--- Log opened Tue Dec 17 00:00:02 2013
00:20 < gmaxwell> ugh. https://bitcointalk.org/index.php?topic=374085.0
00:22 < Luke-Jr> gmaxwell: well, Gavin did encourage it in his blog… :/
00:24 < gmaxwell> mostly ugging at advocating it for "Logins to websites without passwords" and "pseudonyms" where encryption is entirely the wrong tool, and the requirement to have 'spent' from it is completely unnecessary because signmessage already does those things, and a lesser ugh at the address reuse that implies.
00:25 < gmaxwell> it's also probably only about 50 lines of code, just seems weird to me to see people making annoucements for such small things.
00:25 < Luke-Jr> I was ugging at the data-in-bitcoin-blockchain :P
00:26 < gmaxwell> they aren't putting any data in the blockchain yet.
00:27 < gmaxwell> all they're doing is using blockchain.info as a addr to pubkey service and doing encrypted messages using ECDH with that pubkey.
00:27 < Luke-Jr> O.o
00:29 < gmaxwell> Luke-Jr: mind giving a polite response on the loging / identity points  pointing out that doing that via signmessage is already a widely established practice, doesn't require making transactions, carrying around the public key explicitly, or consulting (centeralized) databases?
00:31 < Luke-Jr> gmaxwell: well, this claims to be the inverse?
00:32 < Luke-Jr> oh, you mean just respond to that point
00:33 < gmaxwell> yea. I don't see any reason why you'd use something based on this over signmessage, but there may be people who see this post (even the author) who is unaware of signmessage.
00:35 < andytoshi> istr altoz being around for a long time, he should be aware of these things..
00:36 < Luke-Jr> gmaxwell: http://bitcointroll.org/?topic=374085.msg4004568#msg4004568
00:37 < gmaxwell> Thanks.
00:45 < andytoshi> maybe withhold those hugs :) altoz replied with 'but this does encryption as well as signing', and he's already got a "can't wait to try it!" reply
00:46 < Luke-Jr> sigh
01:20 < Emcy> wow that guy accidentally sent 20btc fees and then had it mined by p2pool
01:20 < Emcy> super unlucky
01:31  * Luke-Jr thinks we should get rid of spendfrom.py example
01:59 < michagogo|cloud> Emcy: note that he was essentially crafting the transaction manually
02:01 < gmaxwell> bitcoin-qt/bitcoind wouldn't have sentraw that transaction now either.
02:14 < Emcy> yea. creating rawtxs to send coins to some gambling thing
04:10 < adam3us> Emcy: that confirms my thought that fee > value on non-dust level should be invalid (not fwded) its ridiculous.  10k pizza guy ok, but its not exactly a "cool' story to hear now and then of the $20k accidental wire xfer fee
04:17 < gmaxwell> adam3us: I disagree very strongly.
04:18 < gmaxwell> There is no reason to make it non-standard— users can be protected by their software, and if the software doesn't then nothing can save them—, doing so would have had likely no effect here, since "brainwallet" passes the transactions directly and any miner is likely to instantly rip out that rule, at least after the first time they don't get some mysterious big fee txn, and doing so would break some applications that depend on ...
04:19 < gmaxwell> ... having big fees.
04:19 < gmaxwell> (this stuff: https://en.bitcoin.it/wiki/Identity_protocol_v1 )
04:19 < gmaxwell> Bitcoind / bitcoin-qt already won't let you sendrawtransaction such a transaction, unless you give it an extra override switch.
04:23 < wumpus> there are tons of ways to shoot yourself in the foot if you work with bitcoin at such a low level. It could just as well have been "person sends 1000BTC with OP_RETURN script by accident"
04:25 < gmaxwell> wumpus: a fun mistake I've made while playing around with those sites:   highlight a pre-filled form to clear it out, but doing so copies the default address there and blows away the address in my copy buffer. Then I paste the default address back in, thinking it was the one I intended to use.
04:25 < wumpus> if you add all kinds of nice and fluffy safety measures at the protocol level, the end result may be making peopel *less* careful
04:25 < gmaxwell> (I asked joric to remove the default addresses from the site, pointing out this failure mode, and he declined ::shrugs::)
04:26 < wumpus> gmaxwell: ouch
04:26 < gmaxwell> fortunately I've never lost money that way, but I've been confused while screwing around with it casually.
04:29 < Emcy> does anyone ever worry in the future that a big bank might fuck up a large settlement by working with raw txs and send a good franction of the wealth of a nation to china or something
04:29 < wumpus> (end users should ideally be protected by a user-friendly layer on top... as for dangerous behaviour, you don't expect consumers to go mixing chemicals directly either to make food flavors, and then blame physics for them ending up in the hospital)
04:29 < Emcy> and plunge thier country into poverty......
04:29 < warren> presumably you would write a parser that double checks your tx before send
04:29 < warren> this isn't a toy anymore
04:30 < warren> (unless you're talking dogecoins)
04:30 < Emcy> only double? for a transfer like that?
04:30 < wumpus> Emcy: they should have actual humans review such a transaction
04:30 < Emcy> thats where the fuckups come in
04:30 < gmaxwell> Emcy: I've had some people on IRC ask me to review transactions of theirs, as a second party review of a large manually constructed transaction.
04:31 < gmaxwell> Emcy: defense in depth.
04:31 < Emcy> i remember the big one a few years abo where barcalays was down for like a week, some human fiddled with settlement code from 1950 or something
04:31 < wumpus> if you transfer such amounts of money, you can hire crypto experts to verify it
04:31 < Emcy> COBOL?
04:31 < gmaxwell> You have machines which cannot fail by design, and then you have humans check too, to catch when the infalliable machines fail. :)
04:32 < gmaxwell> wumpus: at the SJC conference I was joking that it would be fun to have some good "Bitcoin headlines from the future" in a keynotey talk... and I gave some suggestions.
04:32 < Emcy> gmaxwell im suprised you would do that
04:32 < Emcy> for truly serious amounts anyway
04:32 < wumpus> gmaxwell: hah, it sounds pretty weird worded that way
04:33 < Emcy> sounds interesting
04:34 < wumpus> what I sometimes worry about is bitflips due to overheated/damaged CPUs
04:34 < gmaxwell> "January 1st 2016 Kenya announces it's aquired a million bitcoins and is switching to bitcoin"  "January 2nd Apparently Kenya used a 'brain wallet'... Anonymous now the wealthies non-governmental entity in the world" "January 1st 2017, 4chan orbiting station launched"
04:34 < Emcy> that really almost never happens
04:34 < gmaxwell> Emcy: they do happen however, if rarely. They especially worry me with change.. e.g. bitflip changes your change address by 1 before signing. oops.
04:35 < Emcy> when it does i think its more liekly to be solar neutrinos or something and not an old electromigrated chip
04:35 < Emcy> quantum effects as chips approach bloody angstroms remain to be seen........
04:36 < Emcy> gmaxwell yeah its worrying that its possible. Wouldnt ECC memory catch it though for important operations?
04:37 < Emcy> then again wut if a bit flips in your pacemaker, or your plane or anything
04:37 < wumpus> gmaxwell: haha, such stories are a funny way to deliver the message not to use brainwallets
04:38 < wumpus> Emcy: planes have redundant systems (at least I hope so)
04:38 < Emcy> gmaxwell funny moot was depicted as inhabiting an orbital station in that 4chan cartoon short.....
04:40 < wumpus> gmaxwell: i suppose some problems could be avoided by doing a last-minute check on the transaction after signing but before broadcasting.. .then again, everything checked against may be corrupted, how can you ever be sure, it's really difficult to protect against fallible hardware
04:41 < gmaxwell> yea, I opened an issue as a "to do someday" ... after signing just go and check that the change address IsMine, that the amounts and outputs match what we think they should match.
04:41 < gmaxwell> If we redo the base58 decode it'll actually be very strong unless the error is repeatable, since that will check the checksum.
04:43 < wumpus> sounds like a good idea to do an isMine check; if it has a private key for the address, it must still be spendable
04:43 < gmaxwell> key generation should also double check, which I don't think I mentioned on that issue.
04:43 < warren> Coin control lets you set a change address of anything at the moment ...
04:44 < gmaxwell> yea, well, if you do that you get to keep the pieces.
04:44 < wumpus> warren: I've thought about that, not sure it's a good idea to allow non-owned addresses there
04:44 < gmaxwell> (that one could be checked by at least doing the base58 decode, same as regular outputs)
04:45 < wumpus> then again it's coin control not coin nanny
04:45 < gmaxwell> wumpus: it could be kinda handy, I suppose. e.g. if you're migrating between wallets gradually.
04:46 < warren> it says "experts only"
04:46 < wumpus> in any case, adding appropriate some sanity checks wouldn't hurt
04:46 < gmaxwell> I guess we'll see if anyone manages to — say, put their destination address there twice "keep the change" not realizing that "change" could be 100 btc.
04:48 < wumpus> warren: I suppose brainwallet also has such a disclaimer though :p there is a point in not making user friendly interfaces for inherently dangerous expert things
04:49 < gmaxwell> there is no disclaimer on brainwallet.
04:49 < wumpus> okay
04:50 < gmaxwell> the guy who created it either doesn't get half these concerns or hes playing dumb.
04:52 < Emcy> why would he?
04:53 < gmaxwell> Well, calling someone stupid isn't nice, so I thought I'd at least credit him with stupid or evil.
04:53 < Emcy> it is just a tool, i suppose
04:54 < wumpus> it is, but it could at least come with a warning
04:54 < epscy> there should be a disclaimer
04:54 < gmaxwell> see some old logs, https://people.xiph.org/~greg/brainwallet.txt
04:54 < epscy> i would be worried about getting sued if that guy was me
04:54 < Emcy> though i had a look and saw a box to put your OWN passphrase in to generate a wallet AND it was prefilled with correct horse staple battery
04:54 < Emcy> thats just asking for it
04:54 < wumpus> the point is, it doesen't look dangerous... most physical dangerous tools at least look dangerous
04:55 < gmaxwell> it looks slick and its promoted by mainstreamish tech media to new users who've never used bitcoin at all.
04:55 < Emcy> if he took off the friendly rounded corners of the buttons do you think that would be enough to dissadle people lol
04:56 < gmaxwell> The broader bitcoin community (not just us tech heads) has started throwing red flags on it. At least now everyone who gets screwed via that site is getting called an idiot ( :(  but pretending you knew all along it was unsafe is the first step to actually knowing)
04:57 < Emcy> perhaps its a process which people just have to go thru?
04:57 < Emcy> being deprogrammed to just trust every slick website out there
04:58 < gmaxwell> well it's not just the slickness... all the ideas sound fun in principle, but the devil is in the details.
04:58 < Emcy> i loved the idea of a brainwallet until i learned why its almost always a bad idea
04:58 < Emcy> i still like it but i wouldnt do it
04:59 < gmaxwell> people are awful good at visualizing the sequence of events where everything goes right...
05:00 < Emcy> just another cognitive bias
05:01 < gmaxwell> where the website isn't scraping their keys, where its rng isn't weak, where they actually manage to memorize a key that attackers with big fpga farms won't guess, but don't then manage to forget it. ... and then later they come back to collect their coins and don't mess up a copy and paste on the destination, and finally don't manage to send all their coins to fees.
05:02 < gmaxwell> And in the interm hopefully there wasn't an ECDSA or RIPEMD160 break that left them behind in some hard forking update that was easily handled by normal software wallets, but not by specific keys people have memorized.
05:02 < Emcy> yeah bitcoin has a lot of ways to ensure you spend your retirement in the dosshouse.....
05:03 < Emcy> tbh im really really scared about when the time comes to move what coins i have again
05:03 < wumpus> to be fair, storing a large amount of value in any physical commodity is just as risky
05:04 < Emcy> im waiting for you to finish HD wallets.....then wait some more incase theres some atrocious bug.......
05:04 < wumpus> I hardly even dare to touch the wallet code, apart from fixing bugs or small code movements :p
05:07 < Emcy> yeah bitcoin development, 4 guys squatting digging up a landmine because it has to be moved over there to make room for the snake pit
05:08 < wumpus> hah
05:24 < adam3us> gmaxwell, Emcy: yes i worry about bitflips - we saw the first hand 2x in mozy (50Pb cloud store) bitflip twice in ECC ram that were detected
05:26 < adam3us> gmaxwell, Emcy: if you do something enough on enough servers, you will get a bitflip in data (or code); that was in ram between upload and store to disk (a short period of time), and they made  it more robust by reading back from disk and checking the hash again if i recall
05:27 < Emcy> 2 bits in 50pb? thats safe as houses
05:27 < adam3us> i would not recommend moving more than 5% of money in one tx on a big tx really - i think the bitstamp moving 195k coins = $150m were nuts
05:57 < wumpus> Emcy: remember that most consumer tech is not quite as reliable as servers
06:07 < midnightmagic> yikes(bitflips in ecc ram)
06:08 < midnightmagic> i've seen it happen on 24tb storage arrays
08:21 < adam3us> Emcy: safe as houses; hmm basically its relatively safe, but not quite - if its an amount of money you cant afford to lose i think its better to do it in stages (5% per time) and/or to add extra double checks
08:25 < adam3us> Emcy: already bitcoin has 32-bit truncated sha256 checksum included in the address format, but if the address got bit-flipped before going to the network.  maybe other nodes would consider a invalid checksum address as invalid.  does the checksum even exist at the wire level? or is that a human encoding only thing.
08:25 < adam3us> Emcy: otherwise sooner or later as transaction volume grows that WILL happen to someone
08:45 < andytoshi> adam3us: there are indeed no checksums at the wire level
09:09 < andytoshi> gmaxwell: just saw your response to that encrypt-to-address thing
09:10 < andytoshi> yikes, why did he think it was responsible to release encryption software when he didn't know how it worked?
09:11 < andytoshi> oh, i see, it's a bit more subtle than that..
09:19 < andytoshi> i read "what is the nonce" and thought uh-oh
11:43 < adam3us> andytoshi: there is probably an implied checksum on any signed tx, the recipients addr is signed by the senders private key; if any bits are flipped (in recipient addr, or sig, or pub key, or output values) the sig is invalid so the tx is ignored
12:06 < gmaxwell> adam3us: we do have a checksum on the wire.
12:06 < gmaxwell> not that it really matters that much since all the important data is authenticated.
12:10 < Luke-Jr> sigh
12:10 < Luke-Jr> gmaxwell: well, it does with the anti-DoS stuf
12:10 < Luke-Jr> gmaxwell: without a checksum, peopel would get banned for corruption
12:35 < maaku> adam3us: there isn't any checksum protecting the data from the time the transaction is created to the moment it is signed
12:35 < maaku> a not insignificant amount of time if you are getting signatures from offline devices, for example
12:36 < Luke-Jr> perhaps we should be creating and signing every transaction twice
12:36 < Luke-Jr> with a comparison
12:36 < andytoshi> maybe this is something to think about for version 2 transactions..
12:37 < andytoshi> also have a way to indicate if outputs are blinded
12:37 < andytoshi> so that createrawtransaction would deal with them
12:46 < maaku> I think this is a higher-level problem
12:46 < maaku> We just need an interchange format that includes checksums
12:47 < maaku> Of which there are probably multiple bips I am not familiar with
12:50 < maaku> The raw transaction apis should be working with these enveloped transactions
12:51 < andytoshi> yeah, i agree .. hopefully there is a bip about this
12:52  * maaku reviews the bip list and is surprised that there isn't one covering this
12:52 < andytoshi> damn, there's probably too many usecases to consider
12:53 < maaku> Well I'm not sure that matters. It could literally be as simple as "strip all signatures, calculate 4-byte checksum, append checksum & prefix version, base58 encode"
12:53 < maaku> Then internally, that checksum could be checked before signing
12:55 < helo> can it be validated after it is signed?
12:55 < Luke-Jr> andytoshi: you sockpuppet!
12:55 < andytoshi> Luke-Jr: haha, i was gonna bug you about that..
12:55 < helo> a lot of pre-signing bitflips would cause the tx to fail normal verification
12:55 < andytoshi> then i realized that obviously nothing you or i say would help
12:55 < maaku> yeah, but safety check - you don't want signatures to exist for transactions you didn't mean to sign
12:55 < maaku> helo: but there are some which won't
12:56 < maaku> e.g. bitflip in the pubkey-hash
12:56 < helo> right... so valide those after signing?
12:56 < maaku> you could do that ... but is that solving a problem?
12:57 < helo> not afaict :)
12:58 < andytoshi> maaku: i'd like a transaction envelope which can have some or all signatures available..
12:58 < maaku> andytoshi: sure it can include the signatures
12:58 < maaku> but the checksum has to be sig-less
12:59 < andytoshi> ah, i see
13:02 < andytoshi> would there be any point to having a MAC as well?
13:02 < andytoshi> i'm thinking about the reasons that people pass raw transactions around today..
13:02 < andytoshi> i guess, an optional mac, if it were required then the checksum would accomplish nothing..
13:04 < andytoshi> hmm, actually any authenticating tokens would have to be negotiated outside of this format anyway
13:04 < maaku> well the authentication purpose of the MAC is covered by the signature, no?
13:04 < andytoshi> yeah, when you have a signature -- but if, say, i was submitting an unsigned transaction for long-term storage for some reason
13:04 < maaku> well maybe there's a use case involving third parties I'm not thinking of
13:05 < andytoshi> but i think that problem should be solved on still higher a level
13:06 < andytoshi> a checksum would cover innoculous corruption, that's pretty-much all we could prevent with the information associated with an unsigned transaction
13:29 < petertodd> handed in my resignation at work: http://0bin.net/paste/TW-j6eQy8SPX6KOW#W6xba/5CVZcf8xpA/YLtz+cGcjb8CMYNhfE7lNdbuwU=
13:30 < petertodd> I thought PGP-signing it would be appropriate; hilarious that there's a hard-copy of that now with my pen-and-paper signature on it too
13:46  * nsh raises a glass to commemorate petertodd's career transition
13:47 < gmaxwell> nsh: is that ... hemlock?
13:48 < nsh> oops, wrong party
13:48 < nsh> :)
13:48 < gmaxwell> petertodd: congrats
13:54 < michagogo|cloud> petertodd: how is that hilarious?
13:59 < petertodd> Thanks!
13:59 < petertodd> And ha, I manged to get the date wrong... it's January 24th that I leave, Feb 1st is the start date with mastercoin.
13:59 < petertodd> *managed
13:59  * michagogo|cloud doesn't find that funny
14:00 < petertodd> michagogo|cloud: that's because you're a pseudonym :p
14:00 < petertodd> brb, meeting
14:00 < michagogo|cloud> petertodd: huh?
14:01 < michagogo|cloud> Why is it funny to PGP-sign and pen-on-paper-sign the same document? o_A
14:01 < michagogo|cloud> s/A/O/
14:23 < petertodd> michagogo|cloud: it's a bit redundant IMO, or really, calls into question the whole idea of "signing" things
14:23 < petertodd> michagogo|cloud: shows how all the paperless office stuff just hasn't taken off too
14:23 < michagogo|cloud> Sure
14:23 < michagogo|cloud> But I, personally, don't find it funny...
14:24 < petertodd> well, as I said, you're a pseudonym utterly dependent on PGP :P
14:24 < michagogo|cloud> I am?
14:24 < gmaxwell> Don't worry, I found it funny.
14:25 < petertodd> gmaxwell: heh, HR found it hilarious, and also impressively knew exactly what the PGP signature was too!
14:25 < phantomcircuit> the redundant department of redundancy and redundant things
14:27 < petertodd> phantomcircuit: funny that that department is known for analyzing and reducing redundencies... but only external to it
14:28 < phantomcircuit> electronics designer? does that mean you make the things pretty
14:29 < petertodd> phantomcircuit: yes, I make beautiful artworks that sadly have an exceptionally small audience of admirers
14:29 < phantomcircuit> petertodd, i've never known an HR department that added value to the companyt
14:30 < petertodd> phantomcircuit: I actually think HR where I am adds value to the company, and more generally I've got a lot of praise for management
14:31 < andytoshi> damn, i like these PR guys... i should apply for your job
14:32 < andytoshi> maaku: regarding a transaction envelope, it should have a way to indicate that outputs (or anything) are blinded
14:32 < andytoshi> so that, e.g. if i have people submitting stuff to my joiner, i know which outputs i need to have unblinded before collecting signatures
14:32 < maaku> andytoshi: I think that's a different problem...
14:33 < andytoshi> ok, i'll keep thinking about it
14:34 < andytoshi> with the current "submit rawtx" interface it is really not clear to me how i can tell 'all outputs are unblinded, ok to collect sigs'
14:35 < andytoshi> because i'm thinking, i'll probably extend the transaction-submission window to a few days or a week, because if people want quick coinjoins, they're much better served by a fully automatic joiner like yours
14:36 < maaku> I have a different protocol for serializing join offers and proposals
14:36 < michagogo|cloud> Gah, I don
14:36 < michagogo|cloud> 't like thread necromancers
14:36 < michagogo|cloud>  Took me a while to notice that https://bitcointalk.org/index.php?topic=2699.0;all was from 2011...
14:36 < phantomcircuit> petertodd, HR that limits itself to generic stuff is useful
14:37 < phantomcircuit> petertodd, HR that tries to manage is seriously negative value
14:37 < phantomcircuit> petertodd, an HR department that does things like makes sure payroll works correctly and makes sure to get a group health insurance that fits everybody's needs is very valuable
14:38 < phantomcircuit> it's just that most of them try to make business decisions they aren't even remotely qualified to make :/
14:39 < phantomcircuit> (this is the typical engineers snide remarks about hr lol)
14:39 < andytoshi> maaku: and your protocol can badger people to unblind their stuff without identifying themselves?
14:39 < maaku> well, they have to reconnect with a new tor identity
14:39 < petertodd> phantomcircuit: yup, and HR where I am is the good type. Also remember that HR is very useful as a way to give employees a route to raise issues other than their managers.
14:40 < andytoshi> maaku: right, so if they don't do this on time, can you detect it?
14:40 < petertodd> phantomcircuit: e.g. if there's say, abuse or harrassment going on you need HR as a neutral third-party to fix the issue
14:40 < phantomcircuit> maaku, the only way to guarantee that is to monitor tor circuits
14:40 < maaku> andytoshi: people can reveal their blinding factors (thereby identifying themselves)
14:41 < maaku> if it appears that the join has failed
14:41 < phantomcircuit> by default the client has a minimum reset time for new identities to prevent people from DDoSing the relays with the guard flag
14:41 < andytoshi> ok, i see .. i don't think i can use the same strategy for a very-high-latency protocol
14:41 < phantomcircuit> unfortunately the control port will reply with OK even if it didn't actually cycle the identity
14:41 < maaku> ?
14:41 < maaku> this is designed for a high-latency protocol
14:42 < maaku> I don't think it'd scale very well to real time
14:42 < andytoshi> "if it appears the join has failed" could be after people have spent a day submitting transactions, then spent a day unblinding stuff
14:42 < maaku> the bids and proposed joins have round durations built into them
14:42 < andytoshi> and then one guy misses the window, doesn't want to identify himself, so he walks away and ruins it
14:43 < phantomcircuit> maaku, iirc older versions of the tor client are fairly aggressive with keeping hidden service circuits open
14:43 < andytoshi> so, right now i have a round duration for the submit-transaction phase, but then the signing phase can last forever
14:43 < gmaxwell> phantomcircuit: you use two distinct hidden services.
14:43 < maaku> phantomcircuit: that's completely unacceptable... i'll have to talk with some tor devs about this
14:43 < phantomcircuit> gmaxwell, ah yeah that would work
14:43 < maaku> but yes, it's distinct hidden services
14:43 < maaku> oh ok
14:44 < gmaxwell> yea, if you use two distinct hidden services you'll get the properties you want.
14:44 < phantomcircuit> maaku, the new identity feature doesn't even disconnect open circuits
14:44 < andytoshi> hey, cool .. with two hidden services i can refuse to merge transactions until they have been submitted in the clear to one, and unblinded by the other
14:44 < maaku> that's really bad...
14:44 < phantomcircuit> it just marks them as not to be reused
14:44 < phantomcircuit> it only works well with web browsers really
14:44 < andytoshi> wait, that still links inputs to outputs (for me)
14:45 < andytoshi> (sorry, i'll stop thinking out loud, have to eat anyway)
14:45 < gmaxwell> maaku: whats really bad?
14:45 < maaku> andytoshi: the protocol is this: if all blind signatures are submitted, but not all unblind messages received by the expiration, *everyone* involved who does not reveal their output gets DoS banned
14:46 < phantomcircuit> gmaxwell, im assuming there is an anonymity issue with signing every permutation of the outputs for a coinjoin
14:46 < maaku> gmaxwell: that "use new identity" doesn't actually stop using the old identity, if what phantomcircuit is saying is correct
14:46 < maaku> doesn't affect this application though, but bad in general
14:46 < gmaxwell> phantomcircuit: yes, because obviously you'd not sign the ones with your inputs but without your outputs!
14:46 < phantomcircuit> gmaxwell, right
14:47 < andytoshi> maaku: ok, i don't want to dos-ban people because i'm working over a few days and people get distracted or forget
14:47 < gmaxwell> maaku: the use new identity makes it expire the circuits it pegs up to exits, but I dunno what it does with hidden services; probably best to just use two.
14:47 < andytoshi> i'd rather a system where people who don't fully participate just don't get included
14:47 < gmaxwell> andytoshi: in a realtime / near realtime automated protocol those issues go away.
14:48 < phantomcircuit> gmaxwell, but lets say there is a client with coinjoin implemented in such a way that it's continuously doing it through various meeting points
14:48 < phantomcircuit> entirely transparently to the user
14:48 < maaku> andytoshi: that's the system I described ... your client will automatically broadcast your blinding token after the expiration, preventing you from being banned
14:48 < phantomcircuit> would resistance to withholding not be worth the reduced anonymity
14:49 < maaku> it's only people who don't reveal their outputs, and therefore can't prove that they did which get DoS points
14:49 < gmaxwell> phantomcircuit: you can resist witholding by just abandoning doing any blinding, and if someone withholds the server just drops them and asks everyone to retry... you could do several attempts per second or whatever, and you're banning the withholders ago you go.
14:50 < gmaxwell> and as maaku says, there is a relatively straight forward protocol that allows you to ban witholding parties and still keep the stronger privacy.
14:50 < phantomcircuit> gmaxwell, how do you ban anonymous parties? :)
14:50 < phantomcircuit> tell me and we'll get rich running a tor irc network
14:50 < warren> especially over tor
14:51 < phantomcircuit> wait what
14:51 < gmaxwell> phantomcircuit: trivially.
14:51 < phantomcircuit> s/get super annoyed/
14:51 < gmaxwell> By banning their inputs.
14:51 < phantomcircuit> gmaxwell, except they're witholding the outputs not the inputs
14:51 < petertodd> Anyone else planning on going to the real world cryptography conference next month in NY? https://realworldcrypto.wordpress.com/
14:51 < gmaxwell> phantomcircuit: yep no problem.
14:51 < phantomcircuit> so you'd have to be able to link the inputs and outputs to figure out which inputs to ban
14:51 < maaku> Well, it turns into an arms race where I don't think I'd say there's a "trivial" solution
14:52 < phantomcircuit> gmaxwell, if the join is cancelled you just ask everybody to reveal their input/output link and ban the input of the person who withheld
14:52 < warren> one doesn't need the privkey to propose someone else's inputs right?
14:52 < gmaxwell> petertodd: that sounds pretty good.
14:52 < phantomcircuit> then everybody generates a new key for the next round for their output
14:52 < gmaxwell> phantomcircuit: yep
14:52 < maaku> warren: they do in my design
14:52 < phantomcircuit> gmaxwell, i could see that potentially leaking info though since people do reuse addresses no matter how much we tell them not to
14:52 < maaku> proposals are signed by the inputs they provide
14:53 < petertodd> gmaxwell: bah, just noticed they're "sold out" - free event but registration required
14:53 < gmaxwell> phantomcircuit: the details are a bit hard to get right.
14:53 < gmaxwell> phantomcircuit: but there isn't anything fundimentally hard.
14:53 < phantomcircuit> petertodd, something tells me if you call them and ask they'll magically find room
14:54 < petertodd> phantomcircuit: yeah, gonna give that a go... zooko will be there so I'll give him a shout too
14:54 < gmaxwell> hm. wish I'd thought of it earlier.
14:55 < gmaxwell> I'm going to be on the east coast from the 17th to the 21st for the MIT mistery hunt already... don't think kat has booked tickets yet, so I could perhaps swing by nyc first.
14:55 < petertodd> gmaxwell: cool!
14:56 < gmaxwell> phantomcircuit: basically the bitcoin network itself already gives us a scarce resource we can blacklist: existance of a txout. ... if that turns out not to be enough we could have things like SINs that are required to play, which can be blacklisted using the same protocol.
15:00 < phantomcircuit> gmaxwell, SINs?
15:01 < petertodd> gmaxwell: sending an email to the organizers; want me to ask if you can get a registration as well?
15:01 < gmaxwell> phantomcircuit: expensive to create pseudonoymous identities, created by throwing away coin.
15:02 < gmaxwell> petertodd: yes please. If it turns out I can't come it shouldn't be a huge issue.
15:02 < phantomcircuit> ah
15:03 < andytoshi> petertodd: me too? (though i have no credentials, i understand if i'd just be weighing down your request)
15:03 < phantomcircuit> gmaxwell, yeah but nobody would want to do that if it was automated since they'd end up getting banned because they're on wifi at the airport or whatever
15:04 < gmaxwell> phantomcircuit: e.g. it can just ban their input for N hours, if you want, you're free to choose the paramters to make it reasonable.
15:04 < petertodd> gmaxwell: done
15:05 < petertodd> andytoshi: sorry, just sent it already
15:05 < gmaxwell> andytoshi: what part of the world are you located in?
15:05 < andytoshi> no worries :)
15:05 < andytoshi> gmaxwell: austin
15:05 < andytoshi> it's a $300 flight
15:05 < petertodd> andytoshi: ah, if you were local I'd say just sneak in :)
15:05 < andytoshi> :P
15:05 < petertodd> andytoshi: $100 flight for me
15:06 < andytoshi> hopefully in a year or two i'll have the connections here for the university to fund me..
15:07 < phantomcircuit> gmaxwell, so interesting thought (which im sure someone else has had) coinjoin combined with outputs broken up into standard sized pieces would make it effectively impossible to run conventional money tracing algorithms
15:07 < andytoshi> maaku, gmaxwell: i understand your blinding protocol now, thanks
15:07 < phantomcircuit> as it stands with coinjoin you wouldn't be very protected if you were merging with significantly different amounts from everybody else
15:07 < gmaxwell> phantomcircuit: … lol
15:07 < andytoshi> i'd still like to have multi-day joins, and it's too inconvienient if there's a possibility of invalidation
15:07 < petertodd> phantomcircuit: yeah, my post-dark-wallet write-up was going to suggest that merge-avoidance + coinjoin is a powerful tool
15:07 < phantomcircuit> but if all the outputs were powers of 2
15:08 < phantomcircuit> well now
15:08 < phantomcircuit> good luck with that
15:08 < phantomcircuit> petertodd, i actually already do something sort of like this with the intersango cold storage
15:08 < petertodd> phantomcircuit: should do it as a slider basically saying "I'm willing to pay up to x% more fees for better privacy"
15:08 < petertodd> phantomcircuit: oh cool
15:08 < phantomcircuit> i exploded it into lots of standard sized outputs ages ago
15:08 < phantomcircuit> and every so often do it again
15:08 < phantomcircuit> im sure it's not actually safe
15:09 < phantomcircuit> but it means that finding it is at least non trivial
15:09 < gmaxwell> phantomcircuit: yes, if all the outputs are equal sized you have perfect information theoretic anonymity among all the players.  (or if they nicely factor then you have privacy proportional)
15:09 < gmaxwell> phantomcircuit: thats also why andytoshi's tool tells you which output values are most popular... so you can match them up.
15:10 < phantomcircuit> ah
15:10 < phantomcircuit> gmaxwell, yeah i was just thinking like
15:10 < gmaxwell> if the outputs aren't matched up (or at least factor nicely) then CJ just has the benefit of breaking 'taint' analysis assumptions about common key ownership.
15:10 < gmaxwell> Which is good to do, but not very private.
15:10 < phantomcircuit> 1/0.5/0.25/0.125 etc etc down to the point at which it would be dust
15:10 < phantomcircuit> and then whatever dust there is would pay to the meeting point as a small fee
15:11 < gmaxwell> oh interesting, a fixed cascade.
15:11 < phantomcircuit> or even as a transaction fee
15:11 < phantomcircuit> gmaxwell, yeah then you REALLY couldn't follow anything
15:11 < phantomcircuit> (also it protects against someone intentionally making a weird output size very popular to trick you)
15:12 < andytoshi> hmm, i like this idea
15:12 < gmaxwell> if you're putting in 10 btc though, you really probably don't want to recieve it back as a zillion 0.125 btc outputs.
15:12 < petertodd> phantomcircuit: kinda reminds me: I was thinking coinjoin w/ ANYONE_CAN_PAY is useful because it lets you easily up tx fees by adding dust txin's as needed
15:12 < phantomcircuit> gmaxwell, with HD wallets and public derivation you could even pay everybody like that
15:12 < gmaxwell> petertodd: yea but right now doing anyone can pay makes the CJ transactions very distinguishable.
15:13 < petertodd> phantomcircuit: yeah, we need a way in the payment protocol for recievers to state how many extra addresses they're willing to have payments spread over
15:13 < phantomcircuit> gmaxwell, 10 btc would come back to you as 8/2
15:13 < petertodd> gmaxwell: yup, works best if everyone uses cj...
15:13 < phantomcircuit> gmaxwell, you would still need to be merging approximately the same amounts
15:13 < andytoshi> gmaxwell: if you had, say, fixed output sizes of 10, 5, 1, 0.5, 0.1, that should suffice
15:13 < andytoshi> restricted output sizes*
15:13 < phantomcircuit> but even if you weren't at the very least the smaller amounts would be perfectly anonymous
15:13 < gmaxwell> andytoshi: really? someone puts in 1  someone else puts in 10.  .. now they get no privacy under that scheme.
15:14 < phantomcircuit> gmaxwell, i forget what's the default dust limit for an output?
15:14 < andytoshi> well, you'd combine it with the 'most popular output' scheme
15:14 < gmaxwell> phantomcircuit: e.g. if you get an output of X no one who put in <X would be in the same anonymity set as you.
15:14 < petertodd> Anyway, fixed output sizes are all well and good, but in addition to that you can do value matching: party #1+n to the CJ intentionally picks the same output value for some or all of their txouts as a previous party.
15:14 < phantomcircuit> is it 0.0005 ?
15:14 < andytoshi> but yes, that could be the case
15:14 < helo> 0.00005something
15:14 < phantomcircuit> gmaxwell, right
15:15 < petertodd> Or, even more sophisticated, some output value that is the sum of their txin's and your txins, or some similar strategy.
15:15 < gmaxwell> andytoshi: in any case you can do something like where the biggest output is <= the smallest input, and then you have octaves and you randomly assign people's coins to outputs.
15:16 < maaku> phantomcircuit: coin size doesn't actually matter ... you're only mixing with the people participating in the transaction
15:16 < maaku> and from transaction to transaction you can very the output sizes
15:16 < petertodd> *sum of a subset of their txins and your txins
15:16 < andytoshi> i'd like that, but there's still edge cases (that aren't too extreme) where i'm asking people for 20 addresses
15:17 < gmaxwell> andytoshi: and paying their 10 BTC input as a zillion .125 outputs. :P
15:17 < phantomcircuit> maaku, right but lets say you have 1 input for 200 btc and we explode that into outputs for 128/64/8
15:17 < phantomcircuit> maaku, and there is 1 other input for 10 btc
15:17 < phantomcircuit> only the 8 btc output is anonymous
15:17 < phantomcircuit> the 128 and 64 are both clearly linked to the 200 btc input
15:18 < phantomcircuit> ahah wait
15:18 < gmaxwell> phantomcircuit: ENOTENOUGHDATA
15:18 < phantomcircuit> that's wrong
15:18 < gmaxwell> phantomcircuit: if there are two people with 200 BTC inputs, you're great.
15:18 < phantomcircuit> you can have multiple inputs yourself
15:18 < phantomcircuit> so 10 inputs for 10 BTC and 2 outputs for 50 BTC tells you nothing about who is who
15:18 < gmaxwell> sure sure, I'm trying not to assume that the inputs themselves are already somewhat anonymous.
15:19 < gmaxwell> The hard case is where all the data going in is know, if you're secure in that case you're secure in the easier versions.
15:19 < phantomcircuit> gmaxwell, right neither am i
15:19 < phantomcircuit> gmaxwell, if you have exactly 2 inputs both of which are not anonymous and outputs which are larger than one of the inputs
15:19 < phantomcircuit> then those outputs are clearly linked to the larger input
15:20 < maaku> phantomcircuit: if you perform three 2 party mixes, then you've reduced taint of your original input down to 1:8 ... even if there are a thousand other particpants with that output size
15:20 < maaku> your output is still only one of those eight, and definately not one of the other 992 outputs
15:20 < phantomcircuit> maaku, taint is such a terrible measure :/
15:21 < maaku> well im speaking loosly, not giving taint any specific meaning
15:21 < phantomcircuit> maaku, if you take the larger outputs and merge them receiving ever smaller outputs (ie exploding them into a standard size) then you eventually end up with tons of tiny outputs that are super annoying
15:21 < gmaxwell> The word you want to use is "anonymity set".
15:21 < maaku> in coinswap you do benefit from the size of the crowd, but not coinjoin
15:21 < maaku> phantomcircuit: you don't have to explode your outputs, that's what I'm saying
15:21 < gmaxwell> well coinswap crowd benefits would currently be ~0 due to the fact that escrow transactions are basically non-existing, though that'll change.
15:22 < phantomcircuit> ideally you could get a distribution of who controls the inputs
15:22 < phantomcircuit> maaku, if you dont control your outputs to be standard sizes you'll run into fuzzy statistical matching that is actualyl very very sophisticated
15:23 < phantomcircuit> maaku, in general "dirty" money flowing around the banking system isn't traced by following each hop but rather is traced using fairly broad statistics
15:23 < gmaxwell> phantomcircuit: sure and you can reduce the distribution to a single number— the entropy of the distribution.
15:23 < andytoshi> i think having a 'most popular output', and a small set of standard sizes, would suffice
15:23 < andytoshi> then i'd spin up multiple joiners with different standardsizes
15:23 < phantomcircuit> gmaxwell, hmm
15:24 < maaku> "you'll run into fuzzy statistical matching that is actualyl very very sophisticated" I don't think this is correct
15:24 < phantomcircuit> maaku, the attempts at tracing bitcoins on the network to date have been ... how do i put this nicely? ... not sophisticated
15:25 < gmaxwell> maaku: sure, if your output sizes are not equal, and you exclude the possibility that users aren't doing fun things like paying eachother with imbalanced transactions... then you get some probablity mass for any output that it came from any one of the inputs.. and the distribution isn't flat.
15:25 < gmaxwell> e.g. it couldn't have come from any initial parties that had less coin than it— as the first example.
15:26 < gmaxwell> if you have a chain of transactions then you can say "it could have come from A or B, if and only if Z didn't come from A or B, if Z did then it came from B or C"
15:28 < maaku> Although coinjoin payments throw a muck in that
15:29 < maaku> The anonymity set is bounded by the number of participants, obviously
15:29 < gmaxwell> yea, or fancier things.. like do a CJ transaction where you put in 2 BTC, and I put in 1 BTC...  and I walk away with 2 BTC and you walk away with 1 BTC.  You just paid me 1 BTC... and someone trying to deanonymize with values got an exactly opposite result.
15:30 < maaku> When you limit yourself to standard sizes, you limit yourself to the people actually participating at that level
15:30 < maaku> Whereas if you allow any random output amounts, then there's even mixing between "levels" going on
15:30 < gmaxwell> yea, I don't like _forcing_ sizes, but obviously you get better privacy if you make use of size alignment where it exists.
15:31 < gmaxwell> especially if people are doing things like pay-to-payment where 2,1 becomes 1,2 ... making value analysis unrelable.
15:32 < maaku> I haven't formalized this, by my intuition is that if we let output sizes be a random walk based on availability, or even guided to "equalize" the distribution of outputs, you'd get maximal anonymity that way
15:32 < maaku> Much better than standardizing on fixed sizes, which actually hurts you relative to the anonymity you could achieve
15:33 < gmaxwell> sort of would make an interesting payment protocol addition.  "pay me xxx BTC to yyy, oh yea, and add these extra inputs too— I'll worry about getting them signed"
15:33 < maaku> Yeah that would be a good addition
15:34 < gmaxwell> lets you handle dust consolidation too.
15:40 < phantomcircuit> maaku, the output sizes would then be largely set by the meeting point then right?
15:41 < petertodd> gmaxwell: got a name for that concept? good addition to the payment protocol for sure
15:41 < gmaxwell> its sort of the opposite of change.
15:41 < maaku> phantomcircuit: my design allows participants to set allowed ranges, and the joiner / meeting point decides the actual output sizes
15:42 < maaku> it's fully p2p so all clients spend some time participating in other proposed joins, some time organizing their own
15:43 < phantomcircuit> oh using blinding and what not?
15:43 < phantomcircuit> maaku, are you relying on being able to get tor to give you a new hidden service locally? because it's unpossible to make it do that
15:44 < phantomcircuit> i actually tried to add it as a control instruction but it doesn't seem to work except during initialization
15:44 < phantomcircuit> didn't investigate why though
15:45 < andytoshi> can you do it with two fixed hidden services?
15:45 < maaku> andytoshi: no the anonymous revelation is one-use-only
15:46 < maaku> phantomcircuit: I find that hard to believe, unless I'm misunderstanding what you're saying
15:46 < maaku> all you need is one new circuit to broadcast the revelation message
15:47 < phantomcircuit> maaku, im asking if you need the individual clients to have their own hidden service address
15:47 < phantomcircuit> or whether you have a central meeting point with it's own fixed address
15:48 < phantomcircuit> if you need to generate a hidden service endpoint on the clients side
15:48 < phantomcircuit> you're gonna have a bad time
15:48 < maaku> no you do not
15:49 < maaku> clients have fixed endpoints, but there is no central server
15:49 < maaku> the revelation message only needs to be broadcast on a new circuit
15:49 < phantomcircuit> ok
15:49 < maaku> but it doesn't need a hidden service for that
15:49 < maaku> but it's a complicated question because it's getting into low-level details that could change
15:49 < phantomcircuit> you'll need them to setup the hidden service manually still but at least that is a one time setup
15:50 < maaku> for example I've propsed implementing it over bitmessage, which may or may not need a full hidden service; i don't know
15:51 < maaku> but in principle, you just need to connect over a new circuit and broadcast to a random selection of peers the revelation message, and wait to hear the same message arrive at your normal fixed hidden service port, then disconnect and dissolve the circuit
15:53 < maaku> but to andytoshi's point you certainly don't want the 2nd connection to be fixed, because then you could link successive joins to the same person, under some circumstances at least
15:58 < gmaxwell> maaku: there is a bunch of data that you actually need to make sure are consistent for all the players, or you have a risk of the server deanonymizing people even with multiple real players.. though these things could be addressed with the same mechnism I suggested for address reuse.
15:59 < gmaxwell> but I don't know if it matters all that much just due to the risk that the attacker makes all your counterparties sybs.
15:59 < phantomcircuit> oh and something to keep in mind
16:00 < phantomcircuit> if you're using public derivation with an hd wallet then they can figure out if you're using the same chain by just generating them
16:00 < gmaxwell> phantomcircuit: huh, no— only if you give them an extended public key, and why would you do that?
16:00 < phantomcircuit> gmaxwell, lazyness?
16:01 < phantomcircuit> im pretty sure i've seen at least one person suggesting it
16:03 < gmaxwell> I used a crazy rhetorical stunt on the OTR mailing list today and I think it worked.
16:04 < phantomcircuit> gmaxwell, link?
16:04 < phantomcircuit> or is it postman
16:04 < phantomcircuit> stupid postman
16:04 < gmaxwell> Some guy was arging that MPOTR shouldn't have non-non-repudiation (the OTR denyability property) because it's hard and because people will believe totally unauthenticated transcripts anyways, so the non-non-repudiation buys you nothing.
16:05 < gmaxwell> I responded, and in my response I edited the quotation so that he was saying he was a state sponsored shill.
16:05 < BlueMatt> heh
16:05 < gmaxwell> To which he responded perfectly "It's also unethical to silent change my quote to read something I didn't say."
16:05 < gmaxwell> To which I responded, "Do you mean to suggest that you actually have an ability to refute a
16:05 < gmaxwell> non-cryptographically attested transcript? And that someone might
16:05 < gmaxwell> believe your claim that it was forged?  Interesting."
16:05 < andytoshi> ha!
16:06 < gmaxwell> and ... he seems to have now softened his position! O_o
16:06 < BlueMatt> heh, nice
16:07 < nsh> gmaxwell, could summarize the current status of MPOTR? are there workable algorithms/libraries/architectures?
16:07 < nsh> *could you
16:07 < nsh> that would be a nice thing for everyone to have about now...
16:08 < gmaxwell> nsh: I haven't kept up with it. There is a paper published on it, I read it when it came out, and concluded it sounded sensible and forgot it.
16:08 < nsh> ok
16:08 < gmaxwell> Actually implementing it is hard because the obvious way of achieving it has a consensus problem burried into it.
16:08 < gmaxwell> (fortunately not an anonymous consensus though)
16:09 < nsh> hmm
16:09 < nsh> what is consensuated?
16:09 < gmaxwell> basically you divide the chat into arbritarily short epochs and when everyone agrees an epoch has ended you publish the authentication keys so that all parties could fake the transcript.
16:10 < nsh> hmm
16:10 < gmaxwell> You need a consensus that an epoch is over, or someone could trick you into disclosing your authentication key prematurely, and then create forged messages from you for anyone else who doesn't believe the epoch is complete.
16:10  * nsh nods
16:11 < gmaxwell> This is all a problem because you want the property that no chart participant can pretend to be any other in realtime, but later any party can create a forged transcript.
16:11 < gmaxwell> s/chart/chat/
16:11 < gmaxwell> If you don't care about the people pretending to be each other there are a bunch of simple things to do.
16:12 < nsh> hmm
16:12 < gmaxwell> OTR does the same thing, but 2 party consensus is trivial. :P
16:12 < nsh> aye
17:00 < jrmithdobbs> you can't "get it out"
17:01 < jrmithdobbs> erm, wrong channel
17:43 < phantomcircuit> jrmithdobbs, lol @ no context
19:01 < gmaxwell> andytoshi: ... bad luck on that thread on bitcointalk.
19:02 < Luke-Jr> luck? O.o
19:08 < andytoshi> haha
19:08 < andytoshi> i think i made him look like enough of a tool that people will hesitate to use his software
19:09 < andytoshi> (not that people who need encryption would be searching bitcointalk anyway)
19:09 < jrmithdobbs> andytoshi: still waiting on that to work with tux
19:24 < BlueMatt> are there any serious or semi-serious proposals for how to fix an altcoin 1:1 to bitcoin without a large cost to bitcoin miners given some hardfork changes to bitcoin?
19:26 < gmaxwell> if not for the disabled operators you could probably do it without hardfork changes to bitcoin, though you would only have SPV security in the altcoin-bitcoin direction.
19:27 < BlueMatt> even getting spv security in the altcoin-> bitcoin direction is non-trivial, no?
19:27 < BlueMatt> (given hardfork to reenable opcodes)
19:27 < BlueMatt> you'd have to have the whole chain history, or some subset starting from the time of the bitcoin->altcoin transfer
19:28 < BlueMatt> well, whole block-header-chain-history
19:28 < gmaxwell> yea, you just write a script that can do a spv validation and then takes a chunk of headers of a prespecified sufficient difficulty.
19:28 < gmaxwell> the proof can start at the point the txn of interest was mined.
19:28 < BlueMatt> that gets pretty expensive?
19:28 < gmaxwell> I mean, it's 80 bytes per header. so not really.
19:29 < BlueMatt> very expensive if you hold the alt for an extended period...
19:29 < BlueMatt> well, no miner is gonna mine a tx that is 80 bytes*N where N is a few weeks/months of headers
19:29 < gmaxwell> BlueMatt: oh no, you don't do it over the life of the alt.
19:29 < gmaxwell> crazy no no thats not how it works.
19:30 < gmaxwell> you take some coin and assign it to a scriptPubKey that can be redeemed by anyone who provide a SPV fragment from the altcoin showing any of those coins being reassigned back to bitcoin, with a sum difficulty of at least X.
19:30 < adam3us> gmaxwell, BlueMatt: a 1:1 peg - doesnt that import security risk from the alt into bitcoin? (i suggested a 1 way peg "bitcoin staging" only so bitcoin is security firewalled) are we talking about the same area of feature
19:31 < gmaxwell> adam3us: only to the limit of the alt. say the alt was somehow totally insecure... you could then steal all the bitcoins that had been assigned to the altcoin.
19:31 < gmaxwell> but no more.
19:32 < adam3us> gmaxwell: hmm that might be ok
19:32 < BlueMatt> adam3us: what gmaxwell said (if you decide to put your btc in the alt, sucks for you)
19:32 < gmaxwell> BlueMatt: one problem there is that isn't really spv security, its "spv transcript" security, in that the bitcoin network isn't going to go out and find a longer chain.
19:32 < adam3us> BlueMatt: yes that is an acceptable trade off and already at risk with a 1-way peg
19:33 < gmaxwell> BlueMatt: But I did come up with a way to boost that to more like real SPV security with a bit more script power.
19:33 < BlueMatt> gmaxwell: well, ok, sum difficulty is one way...but very non-ideal
19:34 < gmaxwell> (you make the relase of coins back into bitcoin two phase. The first phase you do a header proof for the release.. and that gets mined.. but it can only output to a special holding script with the following rules:
19:35 < gmaxwell> after N blocks the releasing party can grab the coins. OR at any point, any party can show a longer chain to prove the release was bogus. and then they can only be redeemed with a new release on a chain longer than that one.
19:35 < gmaxwell> In any case I think most of the stuff thats been said of any technical substance on this is in the coinwitness thread (where I suggest using SNARKs for C to compact the proofs, though its not essential): https://bitcointalk.org/index.php?topic=277389.0
19:36 < gmaxwell> obviously if you compact the proofs things start sounding more interesting from a scaling perspective.
19:37 < gmaxwell> also if the headers of the altcoin form a MMR (insertion ordered binary tree) it may be cheaper to prove long spans of difficulty.
19:37 < BlueMatt> yea, though depending on cutting-edge crypto is ugly...
19:38 < gmaxwell> BlueMatt: well there are less ambitious (efficiency wise) ways to construct these proofs, but they're larger... though I'm not sure if we could get the direct proofs down with special support. Maybe.
19:38 < gmaxwell> SPV fragments can be pretty small.
19:39 < BlueMatt> yea, its all a bit expensive, really
19:39 < BlueMatt> it would be fun to be able to peg arbitrary altcoins to bitcoin as it really addresses the issues altcoins cause
19:40 < BlueMatt> allows them to innovate (ie risk people's money) while not costing bitcoin's digital scarcity/competing on store-of-value
19:40 < gmaxwell> BlueMatt: one way is easy— just have them validate bitcoin too.
19:40 < adam3us> BlueMatt: agreed
19:41 < gmaxwell> BlueMatt: one point is that you could coinjoin your cross chain merges perhaps, to make them smaller. e.g. one proof and then a dozen transactions hop the gap.
19:44 < BlueMatt>  gmaxwell sure, but if you only peg one-way its really not particularly useful
19:44 < BlueMatt> well, it is, but not as useful
19:44 < BlueMatt> gmaxwell: sure, you could limit to like 1 coinjoin'd alt->btc tx per day
19:45 < BlueMatt> but even that could be expensive
19:45 < gmaxwell> I dunno, I mean, it's a seralized transaction and spv proof, plus some additional headers.
19:45 < BlueMatt> well, if you have 100 alts all doing that, it does
19:46 < adam3us> BlueMatt: I like 1:1 peg idea, I only suggested 1-way peg to insulate security, if you can insulate security to the coins in the alt, thats even better
19:47 < BlueMatt> as long as you limit it to the people who transferred their coins...
19:47 < BlueMatt> gmaxwell: hmm...
19:47 < gmaxwell> lets say there are 2^12 txn per altcoin block, ... lets imagine you make the altcoin txn themselves hashtree so you can get to only their outputs.. so say maybe 64 bytes for the altcoin output, 384 bytes for the spv tree. 4 bytes for a spv index, and 12 80 byte headers = 1.4k.
19:48 < gmaxwell> it's bigger than a typical ecdsa signature, but not murderous.
19:48 < gmaxwell> and if they coinjoin the biggest parts (960 bytes of headers, 384 bytes of hashes) can be shared.
19:49 < gmaxwell> adam3us: yea,  I don't think there is a security need to make it one way. If you can never "pull back" more from an altcoin than was sent to it, then only the holders of the altcoin are at risk.
19:50 < adam3us> gmaxwell: seems plausible indeed, i just didnt think of it in those terms at the time.  good
19:51 < gmaxwell> the altcoin is also a bitcoin node, and monitors bitcoin for coins assigned to the altcoin, and then permits someone on the altcoin to emerge those coins from thin air.. and then when you want to send them back you make a special transaction in the altchain and prove you did it to bitcoin.
19:51 < adam3us> gmaxwell: i suppose the other thing is it itself requires bitcoin changes, perhaps non-trivial ones, and that is part of the reason for the exercise.
19:51 < gmaxwell> yea, unfortunately it requires changes to bitcoin.
19:52 < gmaxwell> we could _almost_ do it in script without the disabled opcodes, but there are enough little corners that I suspect we can't.
19:52 < adam3us> gmaxwell: but an interesting enough change perhaps for motivation to be there as it creates an avenue for value preserving experimentation
19:52 < BlueMatt> 12 blocks seems shallow to me given most altcoins have no miners...
19:53  * BlueMatt thinks this solves the "alt problem"
19:53 < adam3us> BlueMatt: probably have to overcome the merge mining / side chain incentive problems somehow
19:53 < adam3us> BlueMatt: yes i like it a lot :)
19:53 < adam3us> ***adam3us wants to destroy all new digital scarcity race alts
19:53 < gmaxwell> BlueMatt: namecoin's difficulty is 81% of bitcoin's.
19:53 < BlueMatt> gmaxwell: really? wow
19:54 < adam3us> gmaxwell: thats because of heavy merge-mining tho because its been around for a long time
19:54 < gmaxwell> I seem to recall telling you this at the meetup here too. :P
19:54 < gmaxwell> adam3us: sure, but this would be merged mined too.
19:54 < gmaxwell> Now, one annoying issue is that MM makes the @#$#@$@# SPV proofs much bigger. :(
19:56 < BlueMatt> gmaxwell: though it does mean bitcoin miners with bitcoin blocks can do more verification :)
19:56 < gmaxwell> basically doubles the hashtree size plus the size of a bitcoin coinbase.
19:56 < BlueMatt> (though not with existing disabled script opcodes)
19:56 < gmaxwell> in any case, its doable and not unrealistic.
19:57 < BlueMatt> personally, if there's one feature we should enable in bitcoin (testnet) its this
19:57 < gmaxwell> it's not even a hardforking change in bitcoin.
19:57 < BlueMatt> but, we need f**$@#%@ reviewers
19:58 < gmaxwell> it can be deployed like p2sh.
19:58 < BlueMatt> well, to re-enable the script opcodes...
19:58 < gmaxwell> well this needs a bit more than script opcodes, and really, to make it efficient it would probably best be implemented directly.
19:59 < BlueMatt> yes
20:00 < gmaxwell> one optimization would be to have only SPV security inside bitcoin for those proofs too.
20:01 < gmaxwell> E.g. the txn that releases coins in bitcoin has just a hash of the proof in its scriptsig.  the actual proof must be provided along with blocks but only until they're sufficient burried in bitcoin.
20:01 < gmaxwell> (after all, if the emergence in the other chain has only SPV security, no reason to have better security in bitcoin)
20:01 < adam3us> gmaxwell: i was going to ask how does bitcoin know the transaction is non orphan on the alt?
20:02 < gmaxwell> adam3us: thats what the 12 or whatever headers are for from the alt.
20:02 < adam3us> gmaxwell: i might make it 100 like mining confirmations
20:03 < BlueMatt> 100 was fairly arbitrary
20:03 < BlueMatt> though I dont like 12...
20:03 < gmaxwell> whatever, the altcoin could actually signal it with something in its headers.
20:04 < BlueMatt> yea
20:04 < gmaxwell> the big problem with making it big is that it creates a release delay in moving the coins back.
20:04 < BlueMatt> meh, who cares
20:04 < BlueMatt> even if the release delay is a day...
20:05 < gmaxwell> there are altcoins with 30 second blocks that advertise confirmed = 3 blocks …
20:05 < BlueMatt> meh, I dont care about altcoins that are working at dumb knob-tweaking, I'm talking about altcoins that do actually useful research
20:06 < gmaxwell> well, its a fungiblity thing. It's not really a bitcoin if it has a 24 hour ramp to move across. But one interesting thing is this:  You could do CoinSwaps nearly instantly with reasonable security.  So the real migration doesn't need to be fast because it's only needed to correct long term imbalances.
20:07 < BlueMatt> yep, thats what I was thinking
20:07 < BlueMatt> its really only to peg the value, not to act as something that need be traded regularly
20:07 < adam3us> gmaxwell, BlueMatt: yes agreed; cross chain atomic swa
20:08 < adam3us> gmaxwell: even with 1-way peg i was thinking it should have mostly balanced
20:08 < gmaxwell> (coinswaps require there to be two parties, one that wants altBitcoin and has bitcoin, one that wants Bitcoin and has altBitcoin...  nice little trading business... but you need the bulk moves in order to not be constantly going broke on one side or the other)
20:09 < gmaxwell> and yea, in that case requiring 100 headers would be fine.. (but damn that would really bet nicer with a snark than 8kb++ of header data in the txn)
20:19 < andytoshi> arguably, this is exactly the way to experiment with snarks
20:19 < adam3us> andytoshi: unless its your bitcoins in the alt :)
20:20 < andytoshi> :P that's right, i keep forgetting these things are so valuable
20:23 < gmaxwell> IMO SINs are the best snark expirment. :P
20:25 < gmaxwell> BlueMatt: some extra points you might have already realized: the altcoin itself can do the "coinjoin". You make a tx there with a special ToBitcoin Txout and it adds a scriptPubKey to a list maintained by miners, and every {interval} that list is published in the block in a location that makes the proof for it really compact (e.g. at the top of the hashtree) and it has all the values and scriptpubkeys that need to move over.
20:25 < BlueMatt> yep
20:26 < BlueMatt> wait...can you do rolling outputs to the alt?
20:26 < gmaxwell> The next is that point I made about the redeem transaction being temporarly locked and 'reversable' via a longer chain means you don't need to have a long proof.. just a couple headers to prevent a dos attack, if someone cheats someone will unsteal the coins with a longer proof.
20:26 < gmaxwell> thats rolling outputs from the alt to bitcoin.
20:27 < BlueMatt> ie the alt always has one and only one output to it (if its in the standard form, anyone can create the next txn) that keeps track of all the outputs to the alt, and then to spend, you have to provide spv proof from the previous roll to the currnet chain?
20:27 < gmaxwell> yea thats what I was imagining the whole time.
20:27 < BlueMatt> ahh, ok, yea
20:28 < BlueMatt> somehow I was only picturing individual outputs and arbitrary spv proofs back some fixed distance
20:28 < BlueMatt> gmaxwell: some of us are slow :p
20:28 < gmaxwell> nah, then you get into granularity problems. :P sorry.
20:28 < gmaxwell> darnit I had one more idea and now I'm forgetting it.
20:29 < BlueMatt> yea, it seemed to not scale...
20:29 < maaku> BlueMatt: give altcoins an annual demurrage rate of 50%
20:30 < gmaxwell> oh, how they pay their miners? I figured miners in the alts would be purely paid by transaction fees.. in bitcoins.
20:30 < BlueMatt> gmaxwell: yes, thats something I was largely ignoring for complexity reasons...needs thought
20:30 < BlueMatt> maaku: hmm?
20:30 < amiller> that's a neat question, BlueMatt.
20:31 < gmaxwell> BlueMatt: oh ohoho  the other point wrt security.... nothing stops bitcoin miners from also validating the altchains, they're just not required to. So if they do see a bogus proof they can just ignore it unless it gets into the chain.
20:31 < maaku> was reading the log; that's for experimentation in an altcoin without threatening bitcoin as a store-of-value
20:31 < BlueMatt> maaku: well, there are plenty of ways to accomplish it, I just wanted to do it while allowing good scaling/storing value in btc in altchains
20:32 < BlueMatt> gmaxwell: hmm, yes
20:32 < BlueMatt> fun
20:32 < gmaxwell> though I think since we're willing to tolerate long release times, the ability to unsteal with a longer header is pretty good.
20:33 < BlueMatt> yup
20:58 < valek1024> hello
20:59 < valek1024> can someone point me in the right direction for selling my 2011 first month of mint casascius bitcoin with the error in the hologram. the error is a misprint in the background of the hologram the casascius is missing the middle s
21:00 < BlueMatt> terribly, terribly wrong channel
21:01 < valek1024> ty bluematt i understand i am in the wrong place but as wizards should't you be able to help?
21:01 < maaku> ebay?
21:02 < BlueMatt> valek1024: no, we cant help, go elsewhere
21:02 < maaku> valek1024: we could design you a secure multi-party cryptographic auction protocol
21:03 < maaku> but finding buyers is your job ;)
21:03 < maaku> maybe #bitcoin
21:03 < valek1024> see that is helpfil
21:03 < valek1024> helpful
21:04 < midnightmagic> No. #bitcoin-otc for selling goods.
21:04 < valek1024> there is and was no reason to be rude sir, i was simply asking for help
21:04 < midnightmagic> #bitcoin will boot for that.
21:05 < BlueMatt> (we should too)
21:41 < adam3us> gmaxwell, BlueMatt: suggest to write this up and get further details and efficiency worked out.  i think its potentially very useful to combat the remaining rationale for the existence of alts (other than enriching their creators, preminers and early rented vsp early miners before their no real transaction bubble bursts)
22:34 < gmaxwell> adam3us: it also adds to the scalablity dialog... but perhaps what we should do is just do a trial implementation.
22:35 < BlueMatt> gmaxwell: yes!
22:35 < BlueMatt> you should totally find time to do that
22:36 < adam3us> fantastic :) i can maybe help out in some way
22:37 < BlueMatt> keyword *you*
22:37 < gmaxwell> Tweedledee coin, and tweedledum coin.
22:40 < BlueMatt> heh, yup
22:41 < andytoshi> are the currently available snarks viable for a trial implementation?
22:41 < andytoshi> don't these proofs take days to generate?
22:47 < amiller> andytoshi, you can download pinocchio and use it now
22:48 < adam3us> andytoshi: if at all possible i would suggest to start with seeing how efficient it can be made without dependence on snark, bitcoin has simple & conservative crypto assumptions so far and that is a feature
22:48 < amiller> andytoshi, it unsurprisingly relies on a windows binary kernel to run the actual fast crypto, but most of their actual work is in python and they're almost done making it fully open
22:48 < amiller> andytoshi, it takes 15 seconds on a single core to prepare a proof about SHA1 on a small input
22:49 < amiller> andytoshi, you can also use pantry, it's fully open but has baffling dependencies and i haven't personally gotten past that
22:50 < andytoshi> awesome, i'll check them both out
22:50 < andytoshi> adam3us: i think you are missing the point :)
22:51 < adam3us> andytoshi: to not lose bitcoins and enable alts to respect the 21 mil digital scarcity?
22:51 < andytoshi> no, to be a wizard ;)
22:53 < adam3us> andytoshi: homomorphic encryption is cool too, but impractically inefficient.  snark is cool and related and practically efficient, but has some newer crypto assumptions in my view.  you dont want an alt to go up in smoke if someone finds a mathematical flaw in the deployed pairing params (eg)
23:01 < amiller> in my view, the effort of trying to optimize an implementation of traditional homomorphic encryption is almost certainly an overoptimization
23:02 < amiller> er premature optimization
23:03 < andytoshi> well, that'd be a research project in itself
23:09 < andytoshi> hey, pantry was developed partially here at UT austin
23:09 < andytoshi> i can track these people down and ask how to build it :P
23:11 < Luke-Jr> andytoshi: wait, you're in Austin? :o
23:12 < andytoshi> Luke-Jr: i started my ph.d. here this september
23:13 < andytoshi> i'm usually from vancouver
23:13 < Luke-Jr> andytoshi: doh, I was just there last week XD
23:13 < Luke-Jr> coulda met up
23:14 < andytoshi> oh! damn
23:15 < andytoshi> if we had a picture together, that'd show altoz that i'm not a sock puppet..
23:16 < Luke-Jr> altoz is silly, complaining that we're being rude(⁈) when his posts are the only ones that strike me as particularly rude O.o
23:16 < andytoshi> yeah, i read through yours just to be sure, and that's my interpretation too
23:16 < andytoshi> all i did was post a link and say "don't be rude" :P
23:17 < Luke-Jr> about the rudest thing I did IMO was decide I wasn't responding to some stupid comments of his <.<
23:18 < andytoshi> "
23:18 < andytoshi> I am using ECIES, I think. I would need a more experienced cryptographer to examine the code to make sure, but it's fairly straightforward."
23:18 < andytoshi> this is his latest resposne to "are you using ECIES?"
23:19 < andytoshi> imo you should've been much ruder :P
23:20 < Luke-Jr> lol
23:27 < gmaxwell> andytoshi: only the pinocchio (without the pairing crypto backend. :( ) and the pantry system are available
23:30 < andytoshi> you mean the zk-snark stuff is not public?
23:34 < amiller> pantry and pinocchio are both zk-snarks
23:34 < amiller> there are three zk-snark implementations, pantry, pinocchio, and tinyram, of these tinyram is not yet available
23:36 < andytoshi> oh, i see, thanks
23:37 < andytoshi> i have only read the first couple pages of this latest paper, i think it talks a lot about the background
23:37 < andytoshi> so i'll try to get straight what's been happening in this field
--- Log closed Wed Dec 18 00:00:05 2013