1 2015-09-10 02:40:24 <cfields> woohoo, net rewrite is finally up and running (limping and staggering, that is)
  2 2015-09-10 05:05:14 <drazisil> I have the most annoying feeling I've run into this before, but where do I get libdb for building on debian jessie? ppa:bitcoin/bitcoin doesn't want to give me software
  3 2015-09-10 05:11:17 <drazisil> mm, nm, just saw I probably just build it myself :)
  4 2015-09-10 05:42:12 <jamesob> anyone ever use clang to compile bitcoind?
  5 2015-09-10 05:57:47 <cfields> yes, often
  6 2015-09-10 06:32:04 <easye> ~.
  7 2015-09-10 06:32:57 <Luke-Jr> easye: lesson of the day: always press Enter before ~.
  8 2015-09-10 06:33:33 <easye> Yep.
  9 2015-09-10 06:52:53 <bedeho> Is it correct that a TxId, as e.g. displayed in a blockexplorer is big endian, while txids on wire/transactions (e.g. in outpoints) are little endian?
 10 2015-09-10 06:53:10 <dcousens> bedeho: no
 11 2015-09-10 06:53:18 <dcousens> there is no concept of endianness in terms of hashes
 12 2015-09-10 06:53:35 <bedeho> ?
 13 2015-09-10 06:53:36 <bedeho> ok
 14 2015-09-10 06:53:40 <dcousens> BUT.
 15 2015-09-10 06:53:49 <dcousens> when displayed as hex strings, they are reversed
 16 2015-09-10 06:53:59 <dcousens> cause, Satoshi yo.  :P
 17 2015-09-10 06:54:18 <maaku> which is to say, they are displayed little-endian ;)
 18 2015-09-10 06:54:37 <maaku> gaaah, *stored little endian, displayed big-endian
 19 2015-09-10 06:54:54 <bedeho> dcousens, :P
 20 2015-09-10 06:54:58 <maaku> if you interpret the txid to be a 256-bit number
 21 2015-09-10 06:54:59 <dcousens> maaku: except they are transmitted *as is* over the wire, and everything over the wire is transmitted in 'byte order'
 22 2015-09-10 06:55:07 <dcousens> uh, network byte order*
 23 2015-09-10 06:55:09 <dcousens> which is big endian
 24 2015-09-10 06:55:31 <bedeho> what about as txid in outpoint as part of a transaction which is being signed?
 25 2015-09-10 06:55:47 <bedeho> or hashed for merkle tree
 26 2015-09-10 06:55:52 <maaku> dcousens: we are playing a game of pedantry, but there is no network byte order conversion done
 27 2015-09-10 06:56:05 <dcousens> maaku: right,  which might imply it is stored big endian
 28 2015-09-10 06:56:06 <dcousens> haha
 29 2015-09-10 06:56:18 <maaku> rather the SHA standard (really, associated test vectors) specifies byte ordering
 30 2015-09-10 06:56:47 <dcousens> bedeho: a discussion I had on this just recently: https://github.com/kristovatlas/bips/pull/1
 31 2015-09-10 06:57:02 <bedeho> dont want to ruin your escalating debate, but what about those two contexts above
 32 2015-09-10 06:58:36 <bedeho> bah, that discussion got complicated realy quick
 33 2015-09-10 06:58:40 <dcousens> bedeho: basically,  if its displayed to a human, reverse it
 34 2015-09-10 06:58:44 <dcousens> otherwise, leave it as is
 35 2015-09-10 06:58:50 <dcousens> seems to be the hard-and-fast rule
 36 2015-09-10 06:59:33 <bedeho> dcousens, ok, will try that heuristic :D, thanks
 37 2015-09-10 06:59:48 <dcousens> bedeho: its very annoying, common source of bugs when making user facing apps
 38 2015-09-10 06:59:59 <dcousens> and API facing
 39 2015-09-10 07:00:07 <dcousens> since most APIs use the reverse byte order hashes too
 40 2015-09-10 07:02:27 <bedeho> dcousens, indeed
 41 2015-09-10 10:49:32 <dcousens> visualizations of the blockchain are fun
 42 2015-09-10 11:21:02 <jonasschnelli> [12:49:32]  <dcousens>
 43 2015-09-10 11:22:38 <dcousens> jonasschnelli: I'm just playing with some webgl atm
 44 2015-09-10 11:22:39 <dcousens> https://i.imgur.com/OysWssV.png
 45 2015-09-10 11:23:02 <dcousens> need to move the API server I'm using off heroku, craps out when I try to request 20mb of data :S
 46 2015-09-10 11:23:16 <dcousens> still, looks great at 60fps haha
 47 2015-09-10 11:31:05 <dcousens> heh: https://i.imgur.com/LAntOTT.png
 48 2015-09-10 11:31:22 <dcousens> sorry, wrong channel, will post these in #bitcoin instead
 49 2015-09-10 12:22:18 <shesek> jonasschnelli, dcousens, http://analytx.io/ has a pretty cool visualization of blockchain activity
 50 2015-09-10 12:24:49 <dcousens> shesek: eh, I was looking at at from the point of view linked transactions
 51 2015-09-10 12:34:57 <jonasschnelli> shesek: http://analytx.io/  is nice. Thanks.
 52 2015-09-10 12:47:14 <shesek> jonasschnelli, sure thing
 53 2015-09-10 17:24:24 <petertodd> wumpus: it might be an idea to do a quick v0.11.1 with that keep track of recently rejected txs with a rolling bloom filter pull req so setting a higher -minrelaytxfee doesn't waste bandwidth
 54 2015-09-10 17:26:29 <sveny> Hello, anyone has a spare ticket to sell (or can get me one) for the Bitcoin Scalability Workshop this weekend in Montreal?
 55 2015-09-10 17:49:24 <imp9> hi
 56 2015-09-10 21:08:58 <bedeho> why is it that txids in wallets/blockexplorers are shown in little endian mode when this the opposite of what one expects for human readable data? regular written down decimal numbers are most analogous to big endian
 57 2015-09-10 21:12:26 <phantomcircuit> bedeho, because that's how bitcoin core does it
 58 2015-09-10 21:16:02 <bedeho> phantomcircuit, I see
 59 2015-09-10 21:16:53 <phantomcircuit> bedeho, the block hashes are interpretted as unsigned little endian 256 bit integers for the PoW check
 60 2015-09-10 21:17:08 <phantomcircuit> and everything else that's a hash is also because it's the same library
 61 2015-09-10 21:17:56 <bedeho> dont you mean big endian? little was for RPC and wallets, no?
 62 2015-09-10 21:18:33 <bedeho> https://bitcoin.org/en/developer-reference#hash-byte-order says: TxId is big endian internally
 63 2015-09-10 21:28:30 <phantomcircuit> "connections": 124,
 64 2015-09-10 21:28:35 <phantomcircuit> uhhhh
 65 2015-09-10 21:35:43 <phantomcircuit> http://0bin.net/paste/rlQTP+9UP5d7dqPV#BKOvG4gr+tRf4uERwWAUzu6gYbNMA8VitUSXQQ7T0nP
 66 2015-09-10 21:35:44 <phantomcircuit> oh
 67 2015-09-10 21:35:48 <bedeho> phantomcircuit, so Im finding contradictory claims about byte order all over the place, also your last response seemed to me to be not in line with bitcoin.org tutorial
 68 2015-09-10 21:36:01 <bedeho> here is another one claiming little endian on wire: https://bitcointalk.org/index.php?topic=162493.5;wap2
 69 2015-09-10 21:36:57 <phantomcircuit> bedeho, it's little endian on the wire and in memory
 70 2015-09-10 21:37:19 <phantomcircuit> iirc transactions are big endian
 71 2015-09-10 21:37:24 <phantomcircuit> and blocks are little
 72 2015-09-10 21:37:30 <phantomcircuit> or something equally confusing
 73 2015-09-10 21:37:37 <bedeho> ok, so this is wrong then -> https://bitcoin.org/en/developer-reference#hash-byte-order
 74 2015-09-10 21:38:00 <bedeho> it claims block has is big
 75 2015-09-10 21:38:05 <bedeho> hash*
 76 2015-09-10 21:41:38 <phantomcircuit> bedeho, possibly the blockhash is big endian except for purposes of PoW comparison
 77 2015-09-10 21:41:45 <phantomcircuit> tbh it's actually super confusing
 78 2015-09-10 21:42:01 <phantomcircuit> the best way to figure it out is to take a block header, hash it and see what it looks like
 79 2015-09-10 21:42:15 <phantomcircuit> (hint that will  be the opposite of what you see in the logs)
 80 2015-09-10 21:43:36 <bedeho> hehe,wow, bitcoin... :D
 81 2015-09-10 21:44:23 <bedeho> so, but at least txids are big endian, not small, on wire and memory, despite the whole little endian library constraint thing you mentioned before?
 82 2015-09-10 21:51:18 <Yoghur114> both prevtxid aswell as prevblockhash are serialized in .. the reverse of whatever endian a hash yields - it's confusing af
 83 2015-09-10 22:20:41 <phantomcircuit> ./serialize.h:91:9: warning: explicitly assigning value of variable of type 'uint32_t' (aka 'unsigned int') to itself [-Wself-assign]
 84 2015-09-10 22:20:44 <phantomcircuit> clang warning
 85 2015-09-10 22:24:26 <Arnavion> htole32 is defined as a noop-macro in your build configuration?
 86 2015-09-10 22:25:55 <phantomcircuit> Arnavion, ah right
 87 2015-09-10 22:26:14 <phantomcircuit> compiling on a little endian system so it makes sense tht htole32 is a noop
 88 2015-09-10 22:26:22 <phantomcircuit> clang should probably fix that...
 89 2015-09-10 22:26:47 <Arnavion> But is it actually a macro? Instead of a function, I mean
 90 2015-09-10 22:27:30 <Arnavion> You'd think it could just be a function and let the compiler optimize it away, which would also solve this particular false alarm
 91 2015-09-10 22:27:41 <phantomcircuit> Arnavion, i've no idea honestly
 92 2015-09-10 22:27:45 <phantomcircuit> it's probably a macro though
 93 2015-09-10 22:29:36 <Arnavion> Don't know how clang would "fix" than then
 94 2015-09-10 22:29:52 <Arnavion> short of either whitelisting that particular name, or perhaps everything that originates from that particular header
 95 2015-09-10 22:30:45 <bsm1175321> Anyone going to Scaling Bitcoin this weekend?
 96 2015-09-10 22:31:13 <phantomcircuit> bsm1175321, yes i will be presenting on the runtime complexity of initial block synchronization on day two
 97 2015-09-10 22:32:01 <phantomcircuit> petertodd, just sent a bunch of dust your way via dust-b-gone
 98 2015-09-10 22:32:04 <phantomcircuit> plz2kick
 99 2015-09-10 22:32:44 <petertodd> phantomcircuit: heh, I need to patch dust-b-gone to deal with >100K worth of dust at a time properly...
100 2015-09-10 22:33:26 <bsm1175321> I can't make it, but I wrote up my thoughts here: http://blog.sldx.com/three-challenges-for-scaling-bitcoin/
101 2015-09-10 22:33:26 <phantomcircuit> petertodd, congrats it's 80k
102 2015-09-10 22:33:47 <phantomcircuit> petertodd, you can explode the tx into smaller ones without anybody resigning right?
103 2015-09-10 22:34:19 <petertodd> phantomcircuit: yup, they're all signed with NONE|ANYONECANPAY so you can even add them to other transactions
104 2015-09-10 22:35:23 <petertodd> in fact, there's some very savvy stuff that could be done there... e.g. mines could split up the transactions and take just the highest fee parts!
105 2015-09-10 22:36:37 <phantomcircuit> petertodd, in general miners should have a giant list of known private keys and simply snipe outputs at the point of transaction selection
106 2015-09-10 22:36:57 <phantomcircuit> it would be pretty easy to do and probably reasonably profitable
107 2015-09-10 22:36:58 <petertodd> phantomcircuit: speaking of: https://github.com/petertodd/replace-by-fee-tools/blob/master/spend-brainwallets-to-fees.py
108 2015-09-10 22:37:04 <phantomcircuit> ha
109 2015-09-10 22:37:23 <phantomcircuit> petertodd, yeah i imported the spammers private keys that they published and did dust-b-gone
110 2015-09-10 22:37:44 <petertodd> phantomcircuit: it both spends known privkeys, as well as attempts to replace txouts in transactions with OP_RETURN to fees (e.g. unsigned txs and SIGHASH_NONE)
111 2015-09-10 22:37:51 <petertodd> phantomcircuit: ha, nice
112 2015-09-10 22:37:56 <phantomcircuit> petertodd, it would be nice if you could do a replace-by-fee-master
113 2015-09-10 22:38:24 <petertodd> phantomcircuit: I have a default list of known privkeys/brainwallets here: https://github.com/petertodd/replace-by-fee-tools/blob/master/known-privkeys
114 2015-09-10 22:38:39 <petertodd> phantomcircuit: I'm running spend-brainwallets-to-fees right now on a full-RBF node
115 2015-09-10 22:39:05 <phantomcircuit> petertodd, if i specify --tor does that go to a full rbf node?
116 2015-09-10 22:39:07 <petertodd> phantomcircuit: actually, recently it found 4BTC worth of fees because of someones buggy signature signing code... though none got collected by miners
117 2015-09-10 22:39:19 <petertodd> phantomcircuit: ??? in dust-b-gone?
118 2015-09-10 22:39:26 <phantomcircuit> yes
119 2015-09-10 22:39:32 <petertodd> phantomcircuit: dust-b-gone knows nothing about RBF
120 2015-09-10 22:39:44 <phantomcircuit> yeah i mean when i specify tor
121 2015-09-10 22:39:52 <BlueMatt> ummmm......did no one notice that you can no longer build bitcoind with 1gb ram?
122 2015-09-10 22:39:55 <phantomcircuit> it's sending the tx somewhere over tor
123 2015-09-10 22:40:09 <BlueMatt> CXX      test/test_test_bitcoin-script_tests.o
124 2015-09-10 22:40:09 <BlueMatt> g++: internal compiler error: Killed (program cc1plus)
125 2015-09-10 22:40:13 <petertodd> phantomcircuit: --tor sends the tx to the central dust-b-gone server over tor; dust-b-gone itself doesn't broadcast the transaction though
126 2015-09-10 22:40:14 <phantomcircuit> BlueMatt, yes, build with clang instead
127 2015-09-10 22:40:15 <phantomcircuit> horray
128 2015-09-10 22:40:17 <BlueMatt> script-tests takes more than ~1g ram to build...........
129 2015-09-10 22:40:27 <BlueMatt> no, thats a pretty annoying but that *we* should fix
130 2015-09-10 22:40:29 <phantomcircuit> petertodd, yeah is that central server rbf?
131 2015-09-10 22:40:30 <BlueMatt> not switch compilers
132 2015-09-10 22:40:44 <petertodd> phantomcircuit: it's a socat instance piping the txs to a text file
133 2015-09-10 22:40:53 <petertodd> phantomcircuit: actually broadcasting is done manually
134 2015-09-10 22:40:57 <phantomcircuit> BlueMatt, split out the files into more compile units
135 2015-09-10 22:41:07 <phantomcircuit> or use clang which peaks at ~256MB per process
136 2015-09-10 22:41:15 <phantomcircuit> petertodd, ha
137 2015-09-10 22:42:03 <phantomcircuit> hmm
138 2015-09-10 22:43:38 <BlueMatt> phantomcircuit: or be lazy :)https://github.com/bitcoin/bitcoin/issues/6658
139 2015-09-10 22:44:03 <phantomcircuit> BlueMatt, ie get someone else to do it
140 2015-09-10 22:44:19 <BlueMatt> well, I'll do it later if no one else does
141 2015-09-10 23:01:34 <jgarzik> BlueMatt, I vote for dropping boost
142 2015-09-10 23:01:43 <jgarzik> and the "dump it all into a header" mentality along with it
143 2015-09-10 23:02:05 <phantomcircuit> jgarzik, quick go and intercept the mempool indexing patches
144 2015-09-10 23:02:17 <williamcotton> what's the current state of OP_RETURN size, is 80 bytes getting mined and propagating?
145 2015-09-10 23:02:18 <phantomcircuit> boost multi index with no c++11 equivalent
146 2015-09-10 23:03:00 <phantomcircuit> jgarzik, iirc that's one of the only things we would be using that doesn't have a c++11 replacement
147 2015-09-10 23:03:32 <phantomcircuit> though to be fair if we did all the work to actually remove boost replacing that multiindex stuff wouldn't be much more work
148 2015-09-10 23:03:34 <jgarzik> phantomcircuit, sigh
149 2015-09-10 23:04:05 <phantomcircuit> ha
150 2015-09-10 23:04:15 <phantomcircuit> jgarzik, montreal?
151 2015-09-10 23:22:00 <cfields> <phantomcircuit>   "connections": 124,
152 2015-09-10 23:22:05 <cfields> ^^ default config?
153 2015-09-10 23:24:30 <phantomcircuit> cfields, yeah
154 2015-09-10 23:25:04 <phantomcircuit> switching to master which has the smarter connection limiting logic in it
155 2015-09-10 23:25:22 <cfields> interesting. thanks
156 2015-09-10 23:25:45 <jamesob> outta curiosity: what's the likelihood that the reference implementation of bitcoind will ever transition from c++ to a more modern systems language?
157 2015-09-10 23:26:04 <cfields> zero
158 2015-09-10 23:26:10 <cfields> that would be a different implementation
159 2015-09-10 23:29:45 <jamesob> cpp4ever