--- Log opened Mon Oct 21 00:00:28 2013
00:52 < sipa> petertodd: i certainly sometimes won't; i don't always have access to my gpg key
00:53 < sipa> petertodd: right, i think i got that, but at some point lost that comment on github; is there any reason why we can't just fix that singke byte push at the same time?
00:54 < sipa> petertodd: i understand that functionally, it is not required now, as any transaction to which it applies is already non-standard
00:55 < sipa> but i'd rather just have a single version, which can later be moved from IsStandard to a network rule
00:59  * Luke-Jr wonders if we should start deploying some form of gmaxwell's antispam addresses in 0.9 so there's some overlap time
01:02 < sipa> given that the majority of clients don't even support sending to P2SH, i really doubt any will be implementing a new and less convenient one, as long as there are no clear benefits
01:03 < Luke-Jr> sipa: there are clear benefits, becoming more necessary every day it seems
01:04 < sipa> for the network, obviously
01:04 < sipa> not for them
01:07 < sipa> you don't have to convince me of the benefits, i'm just very skeptical whether the community would adopt a new address scheme in the first place
01:08 < sipa> with something like the payment protocol, this woukd be significantly easier
01:08 < sipa> but even in a best-case scenario, far from every transaction will use that
01:15 < Luke-Jr> hm
01:15 < Luke-Jr> does the payment protocol support something like this already? :/
01:16 < sipa> no, it can't
01:16 < sipa> as it needs non-transparent client support
01:17 < sipa> but with a payment protocol, it's just client authors that needs to adopt it
01:17 < sipa> rather than everyone
02:29 < petertodd> sipa: right, so go off an update your pull-req to make that change :P
02:30 < petertodd> Luke-Jr: I'm kinda skeptical of P2SH^2 right now, given that my TXO commitments makes the UTXO set size much less worrying, and embedding data in the chain via pubkeys is still possible there
03:32 < sipa> petertodd: but it's an order of magnitude more invasive
03:33 < sipa> do you really think bitcoin could be converted into someday
03:33 < sipa> ?
03:34 < sipa> i consider it an idea worth exploring in an aktcoin, at least initially
04:04 < petertodd> sipa: invasive? I dunno, I think it's less invasive than UTXO commitments - the code is simplier for one.
04:04 < petertodd> sipa: Remember that TXO commitments with txin proofs scale in that you can always store some or all of the UTXO set to reduce bandwidth.
04:05 < petertodd> The main thing is to have a protocol where you can ask your peer for proofs of txins that you yourself don't know about, allowing you to drop UTXO's you don't think are going to be spent. (preferably even fully selectively)
05:05 < sipa> petertodd: i mean compared to transferring an address preimage along with transactions
05:06 < sipa> they're just so different degrees of 'different', that saying that one isn't necessary because the other fixes it in a better way isn't very relevant
05:06 < sipa> in a theoretical from the ground up cryptocurrency you are right of course
05:07 < sipa> but bitcoin has an actual economy and community around it that every change can be hard
05:08 < petertodd> oh, right, yeah, I agree that's invasive
05:09 < sipa> put otherwise: i see address preimages as something that is still bitcoin and can be integrated
05:09 < petertodd> Still I think TXO commitments have so many long-term advantages for scalability that they're worth it on that alone.
05:09 < petertodd> And I disagree with the idea that they're "not bitcoin"
05:10 < sipa> what is bitcoin can change over time of course
05:10 < sipa> but change likely needs to be gradual
05:10 < petertodd> And actually... maybe you can make the argument that TXO commitments are less invasive than P2SH^2 - they're only a validating node change, not a client-side change.
05:10 < sipa> huh?
05:10 < sipa> maybe i misunderstood it then
05:11 < petertodd> Hmm... and actually, I'll argue the TXO commitments are more gradual too, given they're a mining soft-fork.
05:11 < petertodd> sipa: TXO commitments is just taking a hash of a merkle mountain range of the TXO set, spent and unspent.
05:11 < sipa> but the sender needs to construct that, no?
05:11 < petertodd> no!
05:12 < petertodd> anyone between the sender and the miner can make the proof; initially senders would likely not bother implementing it, and everyone would be forced to have near-complete UTXO sets
05:12 < petertodd> but that can change gradually
05:12 < sipa> right, ok
05:13 < sipa> but the idea was to move storage away from validation nodes?
05:13 < petertodd> basically an implementation strategy would be 1) implement hashing code, 2) do soft-fork, 3) start adding networking protocol rules to be able to use proofs, 4) start working on fraud proof stuff, 5) eventually start using them to store less data
05:14 < petertodd> changing clients only really has to happen at the very end
05:14 < petertodd> potentially never
05:14 < sipa> i still consider it a far more invasive change :)
05:14 < sipa> but maybe that's because i understand it less
05:14 < petertodd> there's a lot more client code out there; lots of stuff assumes addresses have specific forms
05:15 < petertodd> besides, we need TXO commitments for scalability and fraud proofing in the long run.
05:16 < sipa> i find that an odd statement
05:16 < petertodd> why?
05:16 < sipa> would you have said that before you knew about that possibility?
05:16 < sipa> of course anything that improves scalability is an improvement
05:17 < sipa> but needing makes it sounds like it is the only possibility
05:17 < petertodd> yes, I got Gavin to agree months ago that fraud proofs w/ UTXO sets were a pre-condition to changing the blocksize for instance, and I still wanted them even if we didn't to make fidelity bonded banks more auditable
05:17 < petertodd> UTXO commitments are the other option, but they don't let you avoid storing the whole UTXO set
05:18 < petertodd> keep in mind that MMR TXO commitments are a form of UTXO commitment that just happens to also commit to all transactions ever made by accident :P
05:19 < sipa> i'm weighing the difficulty of change vs the scalability improvements over time
05:20 < petertodd> well Mike's view is that we'll magically apply enough social pressure that the UTXO set remains small so P2SH^2 isn't needed :P
05:20 < sipa> if you look at a longer time span, more scalability is likely worth it
05:21 < sipa> but that doean't mean we don't have short term problems that need fixing first
05:21 < sipa> like having a client that doesn't corrupt its database all the time for some people
05:22 < petertodd> but, is some data in the UTXO set a big enough problem in the next few years that we have to go off and change every bit of bitcoin-related software that assumes addresses are of a certain form?
05:22 < sipa> it's more about setting the right economic incentices than an actual short term problem i guess
05:24 < petertodd> well, without UTXO commitments and SPV nodes being able to ask peers for UTXO's I'm not sure that there's actually much difference between P2SH^2 and not - dust rules make UTXO bloat expensive anyway, so data-using apps naturally will spend their UTXO's just to keep things cheap
05:24 < petertodd> point is, right now you *can't* query the UTXO set, so there's no difference to storing data in it, vs. storing data in the blockchain in general
05:25 < sipa> but P2SH^2 dosn't let you query it either
05:26 < sipa> gtg
05:27 < petertodd> no, but if you can't query, simple things like dust-rules are fine because there's no *advtange* to storing your data in the UTXO set
05:28 < petertodd> It's something I like about MMR TXO commitments: they *don't* make it easy to prove the existance of a *class* of TXOs
05:31 < sipa> right, but p2sh^2 makes storing any data at all hard
05:31 < petertodd> no, it's still perfectly possible with P2SH multisig
05:32 < petertodd> not much more expensive than a bare CHECKMULTISIG that you spend
05:32 < sipa> true
10:41 < jgarzik> gmaxwell, JFYI check out @jgarzik or @matthew_d_green on twitter, there have been some good conversations reviewing ECDSA + bitcoin
10:41 < jgarzik> (twitter is fscking awful for referencing threads like this...)
10:42 < jgarzik> sipa, ^
10:42 < jgarzik> https://twitter.com/pbarreto/status/392279389716504576  scroll up and down
10:47 < gmaxwell> what gibberish are these people spewing
10:47 < gmaxwell> of course it checks if the point is on the curve or the twist.
10:48 < gmaxwell> and our implementation checks signatures after creating them.
10:51 < gmaxwell> man, twitter sucks.
10:53 < gmaxwell> in addition to the email I sent you,  I also posted this: https://bitcointalk.org/index.php?topic=285142.msg3118788#msg3118788
10:54 < gmaxwell> hm. but I don't seem to point out that bitcoin-qt validates after signing, (and I consider this a best practice)
10:54 < gmaxwell> I guess that should get put in neon lights someplace.
10:56  * jgarzik noticed that when adding signing to node-libcoin
10:56 < jgarzik> Just figured it was sane, good practice
10:57 < jgarzik> Didn't know that validate-after-signing was more important than that
11:02 < petertodd> jgarzik: I'll do my NODE_BLOOM bip as the first pull-req
11:02 < gmaxwell> yea, for our curve (which, like most, is not twist secure) bitflips during multiplies can result in you effectively using an alternative not-secure curve. The result won't validate... but it may be possible to recover private keys as a result.
11:04 < gmaxwell> though really, a better curve can only partially fix that:  a bitflip in a pointer can just have the signature splat our your private key directly, if not validated. :P
11:07 < amiller> can anyone here tell me about DIANNA
11:07 < amiller> as far as i can tell it's the only elaborated idea that is susceptible to a kind of merge mining attack where you withold some data, and then later release it
11:07 < amiller> and someone who later sees it will choose the wrong chain because of timestamp order
12:21 < Muis> I thought of an alternative to proof-of-work, but I need some critic on it by someone with a sound knowledge of the bitcoin protocol
12:22 < Muis> so if anyone has the time/skills to review my idea, let me know!
12:57 < Luke-Jr> did gmaxwell resign as BIP editor?
13:09 < jgarzik> Luke-Jr, gmaxwell is fine too
13:10 < jgarzik> wiki-as-primary is not the best path forward, IMO
13:10 < Luke-Jr> sure, but I don't see why that means we should change BIP editor. gmaxwell has been doing a good job IMO :P
13:11 < jgarzik> TBH I simply was not aware of gmaxwell as BIP editor
13:11 < jgarzik> it seemed quite chaotic and unedited
13:13 < sipa> the 'editing' was just that he was the person to assign BIP numbers
13:28 < maaku> amiller: what's unique about the DIANNA merge-mine attack?
13:40 < maaku> you mean that you can simultaneously mine two or more forks, double-counting the PoW?
13:43 < gmaxwell> Yea, the only task I had was assigning the numbers when it looked like there was some agreement that there should be one. (No lack of desire to do more or less on my part, I'll do whatever people want)
18:51 < sipa> petertodd: care to explain MMR's in some more detail?
18:51 < petertodd> sure
18:51 < sipa> i can come up with a few datastructures that seem to match the general direction you're going in
18:51 < sipa> but i'd like to know exactly what you're thinking about
18:51 < petertodd> you read my thing on MMR's?
18:52 < sipa> no, where?
18:52 < petertodd> https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md
18:52 < petertodd> doesn't mention that they are cheaply updatable, but otherwise it's complete
18:59 < sipa> ok, so you have an O(1) append, O(log(n)) updatable merkleized datastructure
18:59 < sipa> what do you store in it?
18:59 < sipa> transaction outputs, including their spentness bit, i suppose
19:00 < petertodd> yup, same as the UTXO set
19:00 < petertodd> though I was thinking that H(scriptPubKey) wouldn't be a bad idea - kinda the same effect as P2SH^2
19:00 < warren> Regarding https://github.com/bitcoin/bitcoin/pull/2900 I'm guessing that the people with working exploits really don't want to discuss it in public.
19:00 < sipa> so they are not indexed in any way - you have to know where a particular element resides
19:00 < warren> The discussion has been dysfunctional from people being unwilling to discuss it openly.
19:01 < petertodd> sipa: yup, which is good, because that's what lets you append without having any of the data
19:02 < petertodd> warren: yeah, it's a complex issue... frankly, meh :)
19:02 < petertodd> warren: mike, gavin and I disagree on philosophical, not technical grounds
19:03 < petertodd> sipa: vs. UTXO sets where any given append might need a UTXO from any point in history
19:05 < sipa> so, how much does a client need to know to update his wallet's txo set?
19:05 < sipa> later blocks will only build new nodes next to, or on top of his nodes
19:06 < petertodd> sipa: well, basically you want a complete path to the most recent commitment. Now every new block will tend to invalidate the latter part of that path, but the beginning is only invalidated when adjacent transactions are spent.
19:07 < sipa> petertodd: so, i wonder, what if instead of a single mountain range, you just have a single tree per block
19:07 < sipa> with its transaction outputs, ordered
19:07 < petertodd> sipa: right! and I think that's a good idea actually, although you still need the MMR to commit the state of all blocks
19:07 < petertodd> ordering transaction outputs is nice of course for proof reasons
19:07 < sipa> that means that once a tx is in a mined block, a wallet doesn't need to know anything anymore
19:08 < sipa> you might even optimize a bit, by scrapping outputs spent within the block itself already
19:09 < petertodd> yeah, see, I'm a bit divided on that actually: I'm not sure that outputs being spent within a block is conducive to compact fraud proofs
19:09 < sipa> i'm unfamiliar with the word 'conducive'
19:10 < petertodd> I was thinking that given that wallets basically never have a good reason to spend unconfirmed coins that someone just gave them, it's not unreasonable to say txs in a block may only spend txs prior to that block, provided that tx replacement is availalbe to rewrite txs to add new outputs when you make a few txs in a row
19:10 < petertodd> "making a certain situation or outcome likely or possible."
19:10 < sipa> i don't see why they'd never have reason for that?
19:11 < petertodd> basically just that it's dangerous re: double-spends generally, not to say it's absolutely never useful
19:11 < petertodd> anyway, I gotta think about that more
19:11 < sipa> well in many cases you do trust the sender
19:11 < sipa> in particular when it's yourself
19:12 < petertodd> yes, although if it is yourself, you could just as easily replace the transaction with one with more outputs
19:12 < petertodd> (usually)
19:13 < sipa> i guess you can build an MMR on top of the block's root state hashes
19:14 < petertodd> yeah, which is ugly... I dunno, I'm just inclined to leave it out if it looks at all complex frankly. We really want fraud proofs to have as few code-paths as possible.
19:14 < sipa> but the benefit is relatively small - you just need to maintain each block's top
19:14 < petertodd> They terrify me enough already.
19:14 < sipa> which grows linearly
19:14 < petertodd> ?
19:14 < sipa> the number of blocks grows linearly in time
19:15 < petertodd> oh, no, building an MMR on top of that is absolutely mandatory to be able to generate fraud proofs
19:15 < sipa> hmm?
19:16 < petertodd> basically the issue is that while the size of the block root hashes is small, the TXO commitments of them change constantly as transactions are spent, so it's unrealistic to expect a low-bandwidth client to have an up-to-date version of that, yet they still will want to be able to reject a block
19:17 < maaku> it might be true though that it is simpler for a light(er) client to work with an MMR of block root hashes
19:17 < petertodd> for instance, imagine if every txout spent in a block was from a different block - that could be a few thousand roots changed at once even with 1MB blocks
19:18 < petertodd> maaku: yeah, and MMR's of block roots help out for other reasons too
19:18 < maaku> i mean, opposed with a straight MMR over a linear sequence of txouts
19:19 < petertodd> maaku: yeah, I was thinking that doing the MMR over just the block roots was the way to go - one good reason is it makes it conveivable that multiple nodes could co-operate to create a block in a low-bandwidth per node way
19:20 < petertodd> also keeps txin proofs reasonable small, especially if it were done with 20-byte hashes
19:23 < sipa> so, each txin must give the merkle path from the prevout point to a known root
19:23 < sipa> which can be used both to verify that it actually existed, and to compute the new root
19:24 < petertodd> exactly
19:24 < petertodd> and what's also nice is those proofs can be easily composed, as well as updated. (similar to maaku's points re: composing radix trees)
--- Log closed Tue Oct 22 00:00:31 2013