1 2014-07-02 03:41:32 <jprichardson> Does the spec for base58 check encoding include the version number? According to https://en.bitcoin.it/wiki/Base58Check_encoding it does, but https://github.com/bitcoin/bitcoin/blob/master/src/base58.cpp#L108-L114 it doesn't.
2 2014-07-02 03:41:34 <jprichardson> ?
3 2014-07-02 03:41:56 <jprichardson> (I'm not asking about understanding or anything like that... I'm curious about the spec)
4 2014-07-02 03:59:36 <visiteur_1> salut
5 2014-07-02 04:00:25 <visiteur_1> please read it and spread it: https://www.indiegogo.com/projects/focus-fusion-empowertheworld--3
6 2014-07-02 04:55:54 <sipa> jprichardson: implementation detail
7 2014-07-02 04:56:26 <sipa> jprichardson: encoding of an address is base58check(versionbyte + 160bit hash)
8 2014-07-02 04:57:05 <sipa> jprichardson: with base58check itself not adding the version byte, but does add the checksum
9 2014-07-02 05:41:00 <sipa> getutxosetinfo does not work on head?
10 2014-07-02 05:41:28 <sipa> i get "couldn't parse reply from server"
11 2014-07-02 05:41:39 <gmaxwell> works on 6e8472ec7cd6db2344ebc62c7c3eaed158fe3f05 for me
12 2014-07-02 05:41:54 <gmaxwell> which is a week or so old I guess?
13 2014-07-02 05:41:56 <sipa> what serialized size do you get?
14 2014-07-02 05:42:06 <gmaxwell> "bytes_serialized" : 408298844,
15 2014-07-02 05:42:10 <sipa> i suspect the json parsing changes, which may be more recent
16 2014-07-02 05:42:11 <gmaxwell> "height" : 308838,
17 2014-07-02 05:42:16 <sipa> thanks
18 2014-07-02 05:42:29 <gmaxwell> (gives you a point to bisect from if you want to chase it.
19 2014-07-02 05:42:30 <gmaxwell> )
20 2014-07-02 06:01:05 <wumpus> the "couldn't parse reply from server" problem should be solved, it was introduced in c912e22d and solved by 16f33f16
21 2014-07-02 06:04:34 <shubham> How to find the ip address of the system from which transaction is made?
22 2014-07-02 06:04:56 <wumpus> either you just got one of the unlucky versions in between, or there is another error problem
23 2014-07-02 06:05:24 <sipa> shubham: in general, you don't
24 2014-07-02 06:06:31 <shubham> but then how blockchain.info is able to get the ip address of the system?
25 2014-07-02 06:07:00 <gmaxwell> they are not, they report the host they heard the transaction from themselves, its often not the source (though it sometimes is)
26 2014-07-02 06:07:19 <wumpus> connect to a lot of nodes (and let a lot of nodes connect to you), then erport who you got it from first
27 2014-07-02 06:08:20 <wumpus> it's completely unreliable, and has given various people trouble in the past
28 2014-07-02 06:08:37 <gmaxwell> of course, connecting to a lot of nodes wastes resources on the network, and some people will block you when they see you doing it... so I certantly wouldn't recommend you actually go and try this.
29 2014-07-02 06:08:50 <wumpus> mainly because of sites like that I recommend always using bitcoin behind tor
30 2014-07-02 06:09:46 <wumpus> not that it helps you if you run a node and someone thinks you sent a 'bad' transaction, but at least if enough people use tor the information is muddled even more
31 2014-07-02 06:15:19 <shubham> which is the best tool to analyse bitcoin transactions?
32 2014-07-02 06:16:15 <wumpus> but this is really #bitcoin discussion, please take it there
33 2014-07-02 06:20:19 <warren> http://demo.baronpay.org/ Give it a try. Uses bitcoind as the backend.
34 2014-07-02 06:21:00 <wumpus> warren: did you ever answer the question about the node banning?
35 2014-07-02 06:23:10 <warren> wumpus: sorry, the logs during that time are gone
36 2014-07-02 06:23:14 <wumpus> warren: you reported that a 0.9.2.1 node banned a node running master
37 2014-07-02 06:23:17 <warren> yes
38 2014-07-02 06:23:17 <wumpus> sigh
39 2014-07-02 06:24:13 <sipa> wouldn't that be the relay double spend joke?
40 2014-07-02 06:24:23 <wumpus> IIRC it was before that was merged
41 2014-07-02 06:24:45 <wumpus> but yes, that gives another angle
42 2014-07-02 06:24:54 <warren> wumpus: I recall it 0.9.2.1 was testnet, it was stuck syncing from random nodes at ~80k. I connected my master bitcoin-qt to help sync it. shortly thereafter I saw 10 messages in succession in the 0.9.2.1 node's debug.log and my master node was banned.
43 2014-07-02 06:25:37 <wumpus> warren: well... thanks for reporting anyway, let's hope it was someone that modified their software
44 2014-07-02 06:25:55 <warren> wumpus: no, I controlled both sides
45 2014-07-02 06:25:58 <wumpus> oh it was your own node, hmm
46 2014-07-02 06:26:30 <wumpus> what requires 10 messages to be banned...
47 2014-07-02 06:26:50 <sipa> anything with banscore 10
48 2014-07-02 06:26:59 <sipa> there aren't too many of those afaik
49 2014-07-02 06:27:14 <wumpus> only two
50 2014-07-02 06:27:25 <wumpus> AddBlockToQueue state->nBlocksToDownload > 5000
51 2014-07-02 06:28:01 <sipa> ugh
52 2014-07-02 06:28:06 <wumpus> and the alert penalty
53 2014-07-02 06:29:19 <sipa> that first one can happen randonly, it's just to prevent queues from getting too long
54 2014-07-02 06:29:19 <wumpus> oh indirectly there is also return state.DoS(10, error("AcceptBlock() : contains a non-final transaction")
55 2014-07-02 06:29:46 <sipa> that last one should be 100, it's an undeniable violation of the consensus rules
56 2014-07-02 06:30:01 <warren> non-final means?
57 2014-07-02 06:30:01 <wumpus> return state.DoS(10, error("CheckTransaction() : vin empty") return state.DoS(10, error("CheckTransaction() : vout empty"), ... ehh actually there are quite a lot, I didn't look at this angle
58 2014-07-02 06:30:31 <sipa> and the first one should be 0, and just a disconnect
59 2014-07-02 06:30:50 <wumpus> but 0.9.x stopped sending those anyway
60 2014-07-02 06:31:08 <wumpus> and master certainly shouldn't
61 2014-07-02 06:31:22 <sipa> my guess is the nBlocksToDownload
62 2014-07-02 06:31:30 <wumpus> I do get the 0.8.1 node banned sometimes that sends empty vins, but heh they should upgrade
63 2014-07-02 06:31:34 <sipa> especially with a local fast node
64 2014-07-02 06:31:55 <wumpus> yes
65 2014-07-02 06:34:03 <sipa> i'll send a temporary fix (not trigger banscore for it)
66 2014-07-02 08:38:48 <afk11> I'm curious if anyone is working on implementations which use P2SH here? I'm investigating a protocol similar to BIP70/paymentprotocol for multisigP2SH wallet pairing, and signature requests for transactions
67 2014-07-02 08:39:53 <afk11> I'd like to see if anyone is working on something similar so I'm not reinventing the wheel.. Or if anyone wants to help me shape this idea, please get in touch also
68 2014-07-02 12:10:56 <larku> Hey all - I'm a game developer who is totally ignorant of how the bitcoin ecosystem works, but I'm looking to integrate the ability for my players to compete against each other for bitcoins (ie, both pay in bit coin to compete, winner takes the winnings with the house taking a small cut) Can anyone offer some pointers, url's, hints, tips, etc? Basically I'm beginning my research now, starting here where the experts are :)
69 2014-07-02 12:12:25 <Naphex> larku: don't use custom bitcoin implementations, go for BitcoinJ Java/ BitcoinJS / Bitcoin Core. use core bitcoin if you're willing to put some extra work in secureing the daemon
70 2014-07-02 12:13:30 <larku> Naphex, that's the sort of info I'm looking for - so there is already 3rd party software to facilitate most of the transactions etc? I don't want to handle the transactions if I can!
71 2014-07-02 12:13:35 <TradeFortress> larku, if you'd be doing a lot of transactions, it'd be a good idea to handle user balances yourself
72 2014-07-02 12:14:02 <TradeFortress> by that I mean, have a db of each user's balances, make sure you lock.
73 2014-07-02 12:14:07 <Naphex> larku: don't use 3rd parties, you'll have hell with uptimes
74 2014-07-02 12:14:11 <TradeFortress> when a user wants to deposit/withdraw, that's when you interface with bitcoin libraries
75 2014-07-02 12:14:12 <larku> TradeFortress, well, I hope to be doing lots of transactions (wish, wish(
76 2014-07-02 12:14:22 <Naphex> and your 3rd partys are always going to be offline or malfactioning in the sweetest times
77 2014-07-02 12:14:43 <TradeFortress> larku, right. so you touch your bitcoin client of choice (I'd personally go with bitcoind) when a user deposits, or withdraws bitcoin
78 2014-07-02 12:14:47 <larku> Naphex, right.
79 2014-07-02 12:14:54 <TradeFortress> while in your game, treat bitcoin just like some other ingame currency/score/etc.
80 2014-07-02 12:15:43 <jaakkos> larku: for your service's sake, you should study carefully how bitcoin works or you will probably get hacked. using the reference bitcoin daemon (bitcoind/Bitcoin Core) can get you far.
81 2014-07-02 12:15:48 <Naphex> TradeFortress: a decent future would be to use the internal transaction log, with some move functionality
82 2014-07-02 12:15:53 <Naphex> but kinda not enough atm
83 2014-07-02 12:16:30 <TradeFortress> Naphex, that solves from you having to worry about locking/etc, but I don't suggest it because you can't easily do queries on it
84 2014-07-02 12:16:40 <Naphex> larku: make sure you validate & authenticate all requests for withdrawals, before actually transmiting the transactions
85 2014-07-02 12:18:06 <larku> Naphex, absolutely - I'm a veteran developer and security and authentication will be of highest priority - I'm just totally clueless when it comes to bitcoin
86 2014-07-02 12:18:51 <Naphex> larku: a good start up would be learning bitcoin some. buy some use it, move it around. install a core bitcoin daemon and try the api
87 2014-07-02 12:18:57 <Naphex> move some coins around
88 2014-07-02 12:18:58 <TradeFortress> here are some pointers (obviously you need to do some more research)
89 2014-07-02 12:19:28 <TradeFortress> give user deposit address: rpc call getaccountaddress [some_unique_user_identifer_you_can_pick]
90 2014-07-02 12:20:25 <Naphex> listtransactions / listtransactionsince to sync to an internal tree, have triggers on the data
91 2014-07-02 12:20:30 <TradeFortress> if you want to handle balances yourself from that point, pass -blocknotify to call a script or something that checks transactions
92 2014-07-02 12:21:23 <TradeFortress> when a user wants to withdraw, make sure it's not vulnerable to a race attack, make sure you've deducted their balance on your internal tree, sendtoaddress [address] [amount in btc]
93 2014-07-02 12:21:39 <Naphex> use multisig 2of2 / 2of3 to secure cold wallet funds, only have 'safe' amount in hot wallets
94 2014-07-02 12:21:56 <larku> (I'm going to copy paste this session and research everything you guys say - so keep spewing out the awesome details!)
95 2014-07-02 12:22:25 <Naphex> in the process learn how to do some raw transactions, learning some good things on the way:P
96 2014-07-02 12:22:55 <Naphex> if you keep deposit / withdraw fees, have a special account for fees. and move before
97 2014-07-02 12:23:10 <Naphex> only sendtoaddress sfrom special withdrawal account
98 2014-07-02 12:23:47 <TradeFortress> Naphex, that's if you rely on bitcoind's internal accounts
99 2014-07-02 12:24:09 <Naphex> TradeFortress: at least it will keep the accounts clean, without negative value
100 2014-07-02 12:24:20 <Naphex> so i guess it might just be a bit proper, keep internals clean
101 2014-07-02 12:24:27 <TradeFortress> Naphex, well yeah that is ture.
102 2014-07-02 12:24:47 <TradeFortress> unless you craft raw transactions yourself, you won't know what the network fee will be
103 2014-07-02 12:25:06 <TradeFortress> charging a static 0.0001 or 0.0002 is sane for now.
104 2014-07-02 12:26:22 <larku> TradeFortress, that's about 5c - 10c at the moment yeah?
105 2014-07-02 12:27:53 <TradeFortress> yep. that fee is only when someone withdraws to a bitcoin address, you don't pay fees when you just update your balance ledger internally.
106 2014-07-02 12:29:59 <larku> Thanks a lot everyone - lots of good info to kick start my research!
107 2014-07-02 12:30:07 <larku> (I've got a long road ahead :) )
108 2014-07-02 12:30:12 <Naphex> glhf
109 2014-07-02 12:33:06 <GinAddict> general point on bitcoin services development: unless it is your core to offer bitcoin services, does it make sense for most businesses (gaming, content providers, etc) to handle bitcoin themselves on an online server? IMHO they are better off using a third party
110 2014-07-02 12:34:26 <GinAddict> It's hard enough already to make bitcoin only services secure enough
111 2014-07-02 12:38:18 <epscy> GinAddict: i generally agree with that
112 2014-07-02 12:38:40 <epscy> the flip side is though, what's the point of bitcoin if we just tell everybody to use a third party?
113 2014-07-02 12:39:02 <sipa> i think the important part is that you can choose not to
114 2014-07-02 12:39:05 <t7> is Berkeley db code still in the client?
115 2014-07-02 12:39:11 <sipa> for the wallet, yesz
116 2014-07-02 14:03:34 <Alina-malina> erm
117 2014-07-02 14:03:51 <Alina-malina> bitcoinity.org/markets, how come that i cant see any changes in dev tools, but it change values?
118 2014-07-02 14:03:54 <Alina-malina> where those come from?
119 2014-07-02 14:52:13 <ttll> Alina-malina, websocket afaik
120 2014-07-02 15:04:54 <Alina-malina> ttll, so the websocket doesnt neer do to requests and i cant see anything on webdebtools in browser right?
121 2014-07-02 15:05:28 <ttll> you can, google webdevtools + websocket
122 2014-07-02 15:38:13 <dhill> playing with mining, we have found cgminer sometimes submits an invalid hex string .. it has an extra 0xa0 on the end, making the string an odd length. bitcoind's ParseHex happily ignores it. is that intentional, or should bitcoind be rejecting invalid hex strings?
123 2014-07-02 15:38:43 <sipa> which protocol?
124 2014-07-02 15:40:18 <dhill> sipa: http://gbpaste.org/xrxhm
125 2014-07-02 15:40:40 <dhill> cgminer does a submitblock with an odd length sometimes.. has a 0xa0 on the end.
126 2014-07-02 15:40:56 <dhill> if on odd lengths, we remove the last char.. it works.. but it hides a bug
127 2014-07-02 15:41:08 <dhill> that invalid hex is allowed
128 2014-07-02 15:41:26 <sipa> i don't think we should accept that
129 2014-07-02 15:41:38 <sipa> i'm surprised we do
130 2014-07-02 15:41:43 <dhill> ParseHex returns what it has decoded so far once it hits an invalid char
131 2014-07-02 15:41:58 <sipa> and the caller doesn't check the return value of parsehex?
132 2014-07-02 15:42:18 <jrick> what's even better is how IsHex returns false, and ParseHex can still successfully parse the string
133 2014-07-02 15:42:20 <Luke-Jr> dhill: it's invalid
134 2014-07-02 15:42:33 <dhill> Luke-Jr: right, bitcoind accepts it
135 2014-07-02 15:42:42 <Luke-Jr> dhill: sounds like a bug we should fix
136 2014-07-02 15:43:14 <dhill> maybe ParseHex should just do if strlen(hexstring)%2 != 0, return error
137 2014-07-02 15:43:36 <Graet> might be worth reporting in #cgminer too dhill
138 2014-07-02 15:43:39 <jrick> nah don't use strlen
139 2014-07-02 15:43:39 <Luke-Jr> oh, you mean a literal \n character?
140 2014-07-02 15:43:51 <sipa> seems so
141 2014-07-02 15:43:59 <Luke-Jr> ACTION wonders what the outcome is if it's extra hex
142 2014-07-02 15:44:07 <jrick> you have to iterate the string to parse it regardless, no reason to do it twice with strlen
143 2014-07-02 15:46:15 <Luke-Jr> Graet: it's probably intentional, they purposely implemented GBT poorly to make it look bad
144 2014-07-02 15:46:33 <Graet> dont fud
145 2014-07-02 15:47:08 <Luke-Jr> truth isn't fud.
146 2014-07-02 15:47:33 <gigavps> ACTION puts his tin foil hat on
147 2014-07-02 15:56:53 <dhill> Luke-Jr: it isn't \n (0x0a) .. it is 0xa0
148 2014-07-02 15:57:49 <Luke-Jr> dhill: OH! that one âº
149 2014-07-02 15:58:07 <Luke-Jr> dhill: surprised you're not getting gibberish after it, and finding it randomly inside the block data too
150 2014-07-02 15:58:20 <Luke-Jr> old old bug, they claimed they fixed it like a year ago..
151 2014-07-02 15:58:35 <dhill> looks like ParseHex allows "0000 00" too
152 2014-07-02 15:58:50 <Luke-Jr> >_<
153 2014-07-02 15:59:00 <Luke-Jr> dhill: it makes sense, for other things perhaps
154 2014-07-02 15:59:00 <sipa> ignoring whitespace makes sense, but other characters...
155 2014-07-02 15:59:26 <Luke-Jr> sipa: 0xa0 might be considered whitespace
156 2014-07-02 15:59:35 <Luke-Jr> sipa: U+00A0 is a no-break space
157 2014-07-02 15:59:52 <sipa> it's not utf8 for sure
158 2014-07-02 15:59:54 <dhill> encoding/hex: invalid byte: U+00EF 'ï'
159 2014-07-02 16:10:16 <jcorgan> for the libsecp256k1 integration work that was recently merged, is it written anywhere how to enable it? the PR references an --enable option, but I don't see it in the configure.ac. also, it looks like the src/secp256k1 directory should hold the library source, but it's empty. do we do a git clone there, or is there some other way to populate it?
160 2014-07-02 16:10:55 <wumpus> jcorgan: it cannot be enabled yet, the part that has been merged is just the build system side
161 2014-07-02 16:11:20 <jcorgan> ah, them I'm not crazy
162 2014-07-02 16:11:31 <jcorgan> *then
163 2014-07-02 16:37:39 <dhill> hmm, i wonder if it is the json_spirit get_str that removes it
164 2014-07-02 17:14:14 <davec_> we can certainlly massage it to work, but I'm not a fan of hiding bugs like that
165 2014-07-02 17:14:38 <davec_> personally, if you submit invalid hex, I think it should error (bitcoind too)
166 2014-07-02 17:15:07 <davec_> chopping off an extra nibble or ignoring otherwise invalid chars is scary
167 2014-07-02 17:17:44 <Luke-Jr> davec_: no reason to emulate bitcoind bugs, for sure
168 2014-07-02 17:18:07 <dhill> so i guess an GH issue should be created
169 2014-07-02 17:19:06 <jrick> this probably explains why I decoding txs and blocks in a few places returns the json-rpc error code for invalid hex
170 2014-07-02 17:19:17 <jrick> instead of the one for a deserialization error
171 2014-07-02 17:19:31 <jrick> s/I //
172 2014-07-02 17:29:59 <rutzap> Hello guys. I am currently undertaking a masters dissertation on the wonderful Bitcoin protocol and I was wondering if any of you can help me out with something
173 2014-07-02 17:30:57 <rutzap> I need to run some analysis algorithms on the blockchain and I was wondering if you've got any tips on how I would be able to download the full transaction history and analyze it; i.e. what would be the most efficient way of doing this
174 2014-07-02 17:48:43 <dsnrk> download?
175 2014-07-02 17:48:48 <dsnrk> you have it at your fingertips.
176 2014-07-02 17:52:42 <AndyOfiesh> Luke-Jr I'm not having any luck sending my 5-of-5 P2SH/MultiSig spend to your pool. I've tried running bitcoin with connect=... in bitcoin.conf, and I put 0100000001a65.... into http://eligius.st/~wizkid057/newstats/pushtxn.php, and I googled and tried a few other things. I have never relayed a raw tx to a specific pool before. Can you please point me in the right direction?
177 2014-07-02 17:53:51 <Luke-Jr> AndyOfiesh: be sure you have sufficient fees
178 2014-07-02 18:04:35 <AndyOfiesh> 0.0001 not enough?
179 2014-07-02 18:06:12 <AndyOfiesh> with the bitcoin client I'm simply failing to connect to eligius, and with pushtxn.php it doesn't seem to parse my input correctly.
180 2014-07-02 18:07:14 <AndyOfiesh> Actually, I will try pushtxn.php with a 10x the fee anyway.
181 2014-07-02 18:09:11 <phillipsjk> A 5 of 5 script will be large IIRC. Fees are based on transaction size (disk space-wise)
182 2014-07-02 18:12:18 <AndyOfiesh> It's ~1500 bytes
183 2014-07-02 18:12:41 <AndyOfiesh> .001 didn't work either
184 2014-07-02 18:12:54 <wizkid057> unfortunately sendrawtransaction is not very verbose, so, pain to know why it fails