1 2015-01-26 01:55:01 <kgk> when creating a bitcoin address from a pubkey, should it use the compressed or uncompressed form? or does it matter?
  2 2015-01-26 01:55:25 <Luke-Jr> compressed
  3 2015-01-26 01:55:35 <Luke-Jr> it will work either way, but compressed is smaller
  4 2015-01-26 01:55:49 <Luke-Jr> obviously test on testnet first to be sure you get it all right
  5 2015-01-26 01:56:20 <kgk> gotcha. thx!
  6 2015-01-26 06:50:26 <wumpus> yes, always use compressed
  7 2015-01-26 07:51:15 <jonasschnelli> wumpus, what do you think about hooks instead of #ifdefs for the wallet<->bitcoind interaction?
  8 2015-01-26 07:51:24 <jonasschnelli> wumpus, do we use hools anywhere else in the code?
  9 2015-01-26 07:52:54 <wumpus> jonasschnelli: yes, see boost::signal usage in e.g. uiinterface and the existing wallet
 10 2015-01-26 07:53:31 <wumpus> jonasschnelli: I had a branch once where I replaced most wallet-related ifdefs with signals, I also made the wallet register its own RPC calls
 11 2015-01-26 07:54:01 <wumpus> don't know if I still have it though, I didn't continue work on it, deemed that there would be no interest in it
 12 2015-01-26 07:54:07 <jonasschnelli> wumpus, okay. So then you would also agree with using boost:signals2?
 13 2015-01-26 07:54:20 <wumpus> jonasschnelli: what is there to agree, we use it?
 14 2015-01-26 07:55:19 <jonasschnelli> wumpus, i'm just not sure if it would be better to keep the existing implementation and only change the CWallet interface... (in case of risks and testing)
 15 2015-01-26 07:55:42 <phantomcircuit> 2015-01-26 07:42:02 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large
 16 2015-01-26 07:55:44 <phantomcircuit> uh
 17 2015-01-26 07:55:53 <wumpus> phantomcircuit: disk corruption
 18 2015-01-26 07:56:07 <wumpus> jonasschnelli: I'm not sure the new wallet should be constrained by the old interface
 19 2015-01-26 07:56:17 <phantomcircuit> wumpus, maybe but it's a raid1 of intel s3700's
 20 2015-01-26 07:56:24 <phantomcircuit> so that would be a bit strange
 21 2015-01-26 07:56:40 <wumpus> phantomcircuit: usually the corruption happens at the CPU side
 22 2015-01-26 07:56:51 <jonasschnelli> wumpus, okay. I will try the boost::signals2 implementation
 23 2015-01-26 07:56:54 <wumpus> it's very rare for disks to return corrupted data
 24 2015-01-26 07:57:08 <phantomcircuit> server with ECC
 25 2015-01-26 07:58:03 <wumpus> jonasschnelli: ok
 26 2015-01-26 08:11:38 <wumpus> phantomcircuit: I guess it'd be interesting to see what kind of corruption happened, e.g. whether a whole page was wiped, or just e.g. a bitflip
 27 2015-01-26 08:13:20 <wumpus> phantomcircuit: can you maybe upload the blkXXXX.dat file this happensi n?
 28 2015-01-26 08:14:58 <phantomcircuit> i'd like to but im not sure which one it even was
 29 2015-01-26 08:16:31 <wumpus> right, I don't think it even logs the block number in that case, let alone the file :/
 30 2015-01-26 08:20:47 <phantomcircuit> correct
 31 2015-01-26 08:20:49 <wumpus> linearize likely won't catch this either - it verifies the block header hashes, but not the transactions inside the block
 32 2015-01-26 08:20:51 <phantomcircuit> it just kind of explodes
 33 2015-01-26 08:21:07 <wumpus> well it should explode in case of corrupted essential state, that part is fine
 34 2015-01-26 08:21:23 <phantomcircuit> right but it explodes without telling you enough to debug it
 35 2015-01-26 08:21:27 <phantomcircuit> which is not fine :P
 36 2015-01-26 08:21:39 <phantomcircuit> although i guess the expectation is that this is hw failure
 37 2015-01-26 08:21:59 <wumpus> (on the other hand, reading a block from disk is never essential, e.g.  the utxo set maintains the full running state in the databse)
 38 2015-01-26 08:22:20 <wumpus> I expect it to be a hw failure, but the kind of corruption can tell you more about what kind
 39 2015-01-26 08:23:33 <phantomcircuit> possibly a disk controller issue
 40 2015-01-26 08:27:10 <wumpus> anyhow, let's add more informatino for debugging when that happens
 41 2015-01-26 08:41:27 <phantomcircuit> wumpus, wrote a large random file to disk and dropped cache
 42 2015-01-26 08:41:33 <phantomcircuit> checksums matched before and after
 43 2015-01-26 08:41:47 <phantomcircuit> possibly just some weird edge case in the sas controller
 44 2015-01-26 08:46:18 <wumpus> phantomcircuit: I'm about to submit a pull that adds appropriate debugging to GetBlockFromDisk
 45 2015-01-26 09:16:51 <wumpus> phantomcircuit: https://github.com/bitcoin/bitcoin/pull/5710
 46 2015-01-26 09:21:19 <wumpus> if you merge that, then next time the error happens you'll know at least the block file and position, and possibly the full block index (if it went through ReadBlockFromDisk(pindex) )
 47 2015-01-26 09:38:31 <phantomcircuit> wumpus, oooh i bet i mixed headers first with normal
 48 2015-01-26 09:38:57 <wumpus> that shouldn't make any difference to the contents of blocks on disk
 49 2015-01-26 09:39:55 <wumpus> unless a block in the index has an invalid blockpos pointer, causing it to read crap from disk, but then you'd suppose it fails in the header already
 50 2015-01-26 09:40:47 <wumpus> .. or perhaps not, it doesn't read that separately
 51 2015-01-26 10:25:50 <jbrown_> When using estimatefee are you supposed to round up the size of the transaction to the next kilobyte before multiplying by the fee?
 52 2015-01-26 10:44:56 <wumpus> this bug is interesting https://github.com/bitcoin/bitcoin/pull/5706 . multisig address creation fails for >16 addresses
 53 2015-01-26 10:49:53 <Luke-Jr> wumpus: it should fail for >15
 54 2015-01-26 10:50:40 <wumpus> oh, it does? feel free to reply to the issue
 55 2015-01-26 10:51:37 <Luke-Jr> wumpus: P2SH's size limit only allows for IIRC at most 15 keys
 56 2015-01-26 10:54:27 <wumpus> right, I vaguely remember now, we already check the resulting script against MAX_SCRIPT_ELEMENT_SIZE for that though
 57 2015-01-26 10:55:06 <wumpus> the issue is that some assertion before that fails while constructing the script
 58 2015-01-26 10:56:28 <wumpus> in any case, the proposed fix to hardcode a limit at 16 (because the underlying code fails) is not so bad then
 59 2015-01-26 10:58:54 <wumpus> though it may make sense to move the check down to GetScriptForMultisig instead of in the RPC code
 60 2015-01-26 11:05:17 <wumpus> cfields: https://github.com/bitcoin/bitcoin/pull/5658 can go into -trivial
 61 2015-01-26 11:26:39 <Magicking> I was poking around the Script and non-standard transaction and I went across the Solver function in script/standard.cpp
 62 2015-01-26 11:27:39 <Magicking> And so there is only 4 types of relayed-transaction (not counting the datacarrier one) ?
 63 2015-01-26 11:29:05 <Magicking> And if so, what's the best way to include a non std TX in the blockchain without trying to hunt for node that could include my non-TX (but valid TX) ?
 64 2015-01-26 11:29:55 <Magicking> (Like the Transaction puzzle on https://en.bitcoin.it/wiki/Script )
 65 2015-01-26 11:32:11 <wumpus> you'll have to find a miner that wants to include it (e.g. I think you can submit it to eligius), or do your non-standard tx test on testnet
 66 2015-01-26 11:35:41 <Magicking> Damn ! Ty
 67 2015-01-26 11:43:11 <Luke-Jr> Magicking: better route for something you want others to use, is to make it a standard
 68 2015-01-26 11:43:35 <Luke-Jr> or even if others might find it useful, regardless of whether you care if they use it :p
 69 2015-01-26 11:44:57 <Magicking> Yeah, I'm looking on the history of why it's now rejected and NACKed patch :(
 70 2015-01-26 11:45:44 <wumpus> cfields: what's the deal with config.guess and config.sub? I merged https://github.com/bitcoin/bitcoin/pull/5695 , but realized that the other projects (e.g. bitcoin itself, and secp256k1) don't even include these files. Are they normally generated by autoconf?
 71 2015-01-26 11:46:57 <wumpus> Magicking: was it ever a standard transaction type?
 72 2015-01-26 11:47:21 <Magicking> Yeah, it was a modified multisig
 73 2015-01-26 11:48:14 <wumpus> which was standard before? when was it made non-standard?
 74 2015-01-26 11:48:35 <Magicking> I don't think it was ever standard before
 75 2015-01-26 11:49:13 <Magicking> It's just to change the multisig script to add things like NOP to change the hash
 76 2015-01-26 11:50:53 <wumpus> why?
 77 2015-01-26 11:54:42 <Magicking> In case of stolen keys, they have to known how the script is made to spend the coin
 78 2015-01-26 11:55:48 <Magicking> would*
 79 2015-01-26 11:56:26 <wumpus> wouldn't they just steal the redeemscript too?
 80 2015-01-26 11:57:10 <Magicking> wumpus: Not if the redeemscript is generated on the fly given a seed
 81 2015-01-26 11:57:40 <Magicking> The things is to not give the redeemscript but have something that generate it and add random data
 82 2015-01-26 11:58:30 <wumpus> hmm okay. Maybe make a write-up and propose it to the mailing list as a new standard transaction type.
 83 2015-01-26 11:58:42 <Magicking> Oh, ok :)
 84 2015-01-26 11:58:48 <Magicking> I will thank you
 85 2015-01-26 11:59:30 <wumpus> I'd personally think the key is already supposed to be secret, the goal if multisig is already to require multiple keys, so the added security is very little.
 86 2015-01-26 12:05:48 <Magicking> Yup, I'm just paranoid, it might just end with a xkcd 538 problem, an other thing is that *random* data might just be seen as a way to carry data and then be seen as the « datacarrier » tx :(
 87 2015-01-26 12:21:07 <null> can someone tell me the reason why a compressed public key should produce another address than the decompressed key?
 88 2015-01-26 12:22:23 <TheSeven> because the address is basically a hash of the compressed representation then
 89 2015-01-26 12:22:24 <wumpus> because a different input pubkey produces a different 160-bit hash, and thus a different pay-to-PKH address
 90 2015-01-26 12:23:26 <null> wumpus: yeah, i understand the inputs are different. i'm more interested as to why the compressed public key isn't expanded and maps to the same address as the uncompressed key.
 91 2015-01-26 12:24:21 <gmaxwell> null: why do you assume systems should be doing arbritary processing?  why shouldn't a private key one greater also have the same address with your thinking?
 92 2015-01-26 12:24:55 <gmaxwell> There is a transformation to turn any key into any other key, so perhaps there should only be one address at all?
 93 2015-01-26 12:25:03 <wumpus> because that adds overhead beyond simply hashing the serialized pubkey
 94 2015-01-26 12:25:34 <null> okay
 95 2015-01-26 12:25:37 <wumpus> just no reason to
 96 2015-01-26 12:26:10 <null> i just thought there was some technical reason i was not seeing, e.g. causing ambiguity if they both produce the same address
 97 2015-01-26 12:28:19 <wumpus> also it'd have required a change to the scripts, no longer a simple OP_HASH160 could be used but it's need a OP_UNCOMPRESS_PUBKEY OP_HASH160
 98 2015-01-26 12:28:58 <null> makes sense
 99 2015-01-26 12:28:59 <gmaxwell> it's also perfectly possible to make a verifier which never computes the y coorid, so requiring an 'uncompress' would be pure overhead for such an implementation.
100 2015-01-26 12:29:09 <wumpus> which undoes a bit the reduced size that you get from using compressed pubkeys in the first place
101 2015-01-26 12:33:15 <null> i was just reading it in adreas' book and it was talking about the problems for clients which don't yet understand compressed keys because they wouldn't knot what address to look for
102 2015-01-26 12:33:36 <null> so i thought why not have wif and wif-compressed use the same address, but thanks for clearing that up guys
103 2015-01-26 12:33:47 <wumpus> this is 2015 and there are still clients that don't understand compressed keys?
104 2015-01-26 12:37:32 <wumpus> eh invalidateblock and reconsiderblock are in the RPC table *twice*, that can't be good
105 2015-01-26 12:42:16 <wumpus> ok, doesn't hurt, the last definition will take precedence
106 2015-01-26 15:10:13 <jonasschnelli> wumpus, is there a reason why CValidationInterface is not named CWalletInterface?
107 2015-01-26 15:11:41 <wumpus> because it can be subscribed to by anything interested in validation progress, not just wallets
108 2015-01-26 15:11:45 <sipa> because non-wallets can use it
109 2015-01-26 15:11:59 <wumpus> also CWalletINterface is confusing, it sounds like an interface *to* a wallet
110 2015-01-26 15:12:00 <sipa> for example -blocknotify should be retrofitted to use it
111 2015-01-26 15:12:29 <wumpus> jonasschnelli: the point is to make main.cpp completely oblivious of what is done with it's results, it doesn't care whether a wallet is listening or something else
112 2015-01-26 15:14:58 <jonasschnelli> wumpus, sipa, then i will create another interface for wallet only interaction, things like 'extendHelpMessage()' or 'extendRPCCommands()' won't make sense to add it in the CWalletInterface
113 2015-01-26 15:15:12 <jonasschnelli> s/CWalletInterface/CValidationInterface
114 2015-01-26 15:15:38 <wumpus> yes, keep RPC stuff isolated from the validation interface please
115 2015-01-26 15:16:15 <wumpus> if your point is to make RPC more modular, RPC should just methods to (un)register command handlers
116 2015-01-26 15:16:26 <jonasschnelli> wumpus, yes. makes sense. I just saw that only the miner does also use the Validation interface and thought about renaming it to CWalletInterface...
117 2015-01-26 15:18:04 <sipa> the exactly renamed it from CWalletInterface to CValidationInterface because we were going to use it in the miner code
118 2015-01-26 15:19:04 <wumpus> yes
119 2015-01-26 15:57:10 <helo> what should be the bottleneck during "Verifying last 288 blocks at level 3" at startup?
120 2015-01-26 15:57:25 <gmaxwell> helo: can you rephrase the question?
121 2015-01-26 15:57:33 <helo> my disk and CPU seem relatively under-utilized
122 2015-01-26 15:58:00 <gmaxwell> helo: if you're on a spinning disk it spends a bunch of time seeking.
123 2015-01-26 15:58:07 <helo> okay, that must be it
124 2015-01-26 16:28:04 <wumpus> helo: time to get out the profiler?
125 2015-01-26 16:28:23 <Ostkaka> now is to late
126 2015-01-26 16:28:24 <Ostkaka> ;q
127 2015-01-26 16:31:43 <wumpus> likely depends on the check level, e.g. at checklevel 3 it reads undo data, applies this to results read from the utxo database and keeps the result in memory, building quite a large 'diff' data structure
128 2015-01-26 16:34:03 <helo> i'll be unsophisticated and see how an SSD performs
129 2015-01-26 16:34:07 <wumpus> runtime is likely bound by the number of new outputs in the checked blocks
130 2015-01-26 16:34:26 <wumpus> well, that's easy to answer, it performs better
131 2015-01-26 16:36:29 <wumpus> you could also try reading the whole utxo set into memory first, probably it'd be really fast then as you can avoid the seeking
132 2015-01-26 16:36:57 <wumpus> (at the expense of a few GB of memory, of course, it blows up the database quite a bit)
133 2015-01-26 16:41:35 <wumpus> (also currently the dbcache size determines how deep it will actually check at checklevel 3, so naively,increasing the db size will seem to make it slower :-)
134 2015-01-26 16:41:57 <helo> hmm
135 2015-01-26 18:00:30 <michagogo> Hm, reading the logs from earlier
136 2015-01-26 18:00:45 <michagogo> Didn't everything become standard in P2SH?
137 2015-01-26 19:22:42 <gmaxwell> sipa: https://github.com/bitcoin/bitcoin.org/pull/721
138 2015-01-26 20:18:10 <cfields> wumpus: yes, those are generated by autoconf
139 2015-01-26 20:18:41 <cfields> wumpus: but since we depend on them before we bootstrap, i added them separately there. otherwise things would get circular and confusing
140 2015-01-26 20:18:50 <cfields> s/generated by/copied by/
141 2015-01-26 20:19:28 <wumpus> okay
142 2015-01-26 20:19:48 <wumpus> yes, makes sense, I was just wondering
143 2015-01-26 20:20:45 <cfields> so yea, after-the-fact ACK on that one.
144 2015-01-26 20:46:06 <cfields> jtimon: for backlog, i pushed a rough version of what i've been working on into the consensus-refactor branch
145 2015-01-26 20:46:17 <cfields> it's on top of some of your work
146 2015-01-26 22:27:03 <op_mul> "< null> i was just reading it in adreas' book and it was talking about the problems for clients which don't yet understand compressed keys because they wouldn't knot what address to look for" < for those who haven't read it, that part of "masting bitcoin" is particularly bad, expect lots of confused people in here with questions about that
147 2015-01-26 22:28:47 <op_mul> it has some of the basics correct, but it backs this up with absolutely no real world understanding and outstandingly useless comments like "This compressed public key corresponds to the same private key, meaning that it is generated from the same private key."
148 2015-01-26 22:51:46 <jcorgan> sounds legit
149 2015-01-26 23:59:43 <Luke-Jr> hm