1 2014-06-29 00:03:03 <gwillen> come on, at least ban him then so he doesn't come back and avertise it again :-P
  2 2014-06-29 00:45:05 <warren> Whoa.  A master build testnet node was just banned by a 0.9.2.1 node.
  3 2014-06-29 00:45:13 <btc123> does the alert message signature have to be included in checksum? the wiki isn't clear, since it calls all the data before the signature the 'payload'
  4 2014-06-29 00:45:19 <btc123> https://en.bitcoin.it/wiki/Protocol_specification#alert
  5 2014-06-29 00:46:37 <kazcw> btc123: yes, checksumming happens at the network protocol level
  6 2014-06-29 00:46:52 <btc123> also, can anyone suggest a good way to go about debugging error: {"code":-22,"message":"TX decode failed"}
  7 2014-06-29 00:47:13 <btc123> i suppose i'll have a fun time manually trial and error fixing ;(
  8 2014-06-29 00:47:57 <btc123> kazcw: so, the alert payload + signature is the actual 'payload' that should be calcualted for vars in the header?
  9 2014-06-29 00:48:30 <kazcw> btc123: the entire serialized alert is checksummed
 10 2014-06-29 00:48:48 <btc123> alright.. thanks
 11 2014-06-29 00:49:24 <btc123> i coded a custom c program to sign the message. hope im doing it right... the ecdsa signature is the r + s values together right?
 12 2014-06-29 00:49:26 <kazcw> btc123: the source code is the reference for this kind of thing; the wiki is not always clear, up to date, or accurate
 13 2014-06-29 00:49:47 <btc123> kazcw: good to know.
 14 2014-06-29 00:52:46 <btc123> kazcw; which files do i want to look at in the source to see how messages are built?
 15 2014-06-29 00:52:58 <dsnrk> "SetBestChain: 1 of last 100 blocks above version 2"
 16 2014-06-29 00:53:13 <dsnrk> testnet comes up with some weird stuff.
 17 2014-06-29 00:54:51 <dsnrk> actually that's not even correct, the most recent blocks are all version 2
 18 2014-06-29 01:00:08 <dsnrk> can anybody come up with a reasoning for that?
 19 2014-06-29 01:22:30 <btc123> where are the magic bytes defined in the source code?
 20 2014-06-29 01:22:45 <dhill> dsnrk: the source code says it will give that message if a block comes in higher than the current version
 21 2014-06-29 01:24:23 <dsnrk> dhill: I thought I read somewhere that versions higher than 2 are rejected. that's probably not correct though by the sound of things.
 22 2014-06-29 01:33:26 <dhill> dsnrk: which block?
 23 2014-06-29 01:34:08 <dsnrk> actually good point, let me go back a few blocks and see if I can find one higher than 2.
 24 2014-06-29 01:35:06 <dhill> what timestamp did you get that message?
 25 2014-06-29 01:37:01 <dsnrk> my logs aren't timestamped, that message is after every UpdateTip
 26 2014-06-29 01:37:42 <dsnrk> in the last 100 blocks there's none with a version > 2
 27 2014-06-29 01:38:16 <dhill> find the previous UpdateTip of the first SetBestChain message
 28 2014-06-29 01:40:07 <dsnrk> my logs are super spammy, it was sometime before 0000000061fbbc624dc157b9e2b98aa96bc605e2012e73430431d96a951c3921, but I've no idea when.
 29 2014-06-29 01:40:38 <dhill> looks like 265322?
 30 2014-06-29 01:42:11 <dsnrk> haha, yeah of course it was
 31 2014-06-29 01:42:20 <dsnrk> it's forked bitcoin-ruby off, that's why I didn't see it
 32 2014-06-29 01:42:31 <dsnrk> block version 123456789 :)
 33 2014-06-29 01:43:15 <dhill> http://blockexplorer.com/testnet/rawblock/0000000000014b351588a177be099e39afd4962cd3d58e9ab5cbe45a9cf83c8a
 34 2014-06-29 01:43:22 <dhill> yea, version is not 2
 35 2014-06-29 01:45:07 <dsnrk> well that's cute. wonder how long it'll take somebody to mine on on mainnet that breaks coinbase and friends.
 36 2014-06-29 02:09:02 <PRab> I know this is controversial, but at some point, we should really stop considering bitcoind "the gold standard" and every other implementation buggy.
 37 2014-06-29 02:09:59 <PRab> If only bitcoind follows 1 fork, and most/all other implementations follow a different fork, then I would call that a bug in bitcoind.
 38 2014-06-29 02:10:02 <dsnrk> that's not going to happen. eventually the core rules will be isolated and used in other clients. then there's no issues of consensus.
 39 2014-06-29 02:11:19 <PRab> dsnrk: Maybe not in the near future, but I hope eventually the "protocol" is formalized separate from the bitcoind implementation.
 40 2014-06-29 02:13:20 <PRab> Right now several merchants aren't using bitcoind as their engine, so they get hurt every time there is a fork. If (eventually) bitcoind isn't the most widely spread implementation, then it doesn't make sense for the majority of client to have to upgrade to follow the behavior of the minority,.
 41 2014-06-29 02:13:30 <PRab> (I know all of this is very long-term)
 42 2014-06-29 02:14:11 <dsnrk> that's a problem of entirely their own making though
 43 2014-06-29 02:15:55 <PRab> dsnrk: The fact that bitcoind doesn't fit everybody's needs is their problem?
 44 2014-06-29 02:17:54 <dsnrk> nothing stops you from using bitcoin as your data source and building whatever wallet structures you want on your side.
 45 2014-06-29 02:46:39 <btc123> uhhh, is the 2nd hash here wrong? https://en.bitcoin.it/wiki/Protocol_specification#Hashes
 46 2014-06-29 02:47:21 <btc123> http://www.xorbin.com/tools/sha256-hash-calculator
 47 2014-06-29 02:47:29 <btc123> plug in first hash 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
 48 2014-06-29 02:48:06 <btc123> output is d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9
 49 2014-06-29 02:48:14 <btc123> if someone can confirm, i'll fix the wiki
 50 2014-06-29 02:48:31 <btc123> lots of mistakes on there
 51 2014-06-29 02:50:32 <jcorgan> btc123: you are hashing the hex-encoded ascii, not the original binary
 52 2014-06-29 02:51:18 <btc123> oh, shit
 53 2014-06-29 02:56:35 <btc123> sendrawtransaction can be used to send any message type right?
 54 2014-06-29 02:58:07 <btc123> bbl'
 55 2014-06-29 05:48:04 <wumpus> warren: due to what reason it got banned?
 56 2014-06-29 07:08:41 <fanquake> Looking at the Dos_tests, there is a list of timestamps and nbits for the first 9 blockchain checkpoints. However only the first two match the actual timestamp/bits of the blocks they are reffering to. The next 7 have timestamps/bits that dont match what's actually in the blockchain. Is that intentional? https://gist.github.com/fanquake/1a3aa15c0a73b3bebb20
 57 2014-06-29 08:29:57 <wumpus> PRab: I don't know what you mean exactly with merchants using 'bitcoind as their engine', but I'd say the recommended use of bitcoind is as edge router and full node implementation to run the P2P network, not as wallet. Those concerns should be seen entirely separately.
 58 2014-06-29 08:31:42 <wumpus> a SPV wallet can connect to your bitcoind instance and they won't 'get hurt every time there is a fork' as they outsource part of their verification to the node.
 59 2014-06-29 10:09:32 <sipa1024> warren: existing nodes getting banned is scary; you have any more details
 60 2014-06-29 10:26:58 <izrilgud> Hello everyone, could some one explain me the changes in database from Berkeley DB to other type? what type of database and how the change it's handled?
 61 2014-06-29 10:27:34 <izrilgud> Or the link to the explanation?
 62 2014-06-29 10:28:58 <sipa> the databases related to blockchain validation use LevelDB since 0.8
 63 2014-06-29 10:29:28 <sipa> the wallet was and still is using BDB
 64 2014-06-29 10:30:03 <izrilgud> LevelDB.... nice, i'll start studying
 65 2014-06-29 10:30:50 <izrilgud> ok and BDB for the wallet...
 66 2014-06-29 10:30:56 <dsnrk> not that the blocks on disk are stored in a leveldb database
 67 2014-06-29 10:31:44 <izrilgud> not or note? dsnrk
 68 2014-06-29 10:31:50 <sipa> not
 69 2014-06-29 10:32:11 <sipa> the block chain on disk is raw append-only files with the blocks in network format
 70 2014-06-29 10:32:37 <sipa> there is a leveldb index that stores where which block is to be found in these files
 71 2014-06-29 10:33:08 <izrilgud> it's true... i remember now, raw in network format...thanks sipa..
 72 2014-06-29 10:34:18 <izrilgud> ok, that's how it's prepared to handle a lot of info, the leveldb is for indexing not storing everything... nice
 73 2014-06-29 10:35:11 <dsnrk> as sipa said the block files are append only, the client doesn't use them unless a peer requests it
 74 2014-06-29 10:36:13 <izrilgud> request a verification of old jobs?
 75 2014-06-29 10:36:42 <dsnrk> requests a particular block, that is a node which is doing it's initial sync
 76 2014-06-29 10:36:56 <izrilgud> ahhh yes... of course
 77 2014-06-29 10:37:26 <dsnrk> an SPV node connecting to a full node would need the block files as well.
 78 2014-06-29 10:38:54 <izrilgud> ok, all clients that don't download the whole blockchain but depend on servers...
 79 2014-06-29 10:39:50 <dsnrk> not servers so much, but full nodes. there's no distinction. an SPV node can currently talk to anybody above version 0.8 and set bloom filters on them.
 80 2014-06-29 10:39:51 <izrilgud> ok, all clients that don't download the whole blockchain but depend on full nodes...
 81 2014-06-29 10:39:56 <izrilgud> ok, i'll take a look at LevelDB, and after playing a little i'll be back to get more juicy info from you, thanks a lot.
 82 2014-06-29 10:40:09 <izrilgud> ahh, one more question....
 83 2014-06-29 10:41:01 <izrilgud> how does blockchain.info makes the money?
 84 2014-06-29 10:41:27 <izrilgud> i mean... they don't get any direct income...right?
 85 2014-06-29 10:41:40 <dsnrk> couldn't tell you. I assume through advertising and fees from their mixer service.
 86 2014-06-29 10:42:01 <izrilgud> ;-)
 87 2014-06-29 10:42:14 <izrilgud> thanks and see you soon... i'll keep studying
 88 2014-06-29 10:45:27 <izrilgud> me again.... so is there any easy way to get transaction fees from just implementing full nodes? is what bitpay does?
 89 2014-06-29 10:47:05 <sipa> bitpay is a payment processor
 90 2014-06-29 10:47:13 <izrilgud> i see my question is not clear when mixing with bitpay concept that is much more than just some bitcoin full nodes... but i mean, is there any benefit of running some full nodes... ?
 91 2014-06-29 10:47:13 <sipa> do they much more than run a full node
 92 2014-06-29 10:47:53 <sipa> if you're accepting mondy from others, you better run a full node
 93 2014-06-29 10:48:28 <sipa> full nodes also provide services to the rest of the network, bht this not directly benefit youself
 94 2014-06-29 10:48:37 <izrilgud> ok i understand... the benefit is a better verification of transactions... but no fees...
 95 2014-06-29 10:48:47 <sipa> no
 96 2014-06-29 10:49:07 <dsnrk> fees go to miners only.
 97 2014-06-29 10:50:32 <izrilgud> has anyone see any of the new 999$ OpenSource ATM ?
 98 2014-06-29 10:50:57 <sipa> no
 99 2014-06-29 10:52:42 <izrilgud> ok, i see thanks a lot for your patience...
100 2014-06-29 11:05:51 <izrilgud> thanks sipa, thanks dsnrk ... i see now little more...
101 2014-06-29 12:18:42 <AndersAA> I just made an estimate on how many lines of code are in the Bitcoin project. Does around 370,000 sound about right? I think this includes json/leveldb/crypto though.
102 2014-06-29 12:19:07 <sipa> that sounds a lot
103 2014-06-29 12:19:25 <sipa> sure you didn't count generated code?
104 2014-06-29 12:19:39 <SomeoneWeird> there's software to do exactly this :P
105 2014-06-29 12:20:33 <AndersAA> I just did a "git diff --stat 4b825dc642cb6eb9a060e54bf8d69288fbee4904"(null) on src
106 2014-06-29 12:20:57 <AndersAA> = git diff --stat `git hash-object -t tree /dev/null`
107 2014-06-29 12:21:55 <sipa> well, that will include image files :)
108 2014-06-29 12:21:59 <sipa> and translations
109 2014-06-29 12:22:14 <AndersAA> Images/binaries are skipped. Translations are included though
110 2014-06-29 12:22:21 <gmaxwell> why count leveldb and not boost and openssl? :P
111 2014-06-29 12:22:41 <sipa> 
ACTION quickly adds some empty lines to secp256k1 before merge

112 2014-06-29 12:22:45 <gmaxwell> sloccount on a fresh checkout says Total Physical Source Lines of Code (SLOC)                = 76,277
113 2014-06-29 12:23:17 <AndersAA> gmaxwell: Thank you! Exactly what I needed.
114 2014-06-29 12:23:27 <sipa> that also includes leveldb?
115 2014-06-29 12:23:48 <gmaxwell> yes
116 2014-06-29 12:23:49 <gmaxwell> http://0bin.net/paste/Ypj62PPiLBWsYAVc#pZR-qNpaoKY2EbYnIMKCxctHKBblv52BGQgsJnhq47q
117 2014-06-29 12:27:26 <hearn> bitcoinj is up to 60,500 but that includes orchid
118 2014-06-29 12:27:38 <hearn> 20k of that is orchid (tor)
119 2014-06-29 12:34:45 <sipa> wumpus: present?
120 2014-06-29 12:40:33 <wumpus> sipa: yes
121 2014-06-29 12:44:05 <sipa> so a few things related to clang-format
122 2014-06-29 12:44:19 <wumpus> does it work on the bitcoin source at all? :)
123 2014-06-29 12:44:22 <sipa> sure
124 2014-06-29 12:44:38 <sipa> the latest version in ubuntu doesn't support ForEachMacros
125 2014-06-29 12:44:52 <sipa> meaning that it doesn't recofnize BOOST_FOREACH as a for loop, with pretty horrible results
126 2014-06-29 12:45:00 <wumpus> ugh
127 2014-06-29 12:45:23 <wumpus> but the next version does?
128 2014-06-29 12:45:58 <sipa> i installed one for a ppa, which seems to work
129 2014-06-29 12:46:19 <sipa> i'll push a commit to show the result
130 2014-06-29 12:46:29 <sipa> this takes a while :)
131 2014-06-29 12:47:08 <sipa> hmm maybe not all files at the same time
132 2014-06-29 12:47:33 <wumpus> just the core files at first, I'd say
133 2014-06-29 12:48:06 <wumpus> or maybe one file even
134 2014-06-29 12:48:17 <wumpus> util.cpp :P
135 2014-06-29 12:49:08 <sipa> https://github.com/sipa/bitcoin/commit/924463ddb0e4c3a19fa957a551d959e09e7ff723
136 2014-06-29 12:49:16 <sipa> addrman.h, serialize.h, main.cpp
137 2014-06-29 12:49:36 <sipa> so it deals very badly with IMPLEMENT_SERIALIZE, but if we just put {} around the code inside it will work
138 2014-06-29 12:50:46 <sipa> actually, it unindents incorrectly inside in that case
139 2014-06-29 12:51:03 <wumpus> why does it try to put the implement_serialize on one line, I thought the idea was to disable joining/splitting of lines for now
140 2014-06-29 12:51:38 <wumpus> doesn't seem to do it in other cases
141 2014-06-29 12:51:50 <wumpus> anyhow ,most of it looks good to me
142 2014-06-29 12:52:22 <sipa> https://github.com/sipa/bitcoin/commit/2cab197582fb38bb01f4b2e1cca2f6a6ca7aba98
143 2014-06-29 12:52:36 <sipa> that's with line limit "keep breaking as it is", instead of 120
144 2014-06-29 12:52:47 <wumpus> better!
145 2014-06-29 12:53:28 <wumpus> I like the result now
146 2014-06-29 12:53:29 <sipa> it still unindents an implement_serialize block somewhere halfway
147 2014-06-29 12:54:45 <wumpus> I only see an IMPLEMENT-SERIALIZE in addrman.h and it looks fine
148 2014-06-29 12:54:47 <sipa> also, it never changes anything but whitespace, so it can't enforce braces around if/for blocks
149 2014-06-29 12:55:01 <wumpus> sipa: no problem
150 2014-06-29 12:55:08 <wumpus> I don't really want to see that enforced mindlessly
151 2014-06-29 12:55:26 <sipa> the line with nUBuckets = ADDRMAN_NEW_BUCKET_COUNT is indented _less_ than its parent code
152 2014-06-29 12:55:48 <wumpus> oh I see
153 2014-06-29 12:55:59 <sipa> i wonder whether it's due to the macro around it, or as a means to make the code not too indented
154 2014-06-29 12:56:08 <sipa> i saw no setting for max indentations, though
155 2014-06-29 12:57:37 <CodeShark> http://test.ciphrex.com/coinsocket/
156 2014-06-29 12:57:51 <CodeShark> almost there :)
157 2014-06-29 12:57:56 <sipa> apart from the implement_serialize, i really like how it breaks when a line limit it set... trying to fit things on one line if possible, and otherwhise breaking quite intelligently
158 2014-06-29 12:58:11 <sipa> but that can be done later, i guess
159 2014-06-29 12:59:01 <wumpus> right
160 2014-06-29 13:01:32 <CodeShark> a complete BIP32 key/script generation and transaction/block notification service with a WebSocket API
161 2014-06-29 13:01:40 <sipa> CodeShark: nice!
162 2014-06-29 13:01:44 <sipa> (sorry, too busy now)
163 2014-06-29 13:03:13 <wumpus> CodeShark: nice
164 2014-06-29 13:04:41 <sipa> inline unsigned int GetSerializeSize(char a, int, int = 0)
165 2014-06-29 13:04:50 <sipa> why does it break that function, but not its successors?
166 2014-06-29 13:06:24 <sipa> CBufferedFile(FILE *fileIn, uint64_t nBufSize, uint64_t nRewindIn, int nTypeIn, int nVersionIn)
167 2014-06-29 13:06:40 <sipa> that was well-indented, but it removes the indentation
168 2014-06-29 13:08:35 <wumpus> huh it removes a line break there
169 2014-06-29 13:08:54 <wumpus> after :
170 2014-06-29 13:09:23 <sipa> the keep-breakings was only introduced recently, i guess it has many edge cases
171 2014-06-29 13:10:41 <wumpus> maybe there's an option for constructor initialization clauses?
172 2014-06-29 13:10:59 <sipa> several
173 2014-06-29 13:11:28 <sipa> BreakConstructorInitializersBeforeComma
174 2014-06-29 13:11:35 <sipa> ConstructorInitializerAllOnOneLineOrOnePerLine
175 2014-06-29 13:11:42 <sipa> ConstructorInitializerIndentWidth
176 2014-06-29 13:12:12 <sipa> the last one is about how much indent when breaking after the :
177 2014-06-29 13:12:13 <wumpus> that's a lot indeed, but seems nothing about newlines after :
178 2014-06-29 13:12:40 <sipa> but all logic for determining whether to break after a : is disabled if there is no line length limit
179 2014-06-29 13:12:50 <sipa> and after the : is perhaps a point where it does not check yet
180 2014-06-29 13:34:43 <btc123> can someone tell me why testnet or namecoin or any other blockchain would bother chaining the magic bytes?
181 2014-06-29 13:35:28 <sipa> to avoid nodes thinking they're talking to the right network when they're wrong
182 2014-06-29 13:36:07 <btc123> sipa: wouldn't listening on different ports make that irrelevant?
183 2014-06-29 13:36:19 <sipa> anyone can run on any port
184 2014-06-29 13:36:24 <sipa> there is only a default
185 2014-06-29 13:38:17 <btc123> fair enough, but why would anyone do that? seems like its as silly as checking for pubkey collisions
186 2014-06-29 13:38:46 <btc123> you'd have to be running multiple deamons on the same non standard port with different blockchains
187 2014-06-29 13:39:17 <sipa> well, talk to any of the altcoin authors who forked litecoin and forgot to change the the magic bytes
188 2014-06-29 13:39:36 <btc123> hah. what happened?
189 2014-06-29 13:39:42 <sipa> even if they changed the port, it just needs one accidental link between the two networks, and they start fighting
190 2014-06-29 13:39:46 <btc123> they used the same port also?
191 2014-06-29 13:39:49 <sipa> irrelevant
192 2014-06-29 13:40:19 <btc123> ah one node can start relaying between two networks?
193 2014-06-29 13:40:36 <btc123> good point. thanks.
194 2014-06-29 13:40:37 <sipa> of course, it doesn't know it's talking to different network, so it will relay
195 2014-06-29 13:41:13 <sipa> if they also forgot to change the genesis block, they essentially become a hardfork of eachother
196 2014-06-29 13:41:15 <btc123> sipa: btw, can sendrawtransaction be used to send any network message? or just tx's?
197 2014-06-29 13:41:20 <sipa> just transactions
198 2014-06-29 13:41:54 <btc123> ah, that would explain why i wasted 5 hours yesterday trying to debug my sendalert rawtx that i made
199 2014-06-29 13:42:04 <btc123> lol
200 2014-06-29 13:42:46 <sipa> how would it even know what message to send something as?
201 2014-06-29 13:42:54 <sipa> all you give is the payload
202 2014-06-29 13:43:04 <btc123> the header shows message type
203 2014-06-29 13:43:14 <sipa> you don't pass the header to sendrawtransaction
204 2014-06-29 13:43:27 <btc123> i know this now ;)
205 2014-06-29 13:43:50 <btc123> so, whats best way to send a raw message to the network?  nc?
206 2014-06-29 13:44:02 <btc123> find a peer and manually open a socket and send?
207 2014-06-29 13:44:12 <sipa> use any of the p2p network libraries
208 2014-06-29 13:44:26 <btc123> can you suggest one?
209 2014-06-29 13:44:35 <wumpus> pynode is convenient for that
210 2014-06-29 13:47:00 <hearn> bitcoinj also works
211 2014-06-29 13:48:08 <btc123> thanks
212 2014-06-29 14:00:21 <btc123> is <privatekey> format in sendalert an uncompressed ECC key?
213 2014-06-29 14:00:55 <btc123> uh. nevermind. that was a stupid question.
214 2014-06-29 14:01:29 <btc123> i mean is it HEX or DER or .pem format?
215 2014-06-29 14:03:03 <sipa> neither
216 2014-06-29 14:03:11 <sipa> it's WIF
217 2014-06-29 14:03:17 <sipa> same as importprivkey
218 2014-06-29 14:06:57 <btc123> wow.. thanks. i literally wrote some c yesterday to use openssl libcrypto go gen a ecc keypair for me because i thought it was HEX format for some reason lol
219 2014-06-29 14:08:20 <btc123> its not on wiki also, though i guess it should be assumed
220 2014-06-29 14:10:06 <sipa> also, what sendalert are you talking about?
221 2014-06-29 14:10:58 <sipa> i assumed it was a recently added command that i don't know about, and that it takes the standard we use everywhere...
222 2014-06-29 14:19:01 <btc123> sipa: sendalert displays a message on all clients , obviously only gavin has the privkey for it
223 2014-06-29 14:19:03 <hearn> there is no sendalert p2p message
224 2014-06-29 14:19:07 <hearn> you're talking about jus the "alert" message
225 2014-06-29 14:19:52 <btc123> yes.
226 2014-06-29 14:19:55 <sipa> not only gavin
227 2014-06-29 14:19:59 <sipa> and ah, alert
228 2014-06-29 14:20:07 <sipa> well you don't send a private key in an alert!
229 2014-06-29 14:20:31 <sipa> and it's just the standard public key format that is used everywhere
230 2014-06-29 14:20:38 <sipa> as defined by SEC
231 2014-06-29 14:21:30 <btc123> sendalert <message> <privatekey> <minver> <maxver> <priority> <id> [cancelupto]
232 2014-06-29 14:22:05 <btc123> i guess altcoin creators impletemented it as an api call, thought it was in bitcoin also
233 2014-06-29 14:22:25 <sipa> in that case, ask them :)
234 2014-06-29 14:23:38 <btc123> hah right... well, i manually created an ecc keypair and signed an alert message myself so i'll just try and transmit the raw message myself first
235 2014-06-29 14:26:44 <btc123> do the core devs manually create the alert message and broadcast with some custom code?
236 2014-06-29 14:26:52 <btc123> would you be willing to share it?
237 2014-06-29 14:38:26 <wumpus> it's a custom .cpp file that is linked against bitcoin core, with  specified message, priority etc in the source code, nothing as fancy as a RPC command
238 2014-06-29 14:39:20 <btc123> wumpus: is it available on github?
239 2014-06-29 14:39:41 <wumpus> not publically
240 2014-06-29 14:40:20 <btc123> would i be able to request it, minus the private key of course?
241 2014-06-29 14:40:26 <wumpus> but no problem, I can put it in a gist...
242 2014-06-29 14:40:45 <btc123> thanks!
243 2014-06-29 14:41:23 <wumpus> but if some altcoins have already implemented a 'sendalert' call I'm sure that's more useful
244 2014-06-29 14:43:54 <btc123> wumpus: half their code is usally broken
245 2014-06-29 14:43:57 <btc123> ;)
246 2014-06-29 14:44:18 <wumpus> so is ours, it only gets rebased when an alert needs to be sent
247 2014-06-29 14:45:40 <sipa> sounds like a good reason to include the code
248 2014-06-29 14:45:47 <wumpus> anyhow, I'll put it up
249 2014-06-29 14:46:24 <btc123> wumpus make sure to rm the privkey ;)
250 2014-06-29 14:46:33 <wumpus> it's not in there
251 2014-06-29 14:46:43 <wumpus> https://gist.github.com/laanwj/0e689cfa37b52bcbbb44
252 2014-06-29 14:48:34 <btc123> brb
253 2014-06-29 14:48:40 <wumpus> sipa: well, that adds a continous maintenance burden instead of an incidental
254 2014-06-29 14:48:58 <sipa> i'm not convinced
255 2014-06-29 14:49:17 <sipa> but i don't care
256 2014-06-29 15:00:29 <hearn> sipa, wumpus: what do you guys think about allowing other apps to use the alert broadcast mechanism :-)
257 2014-06-29 15:01:30 <wumpus> hearn: sounds impossible to make that ddos-proof, or to prevent people from using it as generic messaging system
258 2014-06-29 15:01:58 <hearn> i meant a casual "root key signs app key, app key signs alert" type system, where you sign someone's key if they're known to be a Spiffy and Trustable Chap
259 2014-06-29 15:02:00 <wumpus> hearn: but if there is a critical problem with bitcoinj and you need to send an alert, I'll send it for you
260 2014-06-29 15:02:20 <hearn> yeah, i was thinking of upgrade alerts rather than PANIC NOW type alerts.
261 2014-06-29 15:02:29 <hearn> is not a big deal
262 2014-06-29 15:02:46 <hearn> i sort of admire the extreme p2p design of the original bitcoin though. bitcoin.org could have vanished and everything would have still worked
263 2014-06-29 15:02:51 <wumpus> nah, applications can use their own notification mechanism for that (like polling an URI), no need to use the P2P network
264 2014-06-29 15:03:35 <wumpus> bitcoin core doesn't use the P2P network for normal upgrade alerts either, and would use another mechanism if we were to implement them at all
265 2014-06-29 15:04:00 <hearn> i think it originally (?) had some code that checked the version field of your peers, and if they were mostly higher than yours it'd say there was an upgrade available
266 2014-06-29 15:04:09 <hearn> so it wasn't using signed upgrade alerts but was using the p2p network to find out about new versions
267 2014-06-29 15:04:48 <wumpus> if the version string was signed by us, that could work
268 2014-06-29 15:06:08 <wumpus> otherwise, it's just too easy to lie, connect from N nodes with some funny version string and cause a popup
269 2014-06-29 15:06:30 <hearn> i think satoshi's original assumption was that there wasn't much point in doing that. if your peers fake a lower version nothing happens. if they fake your own version, nothing happens (but signing can't fix that). if they fake a new version, ok, you go to bitcoin.org and discover either the p2p network or your internet is broken. no harm done.
270 2014-06-29 15:07:02 <hearn> except a bit of time wasted
271 2014-06-29 15:07:09 <hearn> but sure, signing can't really hurt either
272 2014-06-29 15:07:12 <wumpus> well that requires users to go to bitcoin.org... so the client could just as well look there at startup :)
273 2014-06-29 15:07:59 <hearn> it'd take the load off the server, but perhaps it doesn't matter much
274 2014-06-29 15:08:12 <hearn> if we ever have enough nodes that update checks are a problem -> party time! :)
275 2014-06-29 15:08:20 <wumpus> but yeah, having clients send a signed recommendupgrade message would be interesting
276 2014-06-29 15:08:43 <wumpus> but not more than that and certainly not urgent or important :)
277 2014-06-29 15:08:54 <wumpus> right :)
278 2014-06-29 15:08:59 <wumpus> downloads would be a bigger issue
279 2014-06-29 15:09:23 <hearn> one reason i was thinking about having sub-signed upgrade messages is that i want to make it as cheap/easy as possible to make wallets. if you're on android or ios, no problem, google and apple pay the bills. for a desktop wallet it can end up maybe costing extra money for all the update pings.
280 2014-06-29 15:09:34 <hearn> plus it leaks a bit of data. maybe with integrated tor it doesn't matter
281 2014-06-29 15:09:39 <wumpus> (and if polling every time at start is too much, it could just poll if it is a week ago, for example, this is for non-hurry anyway)
282 2014-06-29 15:09:41 <hearn> yeah
283 2014-06-29 15:11:53 <hearn> i sort of like the idea that someone can make a wallet entirely anonymously. i think running the update server off a tor hidden service and using orchid might be the way to go there
284 2014-06-29 15:12:17 <hearn> but failing that, a signed p2p notification that an update exists pointing at a github url uploaded via tor would also work
285 2014-06-29 15:12:20 <hearn> hmmm. anyway. back to work.
286 2014-06-29 16:00:22 <michagogo> Does Bitcoin Core expose the refund address for transactions sent with the PP?
287 2014-06-29 16:49:59 <dekalo> helo
288 2014-06-29 17:18:33 <AndersAA> Just checking - there's no timeframe on Core releases, right? (Like every x months)
289 2014-06-29 17:18:47 <hearn> nope
290 2014-06-29 17:19:02 <hearn> michagogo: they appear in the UI if you receive a refund to that address. otherwise no.
291 2014-06-29 17:19:10 <hearn> AndersAA: some open source projects do work that way, but not Core
292 2014-06-29 17:20:10 <AndersAA> hearn: Thanks! I know FreeBSD / Linux Kernel work like that so I just had to make sure.
293 2014-06-29 17:20:24 <hearn> chrome, firefox, gnome too iirc
294 2014-06-29 17:22:44 <AndersAA> Yeah, it's pretty much the only life cycle difference between "common open source" and Core.
295 2014-06-29 17:46:43 <AndersAA> The BIP-wiki could use an update. Or I misunderstand the difference between Active and Accepted. Only BIP1 has status "Active" even though a bunch of them are surely active - who's in charge of the page? gmaxwell?
296 2014-06-29 17:47:31 <sipa> the whole concept of accepted is fuzzy
297 2014-06-29 17:48:37 <AndersAA> Shouldn't they be moved to active when they're in a Core production release? Or literally every implementation?
298 2014-06-29 17:48:53 <sipa> except for protocol changes or consensus changes, nothing needs a global "accepted" status
299 2014-06-29 17:49:22 <sipa> it's a per-client or per-implementation decisiin whether to implement for example the payment protocol
300 2014-06-29 17:49:29 <sipa> or bip39
301 2014-06-29 17:49:47 <hearn> i think accepted/active basically just means "we're not going to make any major changes now"
302 2014-06-29 17:50:12 <AndersAA> Well, BIP31 - "pong" for instance - shouldn't that be active instead of accepted?
303 2014-06-29 17:52:03 <hearn> probably. who really cares? :)
304 2014-06-29 17:53:22 <sipa> "not going to make changes anymore" should be "fibal" imho
305 2014-06-29 17:53:25 <sipa> final
306 2014-06-29 17:56:47 <AndersAA> I don't know if I should update BIP31 to Active to see what happens.
307 2014-06-29 18:11:00 <hearn> it's probably not worth the ensuing bike-shed painting
308 2014-06-29 18:13:58 <AndersAA> Let's see if anyone cares :) https://github.com/bitcoin/bips/pull/79
309 2014-06-29 18:29:56 <Luke-Jr> IMO Accepted = in production use; and Active = protocol rule enforced
310 2014-06-29 18:30:12 <Luke-Jr> but that's still a bit fuzzy :p
311 2014-06-29 18:32:23 <AndersAA> Luke-Jr: Good point - though BIP1 is hardly protocol rule enforced.
312 2014-06-29 18:38:27 <Luke-Jr> AndersAA: hence fuzzy
313 2014-06-29 18:40:00 <AndersAA> Indeed.
314 2014-06-29 18:42:39 <sipa> how about new standard tracks: consensus changes, protocol changes, meta (like bip1), informational
315 2014-06-29 18:43:04 <sipa> the last one doea not have 'accepted' or 'active'
316 2014-06-29 18:45:01 <AndersAA> sipa: You mean instead of just type=standard/informational?
317 2014-06-29 18:46:12 <Luke-Jr> sipa: informational seems inherently fuzzy. what would fall under it?
318 2014-06-29 18:46:35 <jcorgan> < hearn> it's probably not worth the ensuing bike-shed painting <= seems to be a common conversation stopper
319 2014-06-29 18:46:37 <sipa> bip32, bip38, bip39, bip44
320 2014-06-29 18:47:33 <Luke-Jr> I would consider those protocol
321 2014-06-29 18:48:16 <AndersAA> Luke-Jr: +1
322 2014-06-29 18:48:21 <sipa> i don't see how
323 2014-06-29 18:48:29 <sipa> they are local to each wallet
324 2014-06-29 18:48:37 <sipa> the network doean't know or care
325 2014-06-29 18:48:38 <Luke-Jr> sipa: HD wallet defines protocol for referring to seeds and such
326 2014-06-29 18:48:40 <Luke-Jr> xpub/xprv
327 2014-06-29 18:48:50 <Luke-Jr> BIP 38 is purely protocol
328 2014-06-29 18:49:06 <sipa> by protocol i meant purely the p2p protocol
329 2014-06-29 18:49:08 <Luke-Jr> oh
330 2014-06-29 18:49:12 <sipa> ie, something nodes need to agree on
331 2014-06-29 18:49:19 <Luke-Jr> well then we need a category for GBT protocol, etc etc
332 2014-06-29 18:49:20 <sipa> wallet stuff... no such requirement
333 2014-06-29 18:49:38 <sipa> maybe call the category 'other' :)
334 2014-06-29 18:50:35 <Luke-Jr> Consensus, Node protocols, Meta, Other
335 2014-06-29 18:50:36 <Luke-Jr> ?
336 2014-06-29 18:50:57 <Luke-Jr> "protocols" keeping in mind that HAM and other mediums may benefit from non-p2p protocols for node peering
337 2014-06-29 18:51:09 <sipa> agree
338 2014-06-29 18:52:07 <Luke-Jr> so now someone needs to write up a BIP to revise BIP 1 on this
339 2014-06-29 18:52:08 <Luke-Jr> :P
340 2014-06-29 18:53:01 <AndersAA> Luke-Jr: :P PR should suffice.
341 2014-06-29 18:53:33 <sipa> no
342 2014-06-29 18:53:47 <sipa> it would be a new BIP; you don't modify old BIPs
343 2014-06-29 18:54:00 <sipa> (unless typo's, corrections, examples, ... but not new ideas)
344 2014-06-29 19:02:41 <AndersAA> sipa: Actually this would be an update to BIP1 = contact editor and original author. Funny thing - BIP1 lists as accepted in the BIP and active in the readme.
345 2014-06-29 19:03:44 <sipa> AndersAA: yes, so it would be bip2 maybe :)
346 2014-06-29 19:05:19 <AndersAA> And according to BIP1 I got it wrong. Active = never meant to be completed. Fuzzy..
347 2014-06-29 19:20:30 <xabbix> I want to run several full nodes on different machines, but have them read the blocks from a single NFS drive, is that possible? would it work?
348 2014-06-29 19:20:36 <sipa> no
349 2014-06-29 19:20:58 <ProfMac> on github, bitcoin/src/main.cpp @ line 4347 is the call pto->PushMessage("inv", vInv);   I wonder if it is possible to search for all occurrences of the string "inv"  (5 characters, including the double quote)
350 2014-06-29 19:21:04 <xabbix> sipa, ok, is this because some will try to write to the same files at the same time?
351 2014-06-29 19:21:13 <sipa> ProfMac: grep?
352 2014-06-29 19:21:50 <sipa> xabbix: the code assumes exclusive access, yeha
353 2014-06-29 19:21:57 <kazcw> xabbix: you can use a filesystem on disk that can do CoW clones or has storage deduplication. You need each instance to be able to write to its own version
354 2014-06-29 19:22:00 <xabbix> cool, thanks for the quick answer.
355 2014-06-29 19:22:15 <ProfMac> I'm using the search box at https://github.com/bitcoin/bitcoin/search?q=%22inv%22&ref=cmdform and I haven't noticed how to use grep on that page.
356 2014-06-29 19:22:25 <sipa> it's a command line utility
357 2014-06-29 19:22:33 <sipa> fgrep '"inv"' *.cpp
358 2014-06-29 19:22:33 <xabbix> kazcw, yeah.. that doesn't help unfortunately :(
359 2014-06-29 19:23:27 <ProfMac> so I need to pull the sources to my local machine, then act nixish.
360 2014-06-29 19:23:35 <sipa> duh
361 2014-06-29 19:23:47 <sipa> learn git, stop using web interfaces :)
362 2014-06-29 19:25:27 <nicksavers> Is it not possible to create deterministic signatures with ECDSA?
363 2014-06-29 19:25:37 <sipa> yes
364 2014-06-29 19:25:49 <sipa> use hash(secretkey || message) as nonce
365 2014-06-29 19:27:33 <ProfMac> lol.  A perfectly nixish answer.
366 2014-06-29 19:52:43 <nicksavers> appreciate the answer, thanks
367 2014-06-29 20:08:36 <posita> Forgive my ignorance, but for secp256k, is 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 an inclusive or exclusive upper bound? I have read it both ways, and (to be completely honest), I don't understand enough about the math to derive it.
368 2014-06-29 20:09:21 <sipa> it's the size of the group
369 2014-06-29 20:09:31 <sipa> so the largest secret key is one less than that
370 2014-06-29 20:10:19 <sipa> it's often called n, the order of the group; valid secret keys are in the (inclusive) range [1,n-1]
371 2014-06-29 20:12:16 <posita> Okay, I understand (more) now. I realize in practice, it probably won't make a difference, since the chance of hitting the upper bound in something like randrange(1, 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141) is *very* small, but I have seen flawed implementations.
372 2014-06-29 20:12:19 <posita> Thanks for the explanation.
373 2014-06-29 20:12:58 <sipa> randrange(a,b) returns numbers in the range [a,b-1]
374 2014-06-29 20:13:24 <sipa> so that is correct
375 2014-06-29 20:14:54 <posita> Sorry…I mistyped. Yes. I meant a call that includes the upper bound. randrange is not that call.
376 2014-06-29 20:15:35 <sipa> ok
377 2014-06-29 20:17:01 <posita> Thanks!