1 2014-09-05 00:14:37 <devrandom> anybody on a distribution other than Ubuntu 14.04 and is willing to test https://github.com/devrandom/gitian-builder/pull/69 ?
  2 2014-09-05 00:14:57 <devrandom> (basically uses lxc-execute instead of lxc-start)
  3 2014-09-05 02:30:48 <cronus> having trouble understanding how to setup certain type of multisig transaction..  want it to be a 2-of-3 transaction where user A wants to send funds to users B and C. The funds can only be sent to B and C (or back to A) if 2 of the 3 people agree to send them.  I don’t know who user C is ahead of time,can someone help me understand the details here?
  4 2014-09-05 02:32:53 <midnightmagic> some of the problems you guys are suggesting make me want to head back to wei dai's assembly..
  5 2014-09-05 02:37:03 <Arnavion> gmaxwell: Atleast C11 has memset_s that's guaranteed to not be optimized out
  6 2014-09-05 02:56:30 <earlz> So, one thing that's always bugged me... why is there not a getblockbynumber RPC call? Instead, looking up a block at a specific height requires getblockhash followed by getblock
  7 2014-09-05 02:57:22 <gwillen> earlz: requesting a block by number is ambiguous, there could be multiple forks
  8 2014-09-05 03:00:59 <earlz> you can't track alternate forks can you?
  9 2014-09-05 03:01:43 <gmaxwell> you can, sure.
 10 2014-09-05 03:02:10 <gmaxwell> though the reason there isn't a bynumber is because we already have an rpc to get the hash by height for the current chain.
 11 2014-09-05 03:15:45 <earlz> What can you use to track the alternate forks then? Like how can you discover orphaned chains?
 12 2014-09-05 03:21:05 <luke-jr_> earlz: side or stale chains, not orphan
 13 2014-09-05 03:21:40 <earlz> what's the difference
 14 2014-09-05 03:21:47 <mr_burdell> earlz: all the blocks your node has seen are stored in the block files
 15 2014-09-05 03:22:02 <mr_burdell> so you can read those files directly to find them
 16 2014-09-05 03:22:03 <luke-jr_> earlz: orphans have no (known) parent - they're not considered chains until they're resolved
 17 2014-09-05 03:22:35 <mr_burdell> i don't know of a way to find them via RPC
 18 2014-09-05 03:22:42 <luke-jr_> mr_burdell: getblock won't work?
 19 2014-09-05 03:22:51 <mr_burdell> luke-jr_: that works if you know the hash
 20 2014-09-05 03:22:54 <earlz> So the only way to find blocks not part of the main chain is to directly read the blk fileS?
 21 2014-09-05 03:22:55 <mr_burdell> but how do you find the hash
 22 2014-09-05 03:23:18 <luke-jr_> mr_burdell: bruteforce! <.< jk
 23 2014-09-05 03:23:26 <mr_burdell> so once you find the blocks, you can then use rpc to read them
 24 2014-09-05 03:23:37 <mr_burdell> ha... just read all the blockhashes
 25 2014-09-05 03:23:48 <earlz> how do you get all the hashes..
 26 2014-09-05 03:24:41 <mr_burdell> earlz: it's not too hard to read the files... you can have a script that basically searches for the magic number and then reads the next 80 bytes.  those will be all the block headers including the ones not in the main chain
 27 2014-09-05 03:25:10 <earlz> ugh
 28 2014-09-05 03:25:57 <mr_burdell> xxd -ps ~/.bitcoin/blocks/blk*.dat | tr -d '\n' | sed -e 's/f9beb4d9/\n/g' | awk '{printf("%s\n", substr($0, RSTART + 9, RSTART + 160)); }' > blkheaders.dump
 29 2014-09-05 03:26:18 <mr_burdell> that's my script for it
 30 2014-09-05 03:26:29 <earlz> I'm dealing with altcoins as well though, specifying magic numbers and hashing algorithm is a pain :(
 31 2014-09-05 03:26:42 <mr_burdell> all you have to do is change the magic number
 32 2014-09-05 03:26:53 <mr_burdell> which is part of the chain parameters
 33 2014-09-05 03:26:57 <mr_burdell> i think
 34 2014-09-05 03:26:59 <luke-jr_> ##altcoin-dev
 35 2014-09-05 03:27:12 <earlz> Wait, do headers include the blockhash?
 36 2014-09-05 03:27:24 <mr_burdell> uh... you hash the header
 37 2014-09-05 03:28:09 <earlz> then yea, have to mess with all the hashing algorithms that different coins use, which is the biggest PITA about messing with Abe
 38 2014-09-05 03:29:19 <earlz> So, there is no better way than parsing block files? ugh. Might just give up on doing "good" tracking of orphans since that blows up my scope for this so much
 39 2014-09-05 03:29:54 <mr_burdell> if you track the blocks in real time, you can just keep track in a database as they come in
 40 2014-09-05 03:30:48 <mr_burdell> the blockfiles are only necessary if you don't have something watching in real time
 41 2014-09-05 03:31:05 <earlz> yea, that's my original plan, but I want somethign better
 42 2014-09-05 03:31:24 <earlz> I assume using blocknotify would help with that though
 43 2014-09-05 03:31:32 <mr_burdell> well, let me know if you find something better... cuz that's how I'm doing it
 44 2014-09-05 03:31:51 <mr_burdell> http://mempool.info/orphans
 45 2014-09-05 03:32:12 <mr_burdell> (apparently I shouldn't be calling them orphans, according to luke)
 46 2014-09-05 03:32:36 <earlz> that page causes chrome to freeeze lol
 47 2014-09-05 03:33:16 <mr_burdell> that's weird
 48 2014-09-05 03:33:34 <mr_burdell> could be because my stats server is down i guess
 49 2014-09-05 03:33:46 <earlz> nah it like doesn't load.. weird
 50 2014-09-05 03:33:59 <mr_burdell> oh, maybe i was hosting some js files on there...
 51 2014-09-05 03:34:04 <earlz> oh apparently my chrome decded to self destruct
 52 2014-09-05 03:34:14 <earlz> it can't load anything lol
 53 2014-09-05 08:04:30 <sipa> mr_burdell: getchaintips or so was recently marged
 54 2014-09-05 09:57:46 <RoBo_V> guys any good realibale site to check bitcoin stat for the day like BTC/MH or so
 55 2014-09-05 09:58:06 <RoBo_V> Im new to it, just doing some calc
 56 2014-09-05 09:58:13 <sipa> #bitcoin
 57 2014-09-05 11:00:42 <volante> how do I build my bitcoin against a custom install of openssl? (not the default openssl that is installed with the system)?
 58 2014-09-05 11:01:25 <volante> i want to use the one in /usr/local/ssl/lib/
 59 2014-09-05 11:06:30 <wumpus> sipa: whoa, good catch about the map1.find(...) != map2.end(), indeed, comparing iterators from different containers is undefined but I'd never have guessed it would cause a crash like that
 60 2014-09-05 11:06:50 <wumpus> volante: IIRC there is a configure flag for specifying the openssl paths
 61 2014-09-05 11:08:20 <volante> i couldnt find anything in configure --help
 62 2014-09-05 11:08:46 <wumpus> otherwise you have to specify ./configure CPPFLAGS="-I/blabla" LDFLAGS="-L/blablab"
 63 2014-09-05 11:20:11 <wumpus> what is this with windows : https://github.com/bitcoin/bitcoin/issues/4840   shouldn't that be the first rule of UI, never move the mouse cursor automatically?
 64 2014-09-05 11:21:45 <TheSeven> windows itself has such a "feature"
 65 2014-09-05 11:21:50 <TheSeven> you can enable it somewhere in the mouse settings
 66 2014-09-05 11:22:08 <TheSeven> if something opens a dialog, the cursor will automatically jump to the default button of that dialog
 67 2014-09-05 11:22:32 <TheSeven> IIUC that user has thar weird feature enabled, and is just complaining that it's somehow picking the wrong buttons to jump to
 68 2014-09-05 11:22:35 <wumpus> ok, thanks
 69 2014-09-05 11:22:44 <TheSeven> that*
 70 2014-09-05 11:23:24 <sipa> i suppose the gui api has some ootion to set the 'default' button, but qt/us aren't using it?
 71 2014-09-05 11:23:36 <sipa> and it onky matters if that feature is enabled
 72 2014-09-05 11:23:42 <TheSeven> dialogs do have a default button of some kind
 73 2014-09-05 11:23:49 <TheSeven> which is e.g. clicked when you press enter or the space bar
 74 2014-09-05 11:24:05 <wumpus> maybe a default button is accidentally set
 75 2014-09-05 11:24:08 <TheSeven> not sure how qt deals with that
 76 2014-09-05 11:24:15 <wumpus> but no one notices, because no one else has that feature on...
 77 2014-09-05 11:24:45 <TheSeven> it's typically also the action that's triggered if you press enter in a text input field
 78 2014-09-05 11:26:11 <hearn> sipa: gettransaction is not supposed to work on a tx that's been confirmed without -txindex right?
 79 2014-09-05 11:27:35 <wumpus> gettransaction will work
 80 2014-09-05 11:27:48 <wumpus> it's a wallet RPC, you're confused with getrawtransaction
 81 2014-09-05 11:29:15 <wumpus> which indeed doesn't (generally) work on transactions that have left the mempool
 82 2014-09-05 11:29:27 <hearn> ah
 83 2014-09-05 11:29:37 <wumpus> except indeed if you enable txindex
 84 2014-09-05 11:30:08 <sipa> gettransaction is a wallet RPC that has nothing to do with -txindex
 85 2014-09-05 11:30:34 <wumpus> it will just fetch a transaction from the wallet, confirmed or not
 86 2014-09-05 11:31:12 <hearn> ah, i see the issue. i noticed that "getdata" was able to fetch transactions that had been confirmed
 87 2014-09-05 11:31:22 <hearn> which is not what i expected and in fact bitcoinj assumes it does not do this. but the reason is probably mapRelay
 88 2014-09-05 11:32:03 <wumpus> right, there is no strong guarantee that confirmed transactions cannot be fetched
 89 2014-09-05 11:32:14 <hearn> tx data hangs around until some hard-coded time results in them being cleared
 90 2014-09-05 11:32:31 <hearn> 15 minutes
 91 2014-09-05 11:32:34 <hearn> i think?
 92 2014-09-05 11:32:44 <volante> woohoo it works.  thanks!  its annoying that redhat doesnt thave ECC support in their openssl.
 93 2014-09-05 11:33:15 <sipa> originally, the only transactions that were fetchable through getdata were recently relayed oned
 94 2014-09-05 11:33:26 <sipa> though i don't know the expiration policy
 95 2014-09-05 11:33:34 <hearn>         mapRelay.insert(std::make_pair(inv, ss));
 96 2014-09-05 11:33:34 <hearn>         // Save original serialized message so newer versions are preserved
 97 2014-09-05 11:33:34 <hearn>         vRelayExpiration.push_back(std::make_pair(GetTime() + 15 * 60, inv));
 98 2014-09-05 11:36:01 <wumpus> yes, I would not recommend writing anything that relies on that specific behavior
 99 2014-09-05 11:56:40 <wumpus> anyone heard of any blocking issues with 0.9.3rc1?
100 2014-09-05 14:06:49 <wumpus> this looks bad, and obvious, can anyone with macosx reproduce? https://github.com/bitcoin/bitcoin/issues/4854
101 2014-09-05 14:12:23 <p2-m2> hi guys I wonder if there is a script-based solution to make a contract to automatically split bitcoin sent to an address to various addresses each with different fraction?
102 2014-09-05 14:17:51 <p2-m2> ot?
103 2014-09-05 14:23:32 <wumpus> p2-m2: I'd say create a multisig address; then when you spend the coins sent to the address each of the people needs to provide their signature, so they can make sure each gets their fair share
104 2014-09-05 14:24:32 <wumpus> I don't think there is a way to *enforce* that it has to happen in certain fractions
105 2014-09-05 14:24:35 <shesek> p2-m2, why not have the payer pay directly to those various addresses?
106 2014-09-05 14:24:51 <shesek> rather than sending it via another address
107 2014-09-05 14:24:59 <wumpus> shesek: that's probably the most sensible solution
108 2014-09-05 14:25:20 <wumpus> generate a payment request that simply pays all the addresses
109 2014-09-05 14:25:30 <shesek> wumpus, though not very practical until the payment protocol is widely adopted
110 2014-09-05 14:25:41 <shesek> there's no proper way to get a user to make a transactions with multiple outputs
111 2014-09-05 14:25:43 <wumpus> the payment protocol *is* widely adapted
112 2014-09-05 14:26:06 <shesek> is it? I might be outdated
113 2014-09-05 14:27:22 <shesek> do bc.i/coinbase/mycelium/electrum/armory support it?
114 2014-09-05 14:27:29 <wumpus> yes
115 2014-09-05 14:31:40 <timothy> only the useless faucet does not support it :P
116 2014-09-05 14:33:48 <lmatteis> i was wondering, can i mine with only the headers of blocks? i could validate transaction inputs by checking the merkle root in the headers right?
117 2014-09-05 14:33:56 <lmatteis> not looking into how to mine, just wondering how the protocol works
118 2014-09-05 14:34:28 <wumpus> you need to track the utxo set to do the validation implied in mining
119 2014-09-05 14:34:57 <lmatteis> wumpus: so the balances add up?
120 2014-09-05 14:35:00 <wumpus> the only secure way to get the utxo set is to validate all the blocks, not just the headers
121 2014-09-05 14:35:20 <wumpus> you could throw away the block data after validating, but you need to have seen it at some point
122 2014-09-05 14:35:45 <lmatteis> wumpus: right, but i'm wondering, instead of having all the block chain with all the transactions, i'm thinking of ways that it could be stripped to only its essential that would allow users to mine
123 2014-09-05 14:36:26 <wumpus> I *think* you can mine with a node that has autoprune (https://github.com/bitcoin/bitcoin/pull/4701) on, don't quote me on this though
124 2014-09-05 14:36:33 <lmatteis> for example, if utxo is needed, then maybe there could be a way, similar to how merkle root allows to verify transaction hashes, to also validate the utxo
125 2014-09-05 14:37:18 <p2-m2> wumpus: to my question, so there is no solution where there is a pure-splitter address equipped with script that always has 0 balance
126 2014-09-05 14:37:42 <wumpus> lmatteis: that would require utxo commitments in blocks (an active area of research)
127 2014-09-05 14:38:25 <lmatteis> wumpus: what's a utxo commitment?
128 2014-09-05 14:39:00 <wumpus> lmatteis: it means (basically, the actual implementation is much more complex) storing and validating a merkle hash of the utxo set in blocks
129 2014-09-05 14:39:17 <lmatteis> ah so what i was saying?
130 2014-09-05 14:39:40 <lmatteis> that would trim down the blockchain by a lot no?
131 2014-09-05 14:39:49 <wumpus> then you can verify the UTXO set at a certain height with SPV-level of security (ie, as long as you trust other miners)
132 2014-09-05 14:40:02 <wumpus> that wouldn't be recommended to use for miners, though
133 2014-09-05 14:40:34 <wumpus> lmatteis: what is your goal? if it is to not store the entire block chain, take a look at the autoprune pull request that I linkd
134 2014-09-05 14:40:39 <lmatteis> wumpus: right and i don't understand the SPV trusting other miners part. if you only have headers, you also know that those blocks have been mined at a high diffuculty and therefore have reached consensus. why do you need to trust them?
135 2014-09-05 14:40:49 <lmatteis> wumpus: i'm just studying not doing anything particular
136 2014-09-05 14:40:59 <wumpus> lmatteis: because miners can lie
137 2014-09-05 14:41:51 <wumpus> it's pretty much a waste of resources right now if they would do so, because everyone computes their own UTXO set and rejects invalid blocks, but if everyone would just trust mined blocks that could change
138 2014-09-05 14:41:56 <lmatteis> how? with transactions that don't add up the the utxo?
139 2014-09-05 14:42:31 <lmatteis> with SPV you don't have to trust miners as long as you wait 5-6 confirmations no?
140 2014-09-05 14:44:49 <wumpus> depth in the chain makes it exponentially more reliable, but with SPV you're always trusting miners to do the validation for you
141 2014-09-05 14:45:16 <lmatteis> wumpus: the validity of the UTXO of the transactions right?
142 2014-09-05 14:46:04 <wumpus> validation of the transactions against the UTXO set
143 2014-09-05 14:56:27 <lmatteis> wumpus: thanks
144 2014-09-05 16:25:00 <wumpus> it's great if people want to contribute, but if you barge in trying to push your coding style because it is so superior, that's rude and annoying...
145 2014-09-05 16:26:13 <gmaxwell> lmatteis: mining on pruned works fine*   (*code not well tested yet)
146 2014-09-05 16:27:09 <gmaxwell> Because wallets don't yet work on pruned mining and firewall nodes are basically the only use case for the pruned stuff at the moment.
147 2014-09-05 16:27:42 <wumpus> mining is an important one
148 2014-09-05 16:27:51 <gmaxwell> (and not even firewall at the moment, since IIRC we won't fetch blocks from a non node-network peer, even if its our only peer)
149 2014-09-05 16:46:06 <wumpus> I'm not sure about that, I think we fetch blocks from non-node_network peers if they inv them, we will just not start a sync from them
150 2014-09-05 17:08:08 <wumpus> grepping the code reveals that the only use of fClient (as set from NODE_NETWORK flag) is in StartSync
151 2014-09-05 17:12:09 <gmaxwell> Hm. Interesting. Well more reason that pruned shouldn't kick peers for trying to fetch blocks they don't have.
152 2014-09-05 20:36:51 <gidgreen> hi. i have a question about transaction relaying prioritisation - anyone here qualified to help?
153 2014-09-05 20:37:10 <sipa> hard to know, without knowing the question
154 2014-09-05 20:38:23 <gidgreen> i'm trying to find the exact rule in bitcoind for determining which transactions are relayed across the network by an individual node, and their prioritisation. i'm seeing transactions that eventually get mined (after around half an hour) but don't seem to be widely known by network nodes.
155 2014-09-05 20:38:40 <gidgreen> i can read the source code and run gdb, etc..., but hoped someone here might already know this stuff well.
156 2014-09-05 20:39:15 <sipa> a transaction is relayed when it is accepted into the memory pool
157 2014-09-05 20:39:34 <gidgreen> so all transactions in the memory pool are relayed to other nodes who request?
158 2014-09-05 20:39:34 <sipa> that means it is valid, does not double spend, is standard, and pays enough fee
159 2014-09-05 20:39:57 <sipa> yes, and more - even transactions which recently were in the mempool but got removed may be requestable still
160 2014-09-05 20:40:32 <gidgreen> ok, and is there any notion of prioritisation in that relaying?
161 2014-09-05 20:40:33 <sipa> but at least: at the moment a transaction is accepted into the mempool, its hash is broadcast in an 'inv' message, and in a short time after that, peers can request it
162 2014-09-05 20:40:43 <sipa> no
163 2014-09-05 20:40:56 <sipa> but there is a concept of priority in the rules for accepting transactions into the memory pool
164 2014-09-05 20:41:03 <gidgreen> aha, i'm listening...
165 2014-09-05 20:41:36 <sipa> either a transaction is fee-paying, which means that per kilobyte it pays whatever the node considers a reasonable amount (10000 satoshi per kb by default, iirc)
166 2014-09-05 20:41:53 <sipa> or, if its fee is below that, it may qualify as a free transaction
167 2014-09-05 20:42:17 <sipa> in which case, its 'priority' must be high enough; priority here is defined as bitcoin-days-destroyed per byte
168 2014-09-05 20:42:36 <gidgreen> ok, but i'm seeing transactions which are fee-paying (10000 satoshis), and under 1kb in size, not propagate well across the network
169 2014-09-05 20:42:44 <sipa> they should
170 2014-09-05 20:43:13 <sipa> maybe that relay minimum fee was reduced to 1000 satoshi per kb; unsure about the number of digits now
171 2014-09-05 20:43:32 <sipa> yes, 1000 per kB
172 2014-09-05 20:43:38 <gidgreen> these transactions are moving a small quantity of bitcoin, but above the anti-dust threshold, and not propagating well
173 2014-09-05 20:43:50 <sipa> not propagating well, or not being mined?
174 2014-09-05 20:44:03 <gidgreen> they are being mined (after say half an hour) but not propagating well in general
175 2014-09-05 20:44:15 <gidgreen> only happens on mainnet, not on test net. will post a link in one sec...
176 2014-09-05 20:44:29 <gidgreen> https://blockchain.info/tx/6ea45d03bed35d2eb1fa3ef79f0485a31f6e8b368954df2e76e1a2dafa4d3f18?show_adv=true
177 2014-09-05 20:44:29 <sipa> how do you measure 'not propagating well'?
178 2014-09-05 20:45:17 <gidgreen> "not propagating well" => my multibit wallet doesn't see it (until it's confirmed), blockchain.info doesn't see it, coinsecrets.org doesn't see it
179 2014-09-05 20:46:08 <gidgreen> (btw i know it's a weird transaction but it is standard under bitcoin 0.9)
180 2014-09-05 20:46:27 <sipa> yes, should be
181 2014-09-05 20:47:14 <gidgreen> is it possible that this is due to the fact that bitcoin 0.8.x is still a meaningful proportion of the network, and to them it is not standard? (that would explain the difference between mainnet and testnet)
182 2014-09-05 20:47:20 <sipa> yes
183 2014-09-05 20:48:12 <gidgreen> ouch. so i need to test that by trying the same txn without the OP_RETURN and seeing if that solves the problem.
184 2014-09-05 20:48:25 <gidgreen> any other possible explanation (and thanks for your help so far)
185 2014-09-05 20:48:28 <gidgreen> ?
186 2014-09-05 20:48:52 <sipa> as far as i know, it should be accepted and relayed
187 2014-09-05 20:50:00 <gidgreen> ok, i will try without the OP_RETURN to confirm if that's the reason. thanks again - Pieter, right?
188 2014-09-05 20:50:14 <sipa> yes
189 2014-09-05 20:50:28 <gidgreen> great, thanks and good night
190 2014-09-05 21:09:19 <gmaxwell> sipa: fwiw, w/ gidgreen's question many sites (including, I believe bc.i) are still based on 0.7 or 0.8 and apply old rules for what they display.
191 2014-09-05 21:09:58 <gmaxwell> actual propagation is very for anything the last release relays (would be hard not to be with the minimum order of a node being 8, the probablity of having all old peers is quite low)
192 2014-09-05 21:14:33 <devrandom> blockchain.info has an even tighter filter AFAIK
193 2014-09-05 21:19:44 <gmaxwell> devrandom: I think thats right.