1 2015-03-27 00:00:16 <familiar_> so the BIP solves this by prefacing the chain with the index of the cosigner (xpubkeys sorted lexicographically)
  2 2015-03-27 00:01:35 <ThomasV> so each of them has its own set of addresses
  3 2015-03-27 00:02:17 <familiar_> In a way, yes. So by looking at who created the half-signed transaction they can figure out the path they need to derive their pub+prv keys
  4 2015-03-27 00:02:42 <ThomasV> ic
  5 2015-03-27 00:03:56 <ThomasV> how do they know who created the hals-signed tx?
  6 2015-03-27 00:04:02 <ThomasV> half
  7 2015-03-27 00:04:04 <gmaxwell> having to search for 'who created' would be quite costly, much better to send metadata with the transaction. (can just be in the space for the missing signatures if you want)
  8 2015-03-27 00:04:46 <familiar_> Yes, I was thinking of that. My ideal would be to find a way without sending metadata. But realistically most bitcoin txn's need to have associated metadata anyway (what are you buying?)
  9 2015-03-27 00:05:03 <ThomasV> gmaxwell: looking at the signature would be costly yes
 10 2015-03-27 00:05:30 <familiar_> One way is, to sort the pubkeys in the redeem-script in the same order as the purpose pubkey's they had previously shared
 11 2015-03-27 00:05:58 <familiar_> then looking at which signature is already in the raw transaction they can find out who signed it
 12 2015-03-27 00:06:09 <familiar_> (Does this work btw?)
 13 2015-03-27 00:06:32 <ThomasV> familiar_: electrum packs metadata in the raw tx, see https://electrum.orain.org/wiki/Serialization_format_of_transactions
 14 2015-03-27 00:06:59 <ThomasV> that's how the cosigner pool plugin works, btw
 15 2015-03-27 00:07:46 <familiar_> Oh. Sweet
 16 2015-03-27 00:07:55 <familiar_> Thanks for that
 17 2015-03-27 00:10:21 <ThomasV> familiar_: also there is a BIP somewhere that proposes to sort pubkeys in lexicographic order, which is what electrum does
 18 2015-03-27 00:10:33 <ThomasV> bip45 violates that
 19 2015-03-27 00:11:09 <familiar_> I don't think it does
 20 2015-03-27 00:11:31 <familiar_> The section "Address Generation Procedure" says this: They do this by deriving the public key in each of the different trees, but using the same path. They can then generate the multisig script (by lexicographically sorting the public keys) and the corresponding p2sh address. In this way, each path corresponds to an address, but the public keys for that address come from different trees.
 21 2015-03-27 00:11:34 <gmaxwell> if the pubkeys (thus sigs) in a single transaction end up in anything but lexicographic order, it does.
 22 2015-03-27 00:11:36 <ThomasV> hmm, right, it does not
 23 2015-03-27 00:11:59 <familiar_> So I guess my idea would be non-standard, and better not to do. I'll stick with metadata
 24 2015-03-27 00:16:27 <phantomcircuit> hmm seems like there isn't much seeding /dev/random in the kernel anymore
 25 2015-03-27 01:12:54 <fanquake> ;;blocks
 26 2015-03-27 01:12:55 <gribble> 349403
 27 2015-03-27 01:13:21 <Luke-Jr> 
ACTION grumbles about anti-modularity movements

 28 2015-03-27 01:18:51 <akstunt600> lol
 29 2015-03-27 01:31:31 <maaku> 
ACTION feeds devrandom into his entropy pool

 30 2015-03-27 01:35:07 <Luke-Jr> 
ACTION is looking at sipa and cfields with their embedded AES code that need not be part of Bitcoin Core. :p

 31 2015-03-27 01:37:22 <phantomcircuit> Luke-Jr, ?
 32 2015-03-27 01:39:01 <fanquake> phantomcircuit https://github.com/bitcoin/bitcoin/pull/5949
 33 2015-03-27 02:07:19 <akstunt600> oh joy vm inside a vm inside a vm
 34 2015-03-27 02:07:25 <akstunt600> what has the world become
 35 2015-03-27 02:54:14 <Cryo> is there no way to pre-seed 0.10.0 with the torrent anymore? even google fu is failing me
 36 2015-03-27 02:54:32 <Cryo> (on mac)
 37 2015-03-27 02:59:03 <gmaxwell> Cryo: it's possible but it is usually slower than not.
 38 2015-03-27 03:01:56 <Cryo> it was ignoring whereever I put it
 39 2015-03-27 03:02:28 <Cryo> so I'm doing the oh, let's download the chain from like 1 peer.
 40 2015-03-27 03:02:46 <Cryo> sending to 8 though!
 41 2015-03-27 03:05:34 <Luke-Jr> … does this "Thy Shizzle" guy realise he's arguing for strong anti-reuse? :P
 42 2015-03-27 03:05:47 <gmaxwell> Luke-Jr: lol yea, I saw that and was like wtf!
 43 2015-03-27 03:05:56 <gmaxwell> he's probably wrong, ... but if not, then uhhh.
 44 2015-03-27 03:09:51 <phantomcircuit> gmaxwell, is there any reason not to have the sender (transaction creator) set a maximum ttl?
 45 2015-03-27 03:10:19 <phantomcircuit> ie not something a recipient can rely on but something a sender can
 46 2015-03-27 03:10:28 <phantomcircuit> locktime but in reverse
 47 2015-03-27 03:10:36 <Luke-Jr> phantomcircuit: reorgs
 48 2015-03-27 03:11:15 <phantomcircuit> Luke-Jr, im not seeing the problem
 49 2015-03-27 03:11:42 <phantomcircuit> in a large reorg a ttl would maybe guarantee the tx isn't included again but uh
 50 2015-03-27 03:11:44 <phantomcircuit> so?
 51 2015-03-27 03:11:45 <Luke-Jr> phantomcircuit: a very limited part of the security model is that even if an innocent reorg does happen sometimes, you can count on a miner just mining the tx in a later block assuming the sender is innocent
 52 2015-03-27 03:12:04 <gmaxwell> Luke-Jr: I'll reply.
 53 2015-03-27 03:12:09 <Luke-Jr> if an innocent person suddenly is guilty of fraud if he doesn't reissue, …
 54 2015-03-27 03:12:36 <phantomcircuit> Luke-Jr, breach of contract at worst
 55 2015-03-27 03:12:44 <phantomcircuit> fraud requires intent how should you have known?
 56 2015-03-27 03:12:59 <Luke-Jr> ok, but point is that shouldn't happen :p
 57 2015-03-27 03:13:45 <gmaxwell> phantomcircuit: because it's not reorg safe, which means that any censorship attacks are much more powerful, and there may be weird incentives against convergence or towards creating forks.
 58 2015-03-27 03:15:11 <gmaxwell> No-reorgable coins are also less fungible than other coins, e.g. if they're near the limit they're exposed. A SPV client can't easily tell when there was a less fungible coin in the recent history. This is one of the advantages of not allowing coinbases to be spent for 100 blocks... they're less fungible, but since they can't show up in blocks spv clients don't need to figure that out for themselves.
 59 2015-03-27 03:16:37 <phantomcircuit> hmm
 60 2015-03-27 03:16:38 <phantomcircuit> ok
 61 2015-03-27 03:39:27 <berndj> kinda meta: why aren't there [PATCH] messages on -dev? some other projects i'm familiar with seem to get reasonable code review engagement on their mailing lists
 62 2015-03-27 03:40:16 <gmaxwell> berndj: because github is used (it can send you emails if you like)
 63 2015-03-27 03:41:07 <berndj> gmaxwell, so basically because bitcoin is a 2010-era project while GCC is a 1990-era project?
 64 2015-03-27 03:41:56 <berndj> (i mean that in the sense that newer tools are presumably better, not the sense that "bring back the old days, and get off my lawn")
 65 2015-03-27 03:42:59 <gmaxwell> I don't think the tools are better, in fact-- there is no real facility for me to filter people I don't want to hear from or priortize things that are urgent; or to automatically fill a work queue from the patch flow. But they have a shallower learning curve, which is certantly desirable.
 66 2015-03-27 03:44:56 <berndj> my other thoughts were: the audience is different; on bitcoin-dev i suspect you'd get more non-code-review bikeshedding type responses due to bitcoin's crypto crank magnetism, compared to, say, GCC which is just compiler nerds
 67 2015-03-27 03:46:34 <gmaxwell> if that were the goal github wouldn't be the choice. The mailing list is a barrier for some, for better or worse (usually worse). We've certantly recieved antagonistic responses on github from people that I doubt have ever used a mailing list. (and then we really have no good way to block them).
 68 2015-03-27 03:46:46 <Cryo> at least bitcoin doesn't corrupt your wallet because it generates invalid op codes for your architecture due to a corner-case bug.
 69 2015-03-27 03:48:36 <gmaxwell> hm?
 70 2015-03-27 03:49:53 <Cryo> adding some gcc hate to the convo :)
 71 2015-03-27 03:50:25 <gmaxwell> oh, please take the OT outside.
 72 2015-03-27 03:50:50 <Cryo> ehhehe
 73 2015-03-27 03:52:03 <berndj> Cryo: for extra credit, figure out what compiler bugs mean for a consensus system
 74 2015-03-27 03:52:51 <Cryo> the US electronic voting system, Alex.
 75 2015-03-27 03:53:06 <Cryo> but alas, OT. so I'll be quiet again
 76 2015-03-27 03:58:48 <sipa> Luke-Jr: pfft it's a trivial non-aging piece of code; imho the burden of a dependency is worse
 77 2015-03-27 03:58:58 <Cryo> 8 (In: 0 / Out: 8) this is no excuse in this
 78 2015-03-27 03:59:18 <Luke-Jr> sipa: we need a dependency for TLS support anyway.. and probably anything with TLS has AES
 79 2015-03-27 03:59:20 <Cryo> I also never seem to see an ipv6 peer
 80 2015-03-27 03:59:48 <Luke-Jr> Cryo: #bitcoin for user support
 81 2015-03-27 04:00:05 <Cryo> k
 82 2015-03-27 04:00:17 <sipa> Luke-Jr: yeah, it is just the wallet, where i care a bit less
 83 2015-03-27 04:00:37 <sipa> Luke-Jr: but having a low-deiendency bitcoind is already nice too
 84 2015-03-27 04:01:16 <Luke-Jr> sipa: low-dependency > high-dependency > embedded-dependency
 85 2015-03-27 04:01:42 <sipa> Luke-Jr: it's not black and white
 86 2015-03-27 04:02:10 <Luke-Jr> in this case, I think it is?
 87 2015-03-27 04:03:41 <sipa> let's agree to disagree then
 88 2015-03-27 04:03:47 <gmaxwell> Luke-Jr: bitcoin core does not need TLS.
 89 2015-03-27 04:04:09 <Luke-Jr> gmaxwell: it needs TLS for payment protocol; AES is also only needed for wallet
 90 2015-03-27 04:04:56 <Luke-Jr> (that is, I don't think there is any situation where we need AES but not TLS)
 91 2015-03-27 04:05:07 <gmaxwell> Luke-Jr: payment protocol is only used with -qt. And OpenSSL is a monthly security firedrill with unreviewable changes.
 92 2015-03-27 04:06:07 <Luke-Jr> gmaxwell: eh, we should probably consider it a bug that payment protocol isn't available via RPC (?); also, I'm not saying we need to or should keep OpenSSL
 93 2015-03-27 04:06:51 <Luke-Jr> 
ACTION ponders if Qt can use other providers for TLS

 94 2015-03-27 04:06:53 <gmaxwell> Luke-Jr: I think you are, in effect.
 95 2015-03-27 04:09:17 <Luke-Jr> gmaxwell: I was thinking more like GnuTLS + libgcrypt as an alternative for dropping OpenSSL. but it seems Qt doesn't make such things practical :<
 96 2015-03-27 04:10:43 <Luke-Jr> (we could probably still use libgcrypt for AES, just we're stuck with OpenSSL on GUI)
 97 2015-03-27 04:13:01 <gmaxwell> Luke-Jr: it's likely that AES will eventually make its way into the p2p protocol if not consensus at some point in any case; there really is no reason to take yet another dependency on a bug infested unmaintanable crypto library (and I'd basically apply this moniker to all of them, some are just worse than others) for a trivial piece of code.
 98 2015-03-27 04:17:57 <petertodd> ~.~.~.~.
 99 2015-03-27 04:18:13 <phantomcircuit> lold
100 2015-03-27 04:18:14 <petertodd> lol, stupid ssh
101 2015-03-27 04:18:18 <gmaxwell> petertodds_computer#
102 2015-03-27 04:18:38 <petertodd> workshopcafes_internet_connection#
103 2015-03-27 04:19:29 <Luke-Jr> TIL petertodd SSHs from untrusted PCs?
104 2015-03-27 04:20:57 <petertodd> nah, this is my trusted-modulo-nsa thinkpad
105 2015-03-27 04:26:05 <kanzure> ls /
106 2015-03-27 04:27:26 <kanzure> mail kanzure@gmail.com -f `cat /tmp/arm_and_mouse/`
107 2015-03-27 04:27:28 <kanzure> gah why is this not working
108 2015-03-27 04:27:45 <kanzure> s/cat/ls
109 2015-03-27 05:09:16 <StephenM347> Have any versions of the software penalized nodes for forwarding pre-mature spends of coinbase transactions? I've looked through a few and couldn't find any
110 2015-03-27 05:10:25 <StephenM347> I'm participating in a discussion on whether or not it would be possible to allow relaying of pre-mature spends of coinbase transactions, with the usual rate limiting and DoS prevention applied to how many transactions the client will store
111 2015-03-27 05:12:03 <Luke-Jr> no; I would say there's no value in relaying them prior to maturity, though
112 2015-03-27 05:44:20 <StephenM347> Luke-Jr: I agree there's not a huge gain from it, only use case I can think of would be to have pools broadcast their transaction early to prove their intent to not steal the funds of users
113 2015-03-27 05:44:40 <Luke-Jr> StephenM347: pools should never hold the funds of their users in the first place
114 2015-03-27 05:44:40 <StephenM347> but even that may be stretching it, pools are working fine now
115 2015-03-27 05:45:50 <StephenM347> Luke-Jr: Ah, right, because the coinbase can set the payouts to go right to the miners. Alright, that settles it, I can think of no good use cases
116 2015-03-27 05:49:22 <wumpus> Luke-Jr: "eh, we should probably consider it a bug that payment protocol isn't available via RPC (?)" no, it's not, that can just as well be handled by an external library, let's not import every high level concern into bitcoind
117 2015-03-27 05:49:51 <Luke-Jr> well, lots of RPC stuff can be. but fair enough
118 2015-03-27 05:50:14 <wumpus> right, there is already too much RPC stuff
119 2015-03-27 05:51:22 <gmaxwell> Luke-Jr: shouldn't be RPC, should be an external utility. (which the GUI should call too; since ... having your wallet make outbound network connections to untrusted hosts... baad idea. :) )
120 2015-03-27 05:51:58 <wumpus> the pure utility functions were a mistake too, in that regard, but at least they don't drag in SSL dependencies again after we'd tried so hard to get rid of them.
121 2015-03-27 05:56:16 <wumpus> there's not just the outbound network connection to deal with, the payment request code uses openssl incantations for verifying the payment request signatures too
122 2015-03-27 06:01:15 <wumpus> outsourcing it to an external utility would make sense, that would be the only thing depending on openssl then
123 2015-03-27 06:07:08 <akstunt600> YOO
124 2015-03-27 06:07:19 <akstunt600> What about mapreduce for scalability?
125 2015-03-27 06:07:35 <akstunt600> and then something like google SPDY
126 2015-03-27 06:07:36 <akstunt600> ?
127 2015-03-27 06:07:52 <akstunt600> i know its closed src stil kinda and it requires a rethink for a min
128 2015-03-27 06:08:23 <akstunt600> but like cant this bedone and cant things be drastically inmpoved with some funk of those techs put together?
129 2015-03-27 06:09:27 <akstunt600> spdy is clsd src still mapreduce is open*
130 2015-03-27 06:11:30 <akstunt600> like little clusters of full nodes?
131 2015-03-27 06:11:33 <akstunt600> idk
132 2015-03-27 06:20:15 <buZz> ;;seen btcdrak
133 2015-03-27 06:20:16 <gribble> btcdrak was last seen in #bitcoin-dev 9 weeks, 6 days, 18 hours, 18 minutes, and 51 seconds ago: <btcdrak> have you seen the latest sensational post on coindesk about backing private keys? /research-hackers-install-backdoor-bitcoin-cold-storage/
134 2015-03-27 06:20:28 <buZz> long ago :(
135 2015-03-27 06:45:29 <akstunt600> SPDY looks cool but closed src
136 2015-03-27 06:46:06 <akstunt600> and i guess mapreduce doesnt help at all. just thinking of their use of SPDY for big data center nodes
137 2015-03-27 06:47:41 <gmaxwell> akstunt600: whatever you're talking about is offtopic here. please take it elsewhere.
138 2015-03-27 06:48:34 <akstunt600> ok, just thinking about that ssl thing and demodularization
139 2015-03-27 06:48:46 <akstunt600> but w.e
140 2015-03-27 06:48:52 <wumpus> this has as much relevance to bitcoin as asteroid mining
141 2015-03-27 06:58:42 <akstunt600> Well i mean its based on problems with tcp
142 2015-03-27 06:59:19 <akstunt600> or i think i was thinking of quic and something else ooops
143 2015-03-27 07:00:02 <wumpus> yes it's fine, take it to #bitcoin at least
144 2015-03-27 07:00:29 <akstunt600> yup np
145 2015-03-27 08:04:27 <wumpus> jonasschnelli: we should make a decision re: the console font https://github.com/bitcoin/bitcoin/pull/5898
146 2015-03-27 08:04:45 <wumpus> jonasschnelli: no use in leaving such a trivial pull open for so long
147 2015-03-27 08:18:37 <jonasschnelli> wumpus, IMO 5898 should go in as it is.
148 2015-03-27 08:18:54 <wumpus> I don't like the crazy large font that i get
149 2015-03-27 08:19:20 <wumpus> it makes the RPC console all but unusable to me
150 2015-03-27 08:19:30 <jonasschnelli> wumpus, hmm... right. Do you get this with the newest version of the PR (removing the font size completely)?
151 2015-03-27 08:19:37 <wumpus> yes
152 2015-03-27 08:19:48 <wumpus> as I mentioned in my post that happens with both font-size:1em and no font size at all.
153 2015-03-27 08:20:51 <jonasschnelli> I tried serval settings. Like setting the font to pt metrics. Like 12pt. But it produces strange differences between platform and HiDPI nonHDPI
154 2015-03-27 08:20:52 <wumpus> would be better to remove the font specification completely
155 2015-03-27 08:21:24 <jonasschnelli> But removing monospace would not shrink the font?
156 2015-03-27 08:21:35 <wumpus> it makes the font look sane here
157 2015-03-27 08:21:46 <wumpus> there's no reason it needs to be monospace
158 2015-03-27 08:22:11 <jonasschnelli> okay... would be fine for me. But i'd like to test this first on OSX and win. Will do today and change the PR and report there.
159 2015-03-27 08:22:38 <wumpus> (there would be if we'd, eg used it to align columns, but it's just json output)
160 2015-03-27 08:23:10 <wumpus> the default font with the default font size is the most likely to be readable
161 2015-03-27 08:23:37 <wumpus> on any platform
162 2015-03-27 08:24:18 <jonasschnelli> yes. Agreed. I don't have a strong position there. It should just be reable on any system with any configuration. Removing any font styles is probably the best way then.
163 2015-03-27 08:24:26 <wumpus> exactly
164 2015-03-27 08:24:34 <jonasschnelli> okay. Will do and report.
165 2015-03-27 08:24:59 <jonasschnelli> Regarding 5503: wasn't the signing always there? Or how should we calculate fees without signing?
166 2015-03-27 08:25:49 <wumpus> just use the worst-case size of the signature
167 2015-03-27 08:26:06 <wumpus> I was thinking of the coin control case. Right now we have a lot of duplicated code, because coin control needs to compute the transaction size without actually signing.
168 2015-03-27 08:27:28 <jonasschnelli> Okay. Will investigate there and see how the fee can be calculated without signing.
169 2015-03-27 08:27:37 <wumpus> signing and then throwing away the signature is suboptimal in any case; I mean, that requires the encryption keys and such
170 2015-03-27 08:27:53 <jonasschnelli> wumpus, yes. Agreed.
171 2015-03-27 08:31:25 <jonasschnelli> wumpus, there is also the issue with the "reservekey" in fundrawtransaction. When you "fund" a rawtx it will use reserve a CReserveKey from your pool.
172 2015-03-27 08:31:46 <jonasschnelli> But there is currently no option to release the reserved key
173 2015-03-27 08:31:58 <wumpus> right, that sounds suboptimal, too
174 2015-03-27 08:32:43 <gmaxwell> it shouldn't sign to get the size, thats foolish and slow. The maximum size is knowable in advance, and is accurate to within a byte with very high probablity.
175 2015-03-27 08:32:44 <jonasschnelli> wumpus, i could add a parameter for fundrawtransaction where you could give in your rawtx and say "i'd like to release the reserves key"...
176 2015-03-27 08:33:03 <wumpus> jonasschnelli: but does it need a reserve key at all?
177 2015-03-27 08:33:13 <wumpus> jonasschnelli: what does it need the key for if not signing?
178 2015-03-27 08:33:15 <jonasschnelli> wumpus, for the change output?
179 2015-03-27 08:34:00 <gmaxwell> any key which has been made visible to the user should remain reserved. its no different than if you 'getnewaddress' then just did nothing with it.
180 2015-03-27 08:34:08 <wumpus> it adds a change output for you? I thought the idea with raw transactions is to do that yourself w/  getrawchangeaddress
181 2015-03-27 08:34:18 <gmaxwell> it's not like keys are some scarce resource.
182 2015-03-27 08:34:31 <wumpus> but maybe I'm misunderstanding fundrawtransaction, thought it provides inputs
183 2015-03-27 08:34:49 <gmaxwell> wumpus: inputs may imply change, and thats not known until the inputs are provided.
184 2015-03-27 08:35:06 <wumpus> gmaxwell: ok, right
185 2015-03-27 08:35:57 <jonasschnelli> imo adding the change output is necessary to avoid insane fee txs.
186 2015-03-27 08:36:17 <wumpus> yes
187 2015-03-27 08:36:51 <jonasschnelli> what about adding a possibility to "clear" the funded rawtx? Like (conceptual) "fundrawtransaction <RAWTX> return=1"?
188 2015-03-27 08:37:13 <wumpus> my quip there is that fundrawtransaction then potentially needs an unlocked wallet, as it may have to generate a new key
189 2015-03-27 08:37:26 <jonasschnelli> or we could follow gmaxwell's advice that keys aren't a scarce ressource.
190 2015-03-27 08:37:41 <wumpus> which is something you'd expect for signtransaction but not for fund...
191 2015-03-27 08:37:59 <gmaxwell> jonasschnelli: it's not acceptable to release a key which could have been seen by the user, we do not have a ungetnewaddress nor have we ever felt the lack of one was a loss. :)
192 2015-03-27 08:38:00 <wumpus> I fully agree with him there, scarcity is not an issue
193 2015-03-27 08:38:17 <jonasschnelli> gmaxwell, yes. Right. return=1 is a bad design... truly.
194 2015-03-27 08:38:30 <wumpus> maybe have the user provide his own change address?
195 2015-03-27 08:38:39 <wumpus> hm, or maybe not
196 2015-03-27 08:38:53 <jonasschnelli> wumpus, but fundrawtransaction IMO always needs a unlocked wallet because the main reason for it is to add funds from your wallet to the tx.
197 2015-03-27 08:38:57 <wumpus> lots of scope for abuse there.
198 2015-03-27 08:38:59 <gmaxwell> wumpus: it really should be automatic or it would be pretty hard to use.
199 2015-03-27 08:39:06 <gmaxwell> jonasschnelli: huh?! why should it be unlocked?!
200 2015-03-27 08:39:21 <wumpus> gmaxwell: to get a change address (which may not be available in the keypool)
201 2015-03-27 08:39:22 <jonasschnelli> gmaxwell, Right. Not unlocked.
202 2015-03-27 08:39:41 <jonasschnelli> if the pool is not filled up, it might need a unlocking.
203 2015-03-27 08:39:47 <gmaxwell> wumpus: same issue arises for getnewaddress or mining.
204 2015-03-27 08:39:54 <wumpus> sure, it'd just fail in that case
205 2015-03-27 08:40:14 <jonasschnelli> these edge cases needs to be covered in unit/rpc tests!
206 2015-03-27 08:40:21 <wumpus> I just think it's counterintuitive for a RPC call called *fundrawtransaction*, I'd expect it to jus tselect inputs, but anyhow
207 2015-03-27 08:40:33 <wumpus> it makes sense thay way
208 2015-03-27 08:40:44 <gmaxwell> wumpus: perhaps a bit, but omg all my coins are gone is more counterintutive. :)
209 2015-03-27 08:40:55 <jonasschnelli> hmm... what about adding a option "add-change-output(boolean)"?
210 2015-03-27 08:41:28 <gmaxwell> jonasschnelli: What would turning that off do? destroy your coins?
211 2015-03-27 08:41:46 <wumpus> no, let's just make it select a change output, you've made your point and it's ok
212 2015-03-27 08:42:14 <jonasschnelli> gmaxwell, good question. Maybe to get more control and avoid topping up/unlocking your wallet? But right. It won't make that much of a sense.
213 2015-03-27 08:42:38 <jonasschnelli> But right. The added change output is probably the right thing..
214 2015-03-27 08:42:45 <wumpus> just make it fail when it cannot get a key, like the other calls
215 2015-03-27 08:42:59 <gmaxwell> jonasschnelli: I just mean what would it possibly do there? if you tell it no what else can it do when the inputs don't match exactly? I guess fail?
216 2015-03-27 08:43:56 <jonasschnelli> Okay. So i'll then fix the signing/fee-calc issue and add some unit tests (maybe fixes) for the case where no CReserveKey could get reserved.
217 2015-03-27 09:01:44 <jonasschnelli> gmaxwell, wumpus: but how exact would be the fee calculation be without signing. I mean the rawtx could containing multiple output and the signature could be way larger then a "normal" signature. Taking the max signature size sounds also not after a good idea. Any ideas?
218 2015-03-27 09:02:30 <wumpus> " the signature could be way larger then a "normal" signature" how? aren't ECDSA signatures well bounded?
219 2015-03-27 09:03:30 <wumpus> 2*256 bits, right? plus DER nonsense.
220 2015-03-27 09:05:21 <gmaxwell> jonasschnelli: the signature has a precise upper size, each byte smaller happens with probablity 1/256^n. so in practices you will not observe more than a couple bytes smaller.
221 2015-03-27 09:05:30 <wumpus> 73 is the maximum length, enforced by BIP66
222 2015-03-27 09:06:12 <gmaxwell> you know the number of outputs before selecting inputs, and the number of inputs when selecting them.
223 2015-03-27 09:06:52 <gmaxwell> 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.
224 2015-03-27 09:07:10 <gmaxwell> you do have to check what you're actually signing for but you know all that.
225 2015-03-27 09:07:20 <gmaxwell> (you, being the wallet, of course)
226 2015-03-27 09:10:17 <gmaxwell> e.g. signing in the input selection loop can be replaced by something that just checks the pubkey types and adds the apropriate number of bytes to the actual size
227 2015-03-27 10:47:42 <wumpus> github is flakey today, pushes and pulls time out all the time
228 2015-03-27 10:51:45 <wumpus> ah, they're under DDoS attack https://status.github.com/
229 2015-03-27 12:32:40 <waxwing> what does the 44/45 in the signature mean? (30 45 etc)
230 2015-03-27 12:45:23 <sipa> length of the compound element with the r and s values that follows (der encoding)
231 2015-03-27 12:47:40 <waxwing> sipa: doh! so obvious :) thanks.
232 2015-03-27 12:53:48 <waxwing> gitcoin: distributed git with proof of work. to mine, make so many PRs/commits that you create a hash less than the target.
233 2015-03-27 14:35:43 <dgenr8> <wumpus> the pure utility functions were a mistake too <- current-milestone fundrawtransaction work requires use of pure utility functions
234 2015-03-27 14:37:01 <wumpus> dgenr8: use of pure utility functions is never required, you could use a client-side implementation
235 2015-03-27 14:37:59 <dgenr8> bitcoin-tx has cloned a lot of code from the RPC which is not ideal (dual maintenance)
236 2015-03-27 14:38:25 <wumpus> it's migrating there
237 2015-03-27 14:38:46 <wumpus> bitcoin-tx is pure client-side
238 2015-03-27 14:39:50 <dgenr8> wumpus: maybe the tests in 5503 shouldn't use pure utility functions then
239 2015-03-27 14:40:21 <dgenr8> though it seems to read and work nicely
240 2015-03-27 14:40:29 <wumpus> well as long as they still exist, there is nothing wrong with testing them
241 2015-03-27 14:40:57 <wumpus> eventually various things could move to a python-based implementation, I have some local code for generating blocks and transactions and such
242 2015-03-27 14:41:35 <wumpus> (or use bitcoin-pythonlib, but that dependency would be overkill for a few tests)
243 2015-03-27 14:42:04 <dgenr8> createrawtransaction is not so much being tested, as it is being used in a fundrawtransaction test
244 2015-03-27 14:42:56 <wumpus> using it is a good way to test it, though
245 2015-03-27 14:43:08 <wumpus> if it breaks it breaks the test
246 2015-03-27 14:44:06 <wumpus> we could also use bitcoin-tx there, that certainly needs better tests
247 2015-03-27 14:44:12 <dgenr8> which is the bigger reason to freeze utility RPC's? the RPC-ness, or the utility-ness?
248 2015-03-27 14:44:47 <wumpus> it burdens the API with functionality that could be done locally, with less overhead
249 2015-03-27 14:45:35 <dgenr8> ie what if the signing code moves to a shared library and the RPC wrapper becomes more general
250 2015-03-27 14:46:29 <wumpus> executing code in another process, over a local network connection, with all the overhead of that is unnecessary if it doesn't require any of bitcoind's state. In retrospect there should have been a simple API to access bitcoind's internal state, and the rest would be built on top of that, instead of stashing it all in the daemon.
251 2015-03-27 14:46:57 <wumpus> a shared library would be a good place for utility functions
252 2015-03-27 14:47:57 <wumpus> the RPC-ness is the problem, there''s nothing wrong with utility functions in themselves
253 2015-03-27 14:51:50 <dgenr8> agreed.  i think it would be ok to add locktime to createrawtransaction though.  it's almost more of a bugfix since the wallet now generates locked txes.
254 2015-03-27 15:01:17 <buZz> whats the difference between 'progress' and 'log2_work' in the output of syncing?
255 2015-03-27 15:01:48 <wumpus> progress is (approximately) the progress scaled to 0..1
256 2015-03-27 15:01:53 <wumpus> log2_work is, well, log2 work
257 2015-03-27 15:02:17 <buZz> is log2_work a different view of the same?
258 2015-03-27 15:03:43 <wumpus> it's the 2log of the sum of total work
259 2015-03-27 15:03:56 <buZz> ahh
260 2015-03-27 15:04:09 <buZz> so no, not related to syncing progress at all :P
261 2015-03-27 15:04:16 <buZz> ty ^_^
262 2015-03-27 15:21:00 <Luke-Jr> 0.10 ARM node self-corrupted with bad_alloc exception (which is a regular occurrence); anyone want me to save the debug.log or anything?
263 2015-03-27 15:21:11 <Luke-Jr> (0.10 branch, doing IBD)
264 2015-03-27 15:21:23 <wumpus> what kind of corruption?
265 2015-03-27 15:22:00 <wumpus> I had problems like that too with 0.10, but not with master, it's also possible that this is a problem already solved on the 0.10 branch
266 2015-03-27 15:22:22 <Luke-Jr> 2015-03-27 15:08:54 ERROR: VerifyDB() : ⁂ coin database inconsistencies found (last 289 blocks, 0 good transactions before that)
267 2015-03-27 15:22:32 <Luke-Jr> 2015-03-27 15:03:25 ERROR: DisconnectBlock() : undo data overwriting existing transaction
268 2015-03-27 15:22:34 <Luke-Jr> 2015-03-27 15:03:25 ERROR: DisconnectBlock() : added transaction mismatch? database corrupted
269 2015-03-27 15:22:40 <Luke-Jr> 2015-03-27 15:03:59 ERROR: DisconnectBlock() : undo data overwriting existing output
270 2015-03-27 15:22:47 <Luke-Jr> looks like a bunch of those
271 2015-03-27 15:23:28 <Luke-Jr> I'm already on 1d2cdd2ef9091508c42619c94d4a7106b1471a14 - not much more on the branch after that
272 2015-03-27 16:38:42 <devrandom> 
ACTION feeds maaku different data in different universes

273 2015-03-27 17:00:54 <afk11> What are the blockers to using secp256k1 for signature verification right now? I assume it's mostly that older clients may still produce less strict signatures, but wondering what else there may be
274 2015-03-27 17:41:06 <maaku> afk11: I assume you mean libsecp256k1. it's more the unknown-unkowns that are worrisome.. but once the soft-fork for strict signatures goes through it should be safe enough to transition
275 2015-03-27 18:19:24 <afk11> maaku: yes indeed, I've been glued to the repo this past so left with a habit of calling it secp256k1
276 2015-03-27 19:11:50 <jonasschnelli> getting lots of warnings while compiling
277 2015-03-27 19:13:23 <sipa> jonasschnelli: how so?
278 2015-03-27 19:13:59 <jonasschnelli> sipa, try to find the root cause... but looks after a jtimon pr.
279 2015-03-27 19:14:04 <jonasschnelli> ./validationinterface.h:12:1: note: did you mean struct here?
280 2015-03-27 19:14:10 <jonasschnelli> class CBlockLocator; (many of these)
281 2015-03-27 19:14:31 <jonasschnelli> it looks like #5681 introduces some warnings
282 2015-03-27 19:14:57 <sipa> ah
283 2015-03-27 19:14:59 <sipa> fix it!
284 2015-03-27 19:15:15 <sipa> not all compilers warn about the struct/class difference
285 2015-03-27 19:15:41 <jonasschnelli> whole (full)compile log: https://gist.github.com/jonasschnelli/cae689aa6810b8f22e3a
286 2015-03-27 19:15:54 <jonasschnelli> clang issues.. :)
287 2015-03-27 19:16:03 <jonasschnelli> will try to fix it if none else does.
288 2015-03-27 19:16:38 <Arnavion> Shouldn't travis have caught them?
289 2015-03-27 19:19:12 <jonasschnelli> Arnavion, i assume travis won't get "red" when there are warnings.
290 2015-03-27 19:19:45 <Arnavion> That's what warnings-as-errors is for
291 2015-03-27 19:20:12 <sipa> and we mark them as errors afaik
292 2015-03-27 19:20:22 <sipa> but only things that are actually caught as warning will have that effecg
293 2015-03-27 19:20:31 <sipa> not all compilers seem to do that
294 2015-03-27 19:20:44 <Arnavion> Is 5812 the PR? Seems the clang build doesn't show any struct/class warnings
295 2015-03-27 19:23:46 <Arnavion> https://s3.amazonaws.com/archive.travis-ci.org/jobs/55910637/log.txt   and   https://s3.amazonaws.com/archive.travis-ci.org/jobs/55910638/log.txt
296 2015-03-27 19:24:26 <jonasschnelli> Arnavion, i think it was #5681
297 2015-03-27 19:24:46 <jonasschnelli> https://travis-ci.org/bitcoin/bitcoin/builds/55672274
298 2015-03-27 19:26:41 <Arnavion> Those don't have the warning either
299 2015-03-27 19:40:49 <jonasschnelli> does this makes sense? https://github.com/theuni/bitcoin/pull/12