1 2015-04-01 01:37:37 <phantomcircuit> Luke-Jr, personally that seems like a critical part of the protocol
  2 2015-04-01 01:54:21 <Luke-Jr> phantomcircuit: it's a complicated part, when you consider the goal of decentralisation. you need to assume the miner will be changing the transactions
  3 2015-04-01 01:56:39 <sipa> Luke-Jr: hmm, maybe some of the efficient block coding work could help here
  4 2015-04-01 01:57:55 <Luke-Jr> maybe. is that still biased toward policy, though? a little bias is okay for nodes (so they have some influence on policy), but maybe not acceptable for mining pools. although of course it's a strict improvement over the current norm..
  5 2015-04-01 02:00:09 <sipa> well it biases towards being able to predict your own block's contents
  6 2015-04-01 02:00:55 <Luke-Jr> I suppose continuing to use proposals may minimise bias too
  7 2015-04-01 02:05:35 <phantomcircuit> Luke-Jr, hmm
  8 2015-04-01 02:05:49 <phantomcircuit> so im thinking the client shouldn't include any transaction it doesn't have the data for
  9 2015-04-01 02:06:01 <phantomcircuit> and the pool shouldn't credit shares which include transaction it doesn't have the data for
 10 2015-04-01 02:06:52 <sipa> phantomcircuit: that's pretty restrictive
 11 2015-04-01 02:07:41 <phantomcircuit> sipa, it prevents the pool from doing withholding attacks
 12 2015-04-01 02:07:46 <Luke-Jr> it might actually be better if the pool *can't* censor transactions. but I'm not sure that's practical.
 13 2015-04-01 02:07:50 <phantomcircuit> and it prevents the client from holding a winning block ransom
 14 2015-04-01 02:08:01 <Luke-Jr> phantomcircuit: the first one is good; the second is bad
 15 2015-04-01 02:08:21 <Luke-Jr> oh
 16 2015-04-01 02:08:34 <Luke-Jr> phantomcircuit: well, as long as the miner can always inform the pool of the transaction, that's okay
 17 2015-04-01 02:08:42 <Luke-Jr> but note the client can ALWAYS w/hold
 18 2015-04-01 02:08:53 <Luke-Jr> that is unavoidable without a softfork
 19 2015-04-01 02:09:28 <sipa> v3 blocks almost at 20% btw
 20 2015-04-01 02:11:34 <phantomcircuit> Luke-Jr, hmm yeah i suppose that's right actually
 21 2015-04-01 02:13:40 <phantomcircuit> Luke-Jr, even if the pool has all the transactions it probably still doesn't have the coinbase
 22 2015-04-01 02:14:05 <phantomcircuit> protocol gets a lot more expensive if the miner cant create the coinbase itself
 23 2015-04-01 02:14:26 <phantomcircuit> so ultimately the client can prove it has a valid block AND withhold the coinbase
 24 2015-04-01 02:14:28 <phantomcircuit> no matter what
 25 2015-04-01 02:16:28 <Luke-Jr> phantomcircuit: or just withhold the share…
 26 2015-04-01 02:16:55 <Luke-Jr> which is effectively the same thing. if you withhold the coinbase, the pool can't prove you're following the generation rules either
 27 2015-04-01 02:17:11 <phantomcircuit> Luke-Jr, no the point is they have to provide enough info to the pool to show that they have a share that's valid on the network
 28 2015-04-01 02:17:21 <phantomcircuit> and then they have about 10 minutes to ransom the share to the pool
 29 2015-04-01 02:17:39 <phantomcircuit> i dont think it's a real issue but as far as protocol design i wanted to make it harder to do
 30 2015-04-01 02:17:55 <Luke-Jr> phantomcircuit: nah, the share is invalid unless the entire thing is received within the time period
 31 2015-04-01 02:18:18 <phantomcircuit> im probably not articulating this well
 32 2015-04-01 02:18:37 <phantomcircuit> i've found a valid network block which includes a coinbase that pays either to the pool or to pool participants
 33 2015-04-01 02:18:48 <phantomcircuit> a total of 25BTC
 34 2015-04-01 02:18:57 <phantomcircuit> im paid 0.0001BTC for the share
 35 2015-04-01 02:19:08 <phantomcircuit> why wouldn't i ransom the block?
 36 2015-04-01 02:19:18 <phantomcircuit> well because you only have 10 minutes to make it happen
 37 2015-04-01 02:19:43 <Luke-Jr> you're not paid for the share until the pool has the whole block somehow
 38 2015-04-01 02:21:15 <phantomcircuit> Luke-Jr, sure but the part that you're paid for the share is tiny compared to the total value it pays to others
 39 2015-04-01 02:21:33 <phantomcircuit> you're risking that tiny share value to basically extort funds from the other pool participants
 40 2015-04-01 02:22:22 <Luke-Jr> … you basically mined a block paying others, and maybe you won't publish it. anyone can do that, even without pools
 41 2015-04-01 02:23:07 <Luke-Jr> are you going to spend ~20 BTC in electricity to bet that those others will be available and agree to pay you on demand?
 42 2015-04-01 02:24:43 <phantomcircuit> Luke-Jr, the miner isn't betting 20BTC
 43 2015-04-01 02:24:53 <Luke-Jr> yes he is, that's the cost to find a block
 44 2015-04-01 02:25:02 <phantomcircuit> no that's the cost to the pool as a whole
 45 2015-04-01 02:25:12 <phantomcircuit> his cost is just the value of the share
 46 2015-04-01 02:25:16 <Luke-Jr> he's not part of the pool if he's holding off on the block
 47 2015-04-01 02:25:16 <phantomcircuit> which is going to be small
 48 2015-04-01 02:25:39 <Luke-Jr> oh, I guess he can submit the other shares timely.
 49 2015-04-01 02:25:49 <Luke-Jr> but still, no different than a block withholding attack really
 50 2015-04-01 02:25:53 <Luke-Jr> except perhaps easier to identify him
 51 2015-04-01 02:26:45 <phantomcircuit> Luke-Jr, the difference is in whether they can prove they have a solution
 52 2015-04-01 02:27:09 <Luke-Jr> the withholder can prove they have a solution too
 53 2015-04-01 02:27:21 <phantomcircuit> unless you've using random extranonce2 values you couldn't prove you had generated a valid block without revealing the block to the pool
 54 2015-04-01 02:27:38 <phantomcircuit> and even then the extranonce2 values tend to be only 2^32
 55 2015-04-01 02:27:45 <phantomcircuit> so easy to bruteforce
 56 2015-04-01 02:28:06 <Luke-Jr> sure you can, reveal the block header alone?
 57 2015-04-01 02:28:45 <phantomcircuit> Luke-Jr, which reveals the nonce, timestamp, and merkle tree root which is enough for the pool to bruteforce the coinbase
 58 2015-04-01 02:29:10 <phantomcircuit> hmm actually i guess not since the pool doesn't know which of the extranonce1 values it gave out is the right one
 59 2015-04-01 02:29:50 <Luke-Jr> and GBT allows any number of bytes to be "extranonce2"
 60 2015-04-01 02:30:38 <Luke-Jr> but as soon as the pool knows you're withholding, they'll just ban you and not payout
 61 2015-04-01 02:31:09 <phantomcircuit> hard to ban anonymous people :P
 62 2015-04-01 03:36:40 <fanquake>  ;;blocks
 63 2015-04-01 03:37:57 <sipa> ;;blocks
 64 2015-04-01 03:37:59 <gribble> 350179
 65 2015-04-01 03:40:05 <fanquake> damn space
 66 2015-04-01 06:57:38 <Chronos> Anyone know of a list or place to discover projects that need contributors?
 67 2015-04-01 06:59:22 <Luke-Jr> Chronos: http://whatcanidoforbitcoin.org/
 68 2015-04-01 07:00:01 <Luke-Jr> https://bitcoin.org/en/development has a list as well
 69 2015-04-01 07:03:22 <gmaxwell> wumpus: Going to fix #5951 or should I make a PR on top of it?
 70 2015-04-01 07:10:24 <wumpus> "fix" what?
 71 2015-04-01 07:11:23 <wumpus> this can already be used, making getrawtransaction check the wallet would be wrong, we're trying to get rid of RPCs that both apply to the wallet and to the rest of the node data structures
 72 2015-04-01 07:12:46 <gmaxwell> wumpus: Thanks for responding. Now I can respond, as is the feature is not useful because there is no way to get the transaction you've created out of the wallet. You might as well just not create transactions. :)
 73 2015-04-01 07:12:54 <wumpus> just use gettransaction, as I mentioned, I wouldn't submit a PR that is compeltely broken like that
 74 2015-04-01 07:13:03 <gmaxwell> oh!
 75 2015-04-01 07:13:11 <wumpus> read the opening post...
 76 2015-04-01 07:18:23 <gmaxwell> I think I'd completely forgotten that gettransaction existed.
 77 2015-04-01 07:19:57 <wumpus> it's named weirdly, should probably have been getwallettransaction or wallet.gettransaction or such.
 78 2015-04-01 07:20:37 <phantomcircuit> wumpus, it was long before getrawtransaction
 79 2015-04-01 07:21:19 <wumpus> ok, that makes sense
 80 2015-04-01 07:21:45 <gmaxwell> the hex was only added to it about a year ago.
 81 2015-04-01 07:22:03 <wumpus> yes
 82 2015-04-01 07:22:05 <gmaxwell> For the longest time it was just a kind of useless call the gave you similar data to listtransactions but not quite the same.
 83 2015-04-01 07:22:43 <phantomcircuit> gmaxwell, it was useful before the listbefore calls
 84 2015-04-01 07:22:44 <wumpus> listtransctions for one transaction!
 85 2015-04-01 07:22:53 <chronos> Istheir such a list? or is anyone here looking for aid on their project?
 86 2015-04-01 07:23:26 <ciemon> chronos: there were two lists given.
 87 2015-04-01 07:23:31 <ciemon> Can you code?
 88 2015-04-01 07:23:34 <chronos> i dced sorry
 89 2015-04-01 07:23:37 <wumpus> it could, in principle, add some information that is too verbose for the list... calls
 90 2015-04-01 07:23:40 <chronos> indeed
 91 2015-04-01 07:23:59 <chronos> i was messing with my vpn settings sorry
 92 2015-04-01 07:24:03 <wumpus> (like hex, thinking of it)
 93 2015-04-01 07:24:13 <ciemon> it happens... http://whatcanidoforbitcoin.org/
 94 2015-04-01 07:24:23 <ciemon> That should help
 95 2015-04-01 07:26:41 <chronos> ahh thanks
 96 2015-04-01 08:13:59 <jonasschnelli> gmaxwell: 03/27 at 09:06 you said: there is no need to actually sign, just assume the size is 73 bytes of signature 1 byte of push, plus the pubkey/redeemscript and its overhead.
 97 2015-04-01 08:14:29 <jonasschnelli> gmaxwell, is the length of the redeemscript (CScript?) available if the wallet is locked?
 98 2015-04-01 08:16:25 <gmaxwell> Yes.
 99 2015-04-01 08:16:57 <gmaxwell> Everything but the private key is there.
100 2015-04-01 08:17:14 <wumpus> the whole script should be available, the code assumes that the redeemscript itself is not sensitive
101 2015-04-01 08:18:02 <jonasschnelli> in sign.cpp i saw: creator.KeyStore().GetCScript(uint160(vSolutions[0]), scriptSigRet)
102 2015-04-01 08:18:31 <jonasschnelli> for getting the length i assume i need the CScript ... but it looks like the CScript is stored encrypted in the walletdb?
103 2015-04-01 08:20:52 <gmaxwell> I'm not sure why you're saying that?
104 2015-04-01 08:21:53 <gmaxwell> (I just mean I don't know what you're saying where you say 'looks like')
105 2015-04-01 08:23:39 <jonasschnelli> Hmm... let me check again. I was assuming that CBasicKeyStore.mapScripts is stored encrypted. But didn't analyzed that fully.
106 2015-04-01 08:28:24 <gmaxwell> jonasschnelli: The only thing that is is mapCryptedKeys. (redeemscripts aren't any more private than pubkeys are; they are just public keys themselves)
107 2015-04-01 08:28:55 <jonasschnelli> gmaxwell, thanks for the help. Now i see it.
108 2015-04-01 08:30:08 <jonasschnelli> wumpus, i'm testing #5951 [disable transaction broadcast], is it right that i can use 'gettransaction' to get the hex of the not-broadcastet tx and use "sendrawtransaction" on another node to broadcast?
109 2015-04-01 08:34:01 <gmaxwell> jonasschnelli: you can sendraw on the same node too.
110 2015-04-01 08:34:34 <gmaxwell> The disable doesn't stop sendrawtransaction from working, it just prevents all "self directed" transmission by the software.
111 2015-04-01 08:35:04 <jonasschnelli> gmaxwell, okay. I just try to send it from another node to get more realistic testing. Just stumbled over the fact that sendrawtransaction does nothing when -walletbroadcast=0. Should that not report that broadcasting is off?
112 2015-04-01 08:35:17 <gmaxwell> so you can make a bunch of transactions, leave them in your wallet, then later use gettransaction/sendrawtransaction to broadcast them.
113 2015-04-01 08:35:46 <jonasschnelli> gmaxwell, ah. Maybe my test is wong... but after sendraw, mining three blocks the tx had 0 confirm.
114 2015-04-01 08:35:47 <gmaxwell> Thats incorrect. Sendrawtransaction works fine when walletbroadcast=0. (I just tested this two hours ago too :) )
115 2015-04-01 08:36:35 <gmaxwell> testnet 56e925f0a5903d8970ca5d3598a909bf8fb969ada4ec3ff4adb9c41b5a2bcf2f had been sitting in my wallet with -1 confirms for two days, I sentraw it, and it confirmed in a few minutes. :) So, -- something wrong with the test.
116 2015-04-01 08:36:53 <gmaxwell> It would be a bug if sendrawtransaction didn't work though.
117 2015-04-01 08:39:39 <jonasschnelli> Again: sorry for the noise. It's working as expected. :)
118 2015-04-01 08:44:11 <wumpus> jonasschnelli: indeed, sendrawtransaction should not be affected by walletbroadcast - none of the non-wallet functionality should be affected by it
119 2015-04-01 08:50:05 <wumpus> (only wallet-related files and init are affecte by the pull, so I would be really surprised if there was a change in behavior there)
120 2015-04-01 09:01:49 <jonasschnelli> wumpus, i just encountered that when i have walletbroadcast=0, send a tx, use the hex to broadcast from another node, sync i then have a tx in the mempool on the original node. Whys this?
121 2015-04-01 09:03:31 <wumpus> I don't quite understand, isn't that the expected behavior? the transaction will enter the mempool of the original node after being broadcasted by another node, just like any other transaction?
122 2015-04-01 09:04:44 <wumpus> the goal of -walletbroadcast=0 is to make the connection node+mempool->wallet one-way
123 2015-04-01 09:05:28 <wumpus> so our own transaction is handled *exactly* like any other transaction, it should not be possible to distinguish them from the outside, based on our behaviour
124 2015-04-01 09:05:57 <wumpus> if there is a leak in that, that would be a bug, but I don't conclude that from what you say
125 2015-04-01 09:06:09 <jonasschnelli> my steps:  node0[broadcast=0].sendtx, node1->sendhex, node2->mineblock, sync_all(), node0 has 1tx in mempool.
126 2015-04-01 09:06:27 <gmaxwell> why is this surprising to you?
127 2015-04-01 09:06:46 <gmaxwell> it should be in node0's mempool after node1->sendhex?
128 2015-04-01 09:06:55 <gmaxwell> or are you saying its still in the mempool after its already in a block?
129 2015-04-01 09:07:49 <gmaxwell> (If it didn't go into the mempool after a peer gave it to it, it would be trivial to go find the origin of a transaction -- it's the node that doesn't have it in its mempool after being given it. :) )
130 2015-04-01 09:08:14 <wumpus> the gossip network will make sure that the transaction ends up in the mempool of all nodes
131 2015-04-01 09:08:23 <wumpus> gmaxwell: indeed
132 2015-04-01 09:08:45 <jonasschnelli> i though the tx should no longer be in mempool when it was mined in a block and the block was received.
133 2015-04-01 09:09:15 <wumpus> yes
134 2015-04-01 09:09:49 <wumpus> if a transaction that made it into a block still lingers in the mempool that would indeed be a bug
135 2015-04-01 09:10:45 <jonasschnelli> i think that is what i encounter in my tests
136 2015-04-01 09:10:47 <wumpus> when a block is connected, the mempool is cleaned of transactions that conflict with transactions that are in that block
137 2015-04-01 09:11:21 <jonasschnelli> the tx id in the mempool is different to the tx id which i manual broadcasts
138 2015-04-01 09:11:32 <jonasschnelli> * i manually broadcasted
139 2015-04-01 09:12:05 <wumpus> so if that doesn't happen it's certainly a bug... I don't see how it could be caused by walletbroadcast=0 changes though, but this would have been a bug that is brought to light by it
140 2015-04-01 09:12:22 <wumpus> jonasschnelli: heh?!
141 2015-04-01 09:12:29 <wumpus> the transaction is mutated?
142 2015-04-01 09:12:44 <wumpus> still, the mempool should catch that
143 2015-04-01 09:12:50 <jonasschnelli> wumpus, i play with rpc test, i try now to get more details of the different txs
144 2015-04-01 09:13:19 <wumpus> as said it eliminates transactions from the mempool that conflict, so that use the same inputs - mutability would not have an effect on that
145 2015-04-01 09:14:18 <hegemoOn> hello
146 2015-04-01 09:14:30 <hegemoOn> i got trouble to compile latest git pull of the repo
147 2015-04-01 09:15:24 <wumpus> hegemoOn: can you be more specific?
148 2015-04-01 09:15:25 <gmaxwell> jonasschnelli: I think you're just spending different inputs there, and so it doesn't conflict, perhaps?
149 2015-04-01 09:16:06 <gmaxwell> (either that or you've found a very severe mempool corruption bug)
150 2015-04-01 09:16:09 <wumpus> if it spends different inputs it's not the same transaction in any way, so it makes sense that it stays in the mempool
151 2015-04-01 09:16:15 <wumpus> yes, that would be bad
152 2015-04-01 09:19:17 <hegemoOn> wumpus: seems the probleme was in my side
153 2015-04-01 09:24:12 <wumpus> ok
154 2015-04-01 09:28:12 <hegemoOn> wumpus: i forgot to ./autogen.sh before ./configure :)
155 2015-04-01 09:38:39 <BuiBU> / Copyright (c) 2009-2013 The Bitcoin Core developers
156 2015-04-01 09:38:41 <BuiBU> / Distributed under the MIT software license, see the accompanying
157 2015-04-01 09:38:43 <BuiBU> / file COPYING or http://www.opensource.org/licenses/mit-license.php.
158 2015-04-01 09:38:45 <BuiBU> #include "crypter.h"
159 2015-04-01 09:38:48 <BuiBU> #include "script/script.h"
160 2015-04-01 09:38:50 <BuiBU> #include "script/standard.h"
161 2015-04-01 09:38:52 <BuiBU> #include "util.h"
162 2015-04-01 09:38:54 <BuiBU> #include <string>
163 2015-04-01 09:38:56 <BuiBU> #include <vector>
164 2015-04-01 09:38:59 <BuiBU> #include <boost/foreach.hpp>
165 2015-04-01 09:39:01 <BuiBU> #include <openssl/aes.h>
166 2015-04-01 09:39:03 <BuiBU> #include <openssl/evp.h>
167 2015-04-01 09:39:05 <BuiBU> bool CCrypter::SetKeyFromPassphrase(const SecureString& strKeyData, const std::vector<unsigned char>& chSalt, const unsigned int nRounds, const unsigned int nDerivationMethod)
168 2015-04-01 09:39:07 <BuiBU> {
169 2015-04-01 09:39:10 <BuiBU>     if (nRounds < 1 || chSalt.size() != WALLET_CRYPTO_SALT_SIZE)
170 2015-04-01 09:39:12 <BuiBU>         return false;
171 2015-04-01 09:39:14 <BuiBU>     int i = 0;
172 2015-04-01 09:39:16 <BuiBU>     if (nDerivationMethod == 0)
173 2015-04-01 09:39:18 <BuiBU>         i = EVP_BytesToKey(EVP_aes_256_cbc(), EVP_sha512(), &chSalt[0],
174 2015-04-01 09:39:21 <BuiBU>                           (unsigned char *)&strKeyData[0], strKeyData.size(), nRounds, chKey, chIV);
175 2015-04-01 09:39:21 <ThomasV> hmm, gmaxwell ^
176 2015-04-01 09:39:21 <wumpus> eh
177 2015-04-01 09:39:23 <BuiBU>     if (i != (int)WALLET_CRYPTO_KEY_SIZE)
178 2015-04-01 09:39:25 <BuiBU>     {
179 2015-04-01 09:39:31 <ThomasV> thanks :)
180 2015-04-01 10:01:15 <jonasschnelli> wumpus, gmaxwell: indeed. There where issues on my side...
181 2015-04-01 10:01:33 <jonasschnelli> wumpus, you might pull in https://github.com/jonasschnelli/bitcoin/commit/f63d3e9dc162a0b02a01fa8b7c51df45aee539d5
182 2015-04-01 10:04:08 <wumpus> jonasschnelli: thanks! I will
183 2015-04-01 10:08:26 <wumpus> I can't retrieve that commit; is it ed9eb7c28fd650b01fbe19353d8e5c1e49549240?
184 2015-04-01 10:09:55 <jonasschnelli> wumpus: maybe a rebase first?
185 2015-04-01 10:10:32 <wumpus> uh, no, I mean I cannot retrieve that commit from your repository
186 2015-04-01 10:26:52 <wumpus> github only allows retrieving commits if they are a parent of a tag or branch
187 2015-04-01 10:27:22 <gmaxwell> :-/
188 2015-04-01 10:27:26 <wumpus> even though you can refer to others in the web interface, you cannot access them through git
189 2015-04-01 10:27:32 <gmaxwell> even though you can link to it?!
190 2015-04-01 10:28:04 <wumpus> in the web interface they also go away after a while, through a scheduled cleanup
191 2015-04-01 10:30:58 <gmaxwell> oh good, PHC (password hashing function contest) dramafest is finally over: http://permalink.gmane.org/gmane.comp.security.phc/2658
192 2015-04-01 10:31:38 <wumpus> jonasschnelli: I suppose I should cherry-pick the head of '2015/04/laanwj_wallet_disable_tx_broadcast', which is ed9eb7c28fd650b01fbe19353d8e5c1e49549240? it looks very similar.
193 2015-04-01 10:32:00 <cbeams> wumpus: the .patch suffix might help here, e.g.: https://github.com/jonasschnelli/bitcoin/commit/f63d3e.patch
194 2015-04-01 10:32:56 <wumpus> cbeams: yes, that'd work too. But I'm, for now, assuming that he  pushed a newer version and gave me the old commit it.
195 2015-04-01 10:33:49 <gmaxwell> wumpus: I bet that behavior is an intentional feature in trying to make accidental data leaks less bad.
196 2015-04-01 10:34:08 <wumpus> gmaxwell: I think so, too
197 2015-04-01 10:34:44 <wumpus> I don't think I caught on the drama around PHC
198 2015-04-01 10:35:17 <wumpus> ohh... I get it
199 2015-04-01 10:35:41 <gmaxwell> well really there was only a little (one of the candidates not taken to second round was complaining for a while), but I was looking for a good reason to express happyness that it was over and wasn't coming up with much.
200 2015-04-01 10:35:44 <wumpus> yes, we should definitely switch to LM hash, it's such proven technology (TM)
201 2015-04-01 10:51:56 <jonasschnelli> wumpus: cherrypick is fine (or copy-n-paste manual commit, etc.) i don't care if its no longer my commit.
202 2015-04-01 10:55:39 <wumpus> jonasschnelli: I'm just trying to understand what happened
203 2015-04-01 10:57:26 <wumpus> trying cbeam's f63d3e.patch: error: patch failed: qa/rpc-tests/wallet.py:150 error: qa/rpc-tests/wallet.py: patch does not apply
204 2015-04-01 10:59:00 <wumpus> OH that patch is to master, not to my branch
205 2015-04-01 11:08:35 <jonasschnelli> wumpus: ah. Yes. Sorry.
206 2015-04-01 11:11:53 <hearn> someone *has* to make a movie of the silk road story some day
207 2015-04-01 11:12:52 <buZz> hearn: only if they include this recent DEA goodness
208 2015-04-01 11:12:59 <buZz> else the story is just too vague
209 2015-04-01 11:13:01 <hearn> yes of course. and whatever insanity follows ....
210 2015-04-01 11:17:07 <hearn> it is very interesting to see the block chain analysis diagrams in the complaint document though
211 2015-04-01 11:17:14 <hearn> the graphs are more complex than i imagined they'd be
212 2015-04-01 11:23:52 <Priidu> lol, when I first read about the rogue DEA guys = instant mental image of goofy Hank-lookalikes (from Breaking Bad) stumbling around aimlessly
213 2015-04-01 11:24:17 <buZz> DEA guy*
214 2015-04-01 11:24:24 <buZz> the other one was secret service
215 2015-04-01 11:24:29 <Priidu> my bad :P
216 2015-04-01 11:24:33 <buZz> and they were helped by DHI , DHS and IRS
217 2015-04-01 11:25:09 <Priidu> anyways, quick question - isn't there a way to get the size of a random wallet transaction via the RPCs from bitcoind?
218 2015-04-01 11:25:26 <Priidu> I'm almost entirely sure I've seen it but might've been dreaming
219 2015-04-01 11:25:30 <Priidu> :P
220 2015-04-01 11:30:05 <Priidu> well, I guess I should just calculate it from the hex string
221 2015-04-01 11:30:29 <Priidu> but thought I had seen it somewhere
222 2015-04-01 11:31:40 <wumpus> gettransaction,  len(rv['hex']//2)
223 2015-04-01 12:21:27 <Priidu> http://www.reddit.com/r/Bitcoin/comments/311gfc/in_a_plea_bargain_former_dea_agent_agrees_to/
224 2015-04-01 12:22:27 <Priidu> my bad, cruel joke ahead :(
225 2015-04-01 12:42:19 <jonasschnelli> hmm... i just found out, that when my wallet has TWO keys of a 2of3 multisig-address, the funds are not seen as spendable (balance, listunspent, etc.). Does this makes sense anyhow or is it just a bug or a incomplete feature?
226 2015-04-01 12:43:06 <gmaxwell> It's just an incomplete feature.
227 2015-04-01 12:43:24 <hearn> jonasschnelli: well the wallet doesn't know how to spend them. so, it makes sense, right?
228 2015-04-01 12:43:38 <gmaxwell> it knows how to spend them.
229 2015-04-01 12:43:54 <jonasschnelli> damit! again my fault. Today i'm working really unconcentrated! Nevermind. It DOES count on the balance.
230 2015-04-01 12:44:36 <hearn> oh, sorry, two keys of a 2-of-3 address, so you have sufficient keys
231 2015-04-01 12:44:40 <hearn> i'm also not really reading closely :)
232 2015-04-01 12:44:42 <gmaxwell> jonasschnelli: there are a bunch of incomplete cases around that.
233 2015-04-01 12:45:15 <gmaxwell> e.g. interaction with watching.
234 2015-04-01 12:57:36 <gdm85> had a somewhat old fork of bitcoin/bitcoin, and GH reported its language as being TypeScript..weird :s
235 2015-04-01 13:07:48 <Priidu> GH does this quite often
236 2015-04-01 13:17:21 <b_lumenkraft> sipa: may i ask how you calculate this chart? >> http://bitcoin.sipa.be/speed-lin-2k.png
237 2015-04-01 13:17:57 <b_lumenkraft> is it based on blocks mined?
238 2015-04-01 13:44:51 <buZz> b_lumenkraft: on what else could it be based?
239 2015-04-01 13:49:47 <b_lumenkraft> buZz: i don’t know. this is why i ask.
240 2015-04-01 13:50:05 <buZz> each block contains a difficulty
241 2015-04-01 13:50:09 <buZz> you can graph those
242 2015-04-01 13:50:17 <b_lumenkraft> so a high hashrate could mean good pool luck, right?
243 2015-04-01 13:50:23 <buZz> looks like he/she also added some moving averages
244 2015-04-01 13:50:31 <buZz> ? high hash means high hash
245 2015-04-01 13:50:36 <buZz> luck is something else
246 2015-04-01 13:51:27 <buZz> X amount of hash gives you Y amount of blocks found in Z amount of time with A difficulty
247 2015-04-01 13:51:39 <buZz> increasing netwide hashrate increases difficulty
248 2015-04-01 13:51:57 <buZz> luck is finding >Y blocks in Z time with X hash on A diff
249 2015-04-01 13:52:19 <b_lumenkraft> i understand this. but how is is the chart calculated then?
250 2015-04-01 13:52:44 <Apocalyptic> <b_lumenkraft> so a high hashrate could mean good pool luck, right? // yes it could
251 2015-04-01 13:52:59 <Apocalyptic> a high hashrate reported in the graph that is
252 2015-04-01 13:53:25 <b_lumenkraft> Apocalyptic: thank’s, that’s what i wanted to know :)
253 2015-04-01 13:54:06 <buZz> i dont see that, but ok
254 2015-04-01 13:54:24 <Apocalyptic> buZz, so what do you see ?
255 2015-04-01 13:54:24 <buZz> luck is finding more blocks than statistics would determine
256 2015-04-01 13:54:41 <buZz> so hashrate would not be increased
257 2015-04-01 13:54:56 <Apocalyptic> he's talking about the green curves that is graphed
258 2015-04-01 13:55:07 <b_lumenkraft> yes
259 2015-04-01 13:55:11 <Apocalyptic> not the real hashrate, which the graph or any node doesn't have any way to know
260 2015-04-01 13:55:29 <buZz> unless, hmm, nethash is calculated based on the rate of blocks found?
261 2015-04-01 13:55:31 <buZz> then yeah
262 2015-04-01 13:55:41 <Apocalyptic> so real hashrate is irrelevant to the discussion, the goal of the graph is to estimate it
263 2015-04-01 13:55:42 <buZz> high luck with same hash would make it look like there is more hash
264 2015-04-01 13:56:07 <Apocalyptic> and that's what he was asking about
265 2015-04-01 13:56:07 <buZz> its just, two different things :)
266 2015-04-01 13:56:46 <b_lumenkraft> thank you guys. i understand now. :)
267 2015-04-01 13:57:41 <Apocalyptic> <buZz> unless, hmm, nethash is calculated based on the rate of blocks found? // on what else could it be based ?
268 2015-04-01 13:58:15 <buZz> yeah :)
269 2015-04-01 13:58:20 <buZz> Apocalyptic: tnx for confirming :)
270 2015-04-01 13:58:35 <Apocalyptic> np :)
271 2015-04-01 13:58:42 <buZz> it was jsut the bringing up of 'pool luck'
272 2015-04-01 13:58:59 <buZz> a pool ofcourse knows the amount of attempts it does, and can do better estimate of hash
273 2015-04-01 14:49:25 <Diablo-D3> https://com.google/
274 2015-04-01 14:52:23 <hearn> well, good to know all the work done on new TLDs was so useful :)
275 2015-04-01 14:55:27 <zooko> ☺
276 2015-04-01 14:55:40 <ajweiss> i read somewhere that google wants to buy exclusive rights to .dev, and the only reason why is that they use it internally and they don't want to deal with changing it
277 2015-04-01 15:00:41 <hearn> they never used .dev when i was there
278 2015-04-01 15:05:30 <pigeons> i guess .local is for that per rfc2606
279 2015-04-01 15:05:34 <pigeons> .test i mean
280 2015-04-01 15:22:07 <morcos> 
281 2015-04-01 15:22:39 <morcos> wumpus: 5900 got merged?  sdaftuar and i were still testing it, but i guess so far so good, so maybe thats fine
282 2015-04-01 15:23:00 <gmaxwell> keep testing it.
283 2015-04-01 15:23:39 <gmaxwell> I think wumpus merged it becase he wants to tag a 0.10rc1 today... and its better to increment further (or take it out) than to leave it out of the rc.
284 2015-04-01 15:23:41 <morcos> will do, do you think we should concentrate on the .10 version for now?
285 2015-04-01 15:23:42 <morcos> right
286 2015-04-01 15:23:45 <wumpus> morcos: moving ahead with 0.10.1
287 2015-04-01 15:24:10 <wumpus> if it wasn't tagged 0.10, I'd not have merged it yet, but as it is low risk and always be improved (or reverted) later I'm merging it now
288 2015-04-01 15:24:48 <wumpus> (no regression risk, if the option is disabled it does nothing)
289 2015-04-01 15:25:16 <sdaftuar> yep, makes sense.  will continue testing...
290 2015-04-01 15:31:09 <wumpus>  * [new tag]         v0.10.1rc1 -> v0.10.1rc1
291 2015-04-01 15:59:06 <michagogo> 
ACTION is pinged by his sms tag alert

292 2015-04-01 15:59:18 <michagogo> Hi everyone... It's been a long time
293 2015-04-01 16:01:03 <michagogo> 
ACTION tries to remember the github url syntax and hopes that https://github.com/bitcoin/bitcoin/compare/v0.10.0..v0.10.1rc1 is right

294 2015-04-01 16:01:31 <michagogo> 3 dots. Damn.
295 2015-04-01 16:02:47 <wumpus> I'm getting a strange gitian build issue on linux
296 2015-04-01 16:16:33 <sipa> jonasschnelli: with watch-only you can mark the p2sh address as spendable
297 2015-04-01 16:28:04 <wumpus> cfields: any idea what could cause "/usr/bin/ld: error: /usr/lib/gcc/x86_64-linux-gnu/4.6/32/libstdc++.a(stdexcept.o): multiple definition of 'std::out_of_range::~out_of_range()'" in the gitian build of 0.10?
298 2015-04-01 16:28:17 <wumpus> cfields: windows build appears to work
299 2015-04-01 16:28:48 <cfields> wumpus: building now
300 2015-04-01 16:29:03 <cfields> wumpus: we mess with that for back-compat, not sure what would've changed though
301 2015-04-01 16:31:06 <wumpus> cfields: thought about that, but "git diff v0.10.0..v0.10.1rc1 src/compat" only shows the strnlen change which doesn't seem to be the source of this
302 2015-04-01 16:31:13 <sipa> b_lumenkraft: from the timestamps of mined blocks yes
303 2015-04-01 16:31:37 <michagogo> Nice to see no deps changes. Did someone add the 0.10.0 release notes to the archive?
304 2015-04-01 16:31:43 <michagogo> 
ACTION texts someone at home to turn on his computer

305 2015-04-01 16:31:54 <b_lumenkraft> thank you sipa. thought so but was not sure.
306 2015-04-01 16:32:39 <sipa> b_lumenkraft: high pool luck could result in higher reported hashrate, but the numbers are based on moving averages, so you would need a significant period of time with consistent luck, which is unlikely
307 2015-04-01 16:33:00 <michagogo> sipa: ...unless you're lucky
308 2015-04-01 16:33:05 <michagogo> :P
309 2015-04-01 16:33:20 <sipa> morcos, sdaftuar: feel free to PR additional tests in it
310 2015-04-01 16:34:29 <cfields> wumpus: can't think of anything off-hand. Still building here. I had nuked my old deps to free up some space, so it's taking a while
311 2015-04-01 16:34:31 <b_lumenkraft> unlikely yes, but huge spikes (like the recent one over 500PH/s) could be a result of better luck.
312 2015-04-01 16:35:44 <sipa> b_lumenkraft: sure, it likely is
313 2015-04-01 16:36:00 <sipa> b_lumenkraft: hashrate is rarely actually removed
314 2015-04-01 16:36:31 <cfields> wumpus: are you using the descriptor from master on accident? That'd link in libstdc++ static and dupe the symbols
315 2015-04-01 16:36:54 <wumpus> cfields: ohhh crap
316 2015-04-01 16:36:58 <wumpus> cfields: yes I think so :-)
317 2015-04-01 16:37:06 <cfields> wumpus: whew :)
318 2015-04-01 16:37:19 <cfields> wumpus: heh, my build just finished successfully too
319 2015-04-01 16:37:20 <sipa> will build rc1 soon
320 2015-04-01 16:37:22 <cfields> so it must be that
321 2015-04-01 16:37:46 <wumpus> cfields: yes, whew, retrying with the right descriptor
322 2015-04-01 16:38:55 <cfields> wumpus: you'll want to redo win too then. Build shouldn't change, but the resulting hashes will due to different configure flags
323 2015-04-01 16:39:28 <wumpus> cfields: indeed
324 2015-04-01 16:41:00 <wumpus> michagogo: no, 0.10.0 release notes wasn't added to doc/release-notes, neither on 0.10 as master
325 2015-04-01 16:41:37 <wumpus> should have done that before cleaning them out for 0.10.1, luckily git keeps a history of everything
326 2015-04-01 16:45:27 <wumpus> ok, added it
327 2015-04-01 16:47:13 <morcos> sipa: when you have a chance, i'd like to discuss that question i mentioned last week about the consistency of caches
328 2015-04-01 16:47:41 <michagogo> wumpus: yeah, there's always the tag, set in stone
329 2015-04-01 16:49:44 <michagogo> Hm. My computer's on and online, but for some reason I can't connect to it
330 2015-04-01 16:50:05 <michagogo> I guess I probably won't build tonight, then
331 2015-04-01 16:50:30 <michagogo> Well, maybe... I don't need to wake up at 5:45 tomorrow, so maybe I'll stay up a bit later
332 2015-04-01 16:59:48 <jonasschnelli> wumpus, cfields: linux build went through on my side: http://builds.jonasschnelli.ch/releasebuilds/v0.10.1rc1/
333 2015-04-01 17:00:16 <jonasschnelli> sipa, thanks. P2SH->watchonly is indeed useful!
334 2015-04-01 17:00:39 <jonasschnelli> 896b06cd4c029b5dc9be54c1da107ede7f4c933c47b0d6a0b39b0d8a08ff4db7  bitcoin-0.10.1-linux32.tar.gz
335 2015-04-01 17:01:13 <cfields> jonasschnelli: great. match.
336 2015-04-01 17:07:22 <cfields> jonasschnelli: https://github.com/bitcoin/gitian.sigs/commit/b1dee230abbb5c87b5756980c306a12a2a7c797d
337 2015-04-01 17:09:04 <jonasschnelli> cfields, nice. win/linux matches. OSX is still building on my side...
338 2015-04-01 17:31:46 <ajweiss> any ideas what "Could not download some packages, please run gbuild --upgrade
339 2015-04-01 17:31:58 <ajweiss> .. means during gitian-building?  (sorry)
340 2015-04-01 17:32:01 <wumpus> I've also pushed sigs (for linux and windows, I don't have the macosx 10.9 tgz)
341 2015-04-01 17:33:30 <wumpus> oh wait, those are not needed for 0.10, that was from back when I had the wrong descriptors
342 2015-04-01 17:33:38 <wumpus> ...building for mac
343 2015-04-01 17:37:11 <ajweiss> ls
344 2015-04-01 17:37:48 <wumpus> ajweiss: never saw that before, probably has to do with the network connection (either your own or in the vm)
345 2015-04-01 17:38:46 <ajweiss> the vm seems fine, maybe inside the container?
346 2015-04-01 17:39:29 <ajweiss> is there a quick oneliner that will get me a shell in the container?
347 2015-04-01 17:43:28 <wumpus> PATH="$PATH:$PWD/libexec" libexec/on-target
348 2015-04-01 17:44:32 <sipa> morcos: in 2-3 hours?
349 2015-04-01 17:46:14 <morcos> sounds good, i have to run at 5pm ET (3:15 from now)
350 2015-04-01 18:27:44 <cfields> jonasschnelli / wumpus: assuming your osx output matches mine: https://bitcoincore.org/cfields/bitcoin-0.10.1rc1/signature.tar.gz
351 2015-04-01 18:35:58 <Guest25225> How do I make sure bitcoind's RPC call sendtoaddress adds miner fees to transactions?
352 2015-04-01 18:36:04 <Guest25225> Tried adding to our bitcoin.conf file: mintxfee=0.0001
353 2015-04-01 18:36:09 <Guest25225> But some of the transactions still won't get any miner fee attached, causing payments to take hours or days to get confirmed.
354 2015-04-01 18:37:54 <gmaxwell> mintxfee; you need to restart to read the config.. (or use the rpc to adjust the mintxfee)
355 2015-04-01 18:38:12 <gavinandresen> Guest25225: -paytxfee=0.0001 is what you want, -mintxfee is used by the mining code (if I’m remembering correctly)
356 2015-04-01 18:38:29 <Guest25225> I already restarted bitcoind, of course
357 2015-04-01 18:38:40 <Guest25225> so paytxfee it is, thanks a lot gavinandresen :)
358 2015-04-01 18:39:09 <jonasschnelli> cfields, https://github.com/bitcoin/gitian.sigs/pull/112, yes. Wrong folder name for OSX, will change
359 2015-04-01 18:41:36 <cfields> jonasschnelli: changing it will break the sig, you'll need to rebuild too :\
360 2015-04-01 18:42:01 <jonasschnelli> cfields, no.. i'll always did it like this.
361 2015-04-01 18:42:17 <jonasschnelli> cfields, why should changing the folder name break the sigs?
362 2015-04-01 18:43:09 <cfields> jonasschnelli: maybe it's only if you change the release name, then
363 2015-04-01 18:44:54 <jonasschnelli> cfields, yes. i think. Maybe i once should make my gpg accept non-email like username... have to look at this once.
364 2015-04-01 18:44:56 <cfields> jonasschnelli: yep, you're right. verifies fine. thanks :)
365 2015-04-01 18:44:58 <gavinandresen> Guest25225: if you’re running the 0.10 release, bitcoind should always send transactions with an estimated fee unless you run with -sendfreetransactions=1
366 2015-04-01 18:47:28 <Guest25225> this is the version I'm running Gavin, Bitcoin version v0.9.2.0-g505681f-beta (Fri, 13 Jun 2014 12:26:02 +0200)
367 2015-04-01 18:47:54 <Guest25225> I've replaced mintxfee with paytxfee now, hopefully that'll work :)
368 2015-04-01 18:49:23 <Guest25225> the Bitcoin wiki pages really need an update tbh
369 2015-04-01 18:50:25 <Guest25225> couldn't find any official info about the mintxfee/paytxfee confs
370 2015-04-01 18:52:13 <sipa> Guest25225: they should be listed in --help
371 2015-04-01 18:52:19 <sipa> the wiki is totally outdated
372 2015-04-01 18:53:44 <Luke-Jr> Guest25225: so update it?
373 2015-04-01 18:55:23 <ciemon> :)
374 2015-04-01 19:07:40 <jonasschnelli> cfields, 38ffe66329ceae701a112cb074a912178a56f7339c387a0726657c67e0b0bacd  bitcoin-osx-signed.dmg
375 2015-04-01 19:08:18 <cfields> jonasschnelli: match
376 2015-04-01 19:08:22 <jonasschnelli> you already committed these. Match.
377 2015-04-01 19:08:51 <Guest25225> I didn't know about --help thanks sipa
378 2015-04-01 19:10:15 <cfields> jonasschnelli: whoa, thanks for checking that on osx. building now.
379 2015-04-01 19:10:37 <jonasschnelli> cfields, you mean the aes stuff?
380 2015-04-01 19:10:43 <cfields> yea
381 2015-04-01 19:11:11 <jonasschnelli> cfields, i didn't expect this on osx to happen. Wonder where the differences are... didn't analyzed.
382 2015-04-01 19:11:36 <phantomcircuit> getting consistent binaries on os x has been an issue in the past iirc
383 2015-04-01 19:11:59 <cfields> jonasschnelli: no worries and no need, I'll look into it. Thanks for testing
384 2015-04-01 19:16:26 <[c]afeine> How can one become an *excellent* progrmmer? (advices).
385 2015-04-01 19:16:59 <jonasschnelli> what a question. Maybe there is no short answer to that.
386 2015-04-01 19:18:07 <Adlai> [c]afeine: http://norvig.com/21-days.html
387 2015-04-01 19:48:17 <cfields> jonasschnelli: what version of openssl did you build against?
388 2015-04-01 19:48:30 <jonasschnelli> cfields, let me check...
389 2015-04-01 19:50:12 <jonasschnelli> cfields, -I/usr/local/Cellar/openssl/1.0.1j/include
390 2015-04-01 19:50:20 <jonasschnelli> pkg_cv_CRYPTO_CFLAGS='-I/usr/local/Cellar/openssl/1.0.1j/include '
391 2015-04-01 19:50:37 <jonasschnelli> CRYPTO_CFLAGS='-I/usr/local/Cellar/openssl/1.0.1j/include '
392 2015-04-01 19:51:01 <jonasschnelli> cfields, i'm using homebrews version.
393 2015-04-01 19:51:25 <cfields> thanks
394 2015-04-01 19:52:02 <jonasschnelli> cfields, hmm.. but as it looks it's a custom/own aes implementation. Or does it compare agains openssl?
395 2015-04-01 19:52:10 <jonasschnelli> *compare in tests
396 2015-04-01 19:52:12 <cfields> jonasschnelli: i can't reproduce. The interesting thing is that the new values look correct
397 2015-04-01 19:52:21 <cfields> yea, that test verifies that we line up with openssl's result
398 2015-04-01 19:52:46 <jonasschnelli> cfields, as long as the new values are correct... :)
399 2015-04-01 19:53:25 <cfields> jonasschnelli: i'm assuming it's a fluke and i'm missing something else. still poking
400 2015-04-01 19:54:44 <jonasschnelli> cfields, just tell me if i can test/assist you somewhere... i assume it one of the EVP_* calls.
401 2015-04-01 19:55:05 <cfields> jonasschnelli: thanks. I'll probably have you add a few nasty printfs if you don't mind
402 2015-04-01 19:55:32 <jonasschnelli> cfields, no problem...
403 2015-04-01 20:57:00 <morcos> sipa: ping, i have to go shortly.. it's potentially a quick question
404 2015-04-01 21:10:02 <morcos> sipa: ok got to run, and will be mostly offline for a few hours, but if you get a chance...  the change i wanted to ask you about is: 
405 2015-04-01 21:10:30 <morcos> uhh  .   https://github.com/bitcoin/bitcoin/compare/master...morcos:AlterBatchWrite
406 2015-04-01 21:11:12 <morcos> the issue is the CCoinsViewCaches get in an inconsistent state for the assumptions we make if you flush an intermediate cache
407 2015-04-01 21:11:29 <morcos> so i think there are two choices, change those assumptions so you can flush an intermediate cache, which is the change i made
408 2015-04-01 21:11:54 <morcos> or i think we should perhaps make it a little less easy to accidentally do that, but can't say i thought to much on how easy that is to do...
409 2015-04-01 21:13:19 <morcos> i didn't want to create a PR for my change though in case its bad or dangerous in some way... i wanted to understand how you thought about the consistency of these caches first
410 2015-04-01 21:13:25 <morcos> thanks!
411 2015-04-01 21:41:32 <sipa> morcos: is there a reason why flushing intermediate caches is useful?
412 2015-04-01 21:43:55 <benjamindees> https://www.youtube.com/watch?v=5cTzcroTkBw&t=1h2m37s
413 2015-04-01 21:44:10 <benjamindees> jgarzik, are these the special forces that BitPay is working with?
414 2015-04-01 21:44:27 <benjamindees> the ones training to "blend in" to American cities and "snatch and grab" people?
415 2015-04-01 21:45:17 <sipa> benjamindees: not here
416 2015-04-01 21:48:24 <benjamindees> sipa, I can assure you that you would find discussing this here preferable to the alternatives.
417 2015-04-01 21:51:06 <sipa> this channel is about development of bitcoin's technology; please take it elsewhere
418 2015-04-01 21:52:23 <benjamindees> of course it is.  this is about who is qualified to develop Bitcoin, and who isn't.
419 2015-04-01 22:00:08 <teward> well time to see if they're disrupting elsewhere too
420 2015-04-01 22:05:32 <benjamindees> for the record, I have also been censored in #bitcoin
421 2015-04-01 22:06:34 <justanotheruser> ##bitcoin
422 2015-04-01 23:23:36 <Luke-Jr> can someone explain why MANDATORY_SCRIPT_VERIFY_FLAGS would ever be considered policy?
423 2015-04-01 23:34:53 <phantomcircuit> Luke-Jr, ?
424 2015-04-01 23:35:33 <sipa> Luke-Jr: well arguably nothing related to lone transactions is consensus