--- Log opened Fri Jan 10 00:00:20 2014
00:02 < Luke-Jr> maaku_: what error?
00:03 < Luke-Jr> that statement quoted is essentially correct
00:04 < maaku_> which is why i said it's pretty minor
00:04 < maaku_> more like bytecode than a programming language (which implies compilation)
00:05 < maaku_> and i don't know anyone who calls it Script with a capital S
00:05 < Luke-Jr> meh, we have an assembly-like form :P
00:05 < Luke-Jr> maaku_: it's not that uncommon
00:13 < justanotheruser> What do you guys recommend as a proof of sacrifice? Hashcash is more anonymous, but it doesn't work well (someone with a powerful hashing maching/GPU could make a ton of messages) and OP_RETURN associates the sacrifice with you to some extent and remove anonymity. Is there anyway I can get the best of both worlds?
00:16 < gmaxwell> justanotheruser: depends on the application, if you'd really be willing to use hashcash, perhaps mine.
00:18 < justanotheruser> gmaxwell: perhaps mine? What do you mean by that. I wouldn't want to use hashcash if it allowed people with special hardware to spam the network with as much electricity spent as a regular CPU user.
00:18 < justanotheruser> Application is bitmessage fork that isn't vulnerable to the problem I just described
00:20 < gmaxwell> justanotheruser: zero knoweldge proof of a bitcoin sacrifice using pinocchio.
00:21 < justanotheruser> gmaxwell: is that bleeding edge crypto?
00:22 < gmaxwell> yea? so. and a flooding messaging system isn't?  the harm of someone breaking it is they can flood your system, whoopiedo.
00:23 < justanotheruser> gmaxwell: I was just curious if there were any other applications in use, or if it was just knowledge from research papers
00:23 < gmaxwell> justanotheruser: I suggested pinocchio because you can go download an implementation.
00:25 < justanotheruser> gmaxwell: where would I find this? Every top google result is research papers and news
00:26 < gmaxwell> https://vc.codeplex.com/
00:26 < justanotheruser> gmaxwell: thanks a lot
00:26 < gmaxwell> They've annoying ripped out the pairing library so one will need to be pached back in.
00:27 < gmaxwell> justanotheruser: in any case, I think bitmessage pow would be a great application for this.
00:30 < justanotheruser> gmaxwell: ofcourse your anonymity is limited to the recent proof of burns
00:30 < justanotheruser> right?
00:32 < gmaxwell> you make a sacrifice that contains X=H(random_value)  and then to send a message you prove X is in a sacrifice of value >= Z in bitcoin (by evaluating a SPV proof for the transaction), and random_value is the preimage of X,  and that Q=H(random_value||date||hour), and that R=H(random_value||pubkey). And you show the network the proof and Q,R,pubkey and sign your message with the pubkey.
00:32 < gmaxwell> you basically can get a new anonymous identity from each of your sacrifices once an hour, and then send however many messages the network will let you per identity (maybe just 1)
00:33 < gmaxwell> next hour you redo the proof with a new pubkey, and you have a new anonymous identity.
00:33 < gmaxwell> and you don't have to keep redoing sacrifices.
00:34 < gmaxwell> (unless you wanted to require that)
00:34 < justanotheruser> pubkey is separate from the pubkey I used to make the PoB right?
00:35 < gmaxwell> you wouldn't even need a ecdsa pubkey in the PoB, effectively H(random_value) is a pubkey in the proof of burn.
00:35 < justanotheruser> oh
00:35 < gmaxwell> You don't want to run ecdsa inside the zkp because its @#$@ expensive. Where running a hash inside the proof is more realistic.
00:35 < justanotheruser> what I mean by that is I use a pubkey to spend the output to OP_RETURN
00:36 < gmaxwell> yea, thats irrelevant. youd put H(random_value) in the OP_RETURN and the only thing the proof would look at is the txout value and H(random_value).
00:36 < justanotheruser> if that is the correct terminology, not sure what else you would call spending a transaction to something that always returns false
00:37 < justanotheruser> gmaxwell: I will be able to write stuff in OP_RETURN in v.9 right?
00:37 < gmaxwell> I'd say that even better than a scarifice would just be proving that you have possession of a bitcoin, but to do that you'd have to do a ecdsa signature inside the proof, and that would kinda suck.
00:37 < Luke-Jr> justanotheruser: no
00:38 < justanotheruser> gmaxwell: I don't see how proving you have bitcoins would help in the future when everyone might be transacting bitcoins
00:38 < justanotheruser> Luke-Jr: whenever the miners vote on it?
00:38 < Luke-Jr> justanotheruser: hopefully never
00:38 < gmaxwell> wtf. there is no "miners vote on it"
00:38 < Luke-Jr> and there will never be an interface to do it in any sane client
00:38 < gmaxwell> as of right now in git bitcoin allows data in OP_RETURN though given what people are saying I hope we back that out.
00:39 < gmaxwell> or at least cut it back to 32 bytes.
00:39 < justanotheruser> gmaxwell: I thought miners voted on whether or not they would mine a certain tx type and if a certain amount said yes it would be implemented and the miners would start mining it
00:39 < gmaxwell> justanotheruser: no.
00:39 < gmaxwell> dunno where the heck you got that idea!
00:39 < justanotheruser> gmaxwell: some other fork I remember miners including their votes in their blocks
00:40 < justanotheruser> maybe it's because that was a hardfork?
00:40 < Luke-Jr> there's no fork going on
00:40 < Luke-Jr> at all
00:40 < gmaxwell> why are you talking about forks?
00:40 < justanotheruser> gmaxwell: Well isn't OP_RETURN <data> an invalid tx?
00:40 < Luke-Jr> no
00:40 < gmaxwell> No.
00:40 < Luke-Jr> just a useless, spam tx
00:40 < justanotheruser> oh, well that's where I was getting that idea from
00:40 < gmaxwell> it's just not IsStandard
00:42 < justanotheruser> "So, with some reluctance, I recently merged pull request #2738 : “Relay OP_RETURN data TxOut as standard transaction type.”" - gavin andresen
00:42 < justanotheruser> So will it be standard in .9?
00:42 < Luke-Jr> hopefully not
00:43 < justanotheruser> gmaxwell: also, how is it a sacrifice to prove you possess bitcoins?
00:43 < gmaxwell> 21:38 < gmaxwell> as of right now in git bitcoin allows data in OP_RETURN though given what people are saying I hope we back that out.
00:43 < justanotheruser> gmaxwell: oh, I missed that
00:44 < gmaxwell> justanotheruser: it's not, but what you want is a resource rate limiter. You want to give each user 1/Nth of the capacity, but since users are anonymous you need a way of to prevent a user from claiming that they are 100 users and gobbling it all
00:44 < gmaxwell> holding bitcoin at a particular instance of time is something that prevents unlimited cloning.
00:46 < justanotheruser> gmaxwell: I suppose an attack on the network would cost as much as in a system with PoB because they would have to create a large number of new addresses with coins and pay the tx fee for all those just like if they were doing a large number of burns
00:47 < gmaxwell> yea, well I think a real sacrifice is stronger, but it's not clear to me that something bitmessage like would need a real one, and just showing you were holding coins as of a daily txoutset snapshot would be easier to accept for users, I suspect.
00:48 < gmaxwell> in any case, I also think that because of the aformentioned ecdsa an actual sacrifice would be easier to implement.
00:48 < justanotheruser> gmaxwell: funny to see you promoting proof of stake btw :D
00:49 < gmaxwell> justanotheruser: PoS is fine, so long as you're not expecting it to operate its own consensus.
00:49 < justanotheruser> yeah
00:49 < gmaxwell> you could mine a PoS altcoin based on bitcoin holdings, you just can't the chain itself. :P
12:08 < jtimon> petertodd why does litecoin need a softfork?
12:45 < petertodd> jtimon: to implement height in coinbase, and warren wants to see single-satoshi dust made unspendable
12:46 < jtimon> thanks
12:46 < jtimon> so are they making a protocol antidust rule?
12:47 < petertodd> jtimon: yup, if nValue == 1 satoshi treat the output like a provably unspendable OP_RETURN
12:47 < jtimon> is not only in isStandard, interesting
12:47 < sipa> petertodd: why not 0 satoshi?
12:47 < sipa> what makes 1 special?
12:48 < petertodd> jtimon: Note that this *isn't* because doing so will actually have a big impact on anything, but rather the argument is to do it "symbolicly" for future, more invasive, anti-dust efforts.
12:49 < petertodd> sipa: Litecoin had a bunch of 1 satoshi dust spam a while back, and it's conceivable that a future soft-fork feature might want to use 0-value outputs for something.
12:49 < jtimon> we haven't even make sub satoshi (sub-kria) outputs unspendable in freicoin. Yes, demurrage still applies to a single satoshi so you won't be able to spend it, but you may want to spend 0 coins?
12:50 < petertodd> Indeed, zero-output txouts could be used to implement a increased divisibility soft-fork for instance.
12:50 < jtimon> well, maaku was reluctanct to have any form of escheatment
12:50 < jtimon> yes, and we also plan to increase divisibility on freimarkets so...
12:51 < petertodd> Add nNewValue to transactions and define nSumValue = nNewValue + nValue, then do divisibility by moving value from nValue to nNewValue, which means you can re-combine sub-satoshi outputs, it's just that old clients can't see the fact you've done so.
12:52 < petertodd> Note how this depends on the fact that miners can destroy coins forever rather than taking them as fees.
12:53 < jtimon> I think that's what we have in freimarkets
12:53 < jtimon>     nValue :: int64
12:54 < jtimon>     dValue :: decimal64
12:54 < jtimon>     dValue = nValue * 10^369
12:54 < petertodd> Oh, interesting!
12:54 < jtimon> but maaku told me that gmaxwell told him we're not using nVersion as it was intended
12:54 < petertodd> how so?
12:54 < jtimon> I'm not sure I did understood that
12:54 < petertodd> how are you using it?
12:55 < jtimon> for us version 2 are transaction with an additional refHeight, necessary for calculating demurrage
12:55 < jtimon> so all freicoin transactions are v2
12:55 < petertodd> is refHeight actually a different binary format?
12:56 < jtimon> and freimarkets introduces v3 with more modifications
12:56 < jtimon> it's an additional field
12:56 < petertodd> right, nVersion was meant to signify to *interpret* a otherwise backwards-compatible transaction differently
12:56 < jtimon> so if bitcoin were to adopt freimarkets, interest bearing assets could be moved with v2 transactions
12:57 < jtimon> ours aren't backward compatible, are hardfork changes
12:59 < jtimon> here's the commit that adds nRefHeight: https://github.com/freicoin/freicoin/commit/cee818350d857029e0e7148fece35646d479aea1
12:59 < petertodd> for instance P2SH could have been done with a nVersion bump
13:01 < jtimon> but some other version number was changed for that, no?
13:01 < petertodd> jtimon: right, you could have done that as a soft-fork
13:01 < petertodd> jtimon: no, that was done with voting by putting the string "P2SH" in the coinbase - not a great mechanism
13:02 < petertodd> jtimon: the "height in coinbase" soft-fork was a lesson learned there, and was done with a CBlock.nVersion bump.
13:02 < petertodd> jtimon: oh, sorry, and come to think of it the voting *wasn't* software evaluated
13:02 < petertodd> jtimon: IE, miners "voted", then a bitcoin was released that turned on P2SH on a specific day IIRC
13:03 < petertodd> eh, I might have to double-check the code for that, don't quote me :)
13:04 < jtimon_> petertodd: "right, you could have done that as a soft-fork" what? adding the nRefHeight field?
13:04 < jtimon_> anyway, the tx-nversion looked ideal for our changes, I'm not sure what we should use instead
13:05 < petertodd> jtimon_: yeah, you'd do it by just recording nRefHeight in a different datastructure that was stored along-side the block
13:05 < jtimon_> no, no
13:05 < jtimon_> the nRefHeight goes with EACH transaction
13:05 < petertodd> Yes, and along-side the block you store an nRefHeight array for each tx.
13:05 < jtimon_> oh, I see
13:06 < jtimon_> but...
13:06 < jtimon_> that number has to be signed
13:06 < jtimon_> it really belongs in the tx
13:06 < petertodd> See, what might be good is a hard-fork to allow arbitrary junk to go at the end of CTransaction's, and then forever after you could add new fields in soft-forks by bumping nVersion.
13:07 < jtimon_> interesting
13:07 < petertodd> jtimon_: oh right, well, that's another thing: SignatureHash() should have been written so that the presence of unknown flags makes the signature always evaluate as true, so that new flags could be defined in soft-forks.
13:07 < petertodd> Additionally you need different OP_CODESEPARATOR there too, long story. :P
13:09 < petertodd> (well, actually, better to only define *some* of the unused flag bits as "return true")
13:09 < petertodd> (though an even better system wouldn't have a "all-in-one" CHECKSIG anyway, but I digress)
13:09 < jtimon_> well, I think it was much simpler to just add the nRefHeight field after nLockTime (if I remember correctly, that's where it is)
13:09 < petertodd> sure, given you're doing a hard-fork
13:10 < jtimon_> so there's no way to signal hardfork versions for transactions?
13:10 < petertodd> point is, if you're doing a hard-fork you don't have too really
13:11 < jtimon_> well, it just simplifies the implementation, since older versions will still work the same
13:11 < petertodd> yeah, older code
13:12 < gmaxwell> petertodd: sig flags are set by the signer. So I write a txn with an unknown flag and freely spend your inputs. :P
13:13 < jtimon_> I guess we will keep using the nVersions even if it wasn'te the purpose for a lack of a better alternative
13:14 < petertodd> gmaxwell: gah, damn, that's right
13:14 < petertodd> gmaxwell: yeah, guess that just leaves the OP_CODESEPARATOR solution so you can put arbitrary signed data in the scriptSig
13:15 < jtimon_> the "junk-at-the-end-of-the-tx and nversion for softfork additional fields" is really interesting though
13:16 < petertodd> yup, basically you just need to hard-fork in a total-transaction-length field and then go nuts
13:17 < petertodd> you probably want OP_CHECKSIG to be made to include the *contents* of the extra data in the signature hash, which nicely can be done backwards compatibile - generally the extra contents are empty
13:17 < shesek> though it'll make it impossible to prevent arbitrary data storage on the blockchain, as something like p2sh^2 intends to do
13:18 < gmaxwell> petertodd: on another subject I don't know if you saw my musing;  wrt coinbase only pooling, if the payout is to some M of N keys,  then shares could be submitted to N entities and they could share the shares to achieve a consistent state and then do consensus signing of payouts. So you can even distribute the payout trust in coinbase only mining.
13:18 < petertodd> shesek: if you genuinely make arbitrary data storing impossible you've probably made future soft-forks difficult to impossible
13:18 < petertodd> shesek: e.g. you need to change the signature algorithm, now what?
13:19 < maaku_> are all forms of transaction storage length prefixed though?
13:19 < petertodd> gmaxwell: ha, nice
13:19 < gmaxwell> petertodd: also the entities need only about 1mbit/sec of bandwidth if you assume eligius' current user count and that each user is targeting 4000 shares / day  (which gets them to the point where weekly performance <98.5% if less than 1% likely)
13:19 < petertodd> maaku_: not yet, but they can be made to be in a hard-fork
13:19 < helo> would those then be unspendable for 100 blocks?
13:19 < gmaxwell> which means you could easily support additional observer entities over the N.
13:19 < maaku_> regardless though I don't think it will work - before the soft-fork the length-extending version means nothing, after it means there's extra bytes
13:20 < petertodd> maaku_: doing that in a soft-fork is much less trivial, I'm talking about a hard-fork
13:20 < maaku_> well ok, i guess it'd work if every instance of transaction storage is made length prefixed
13:20 < gmaxwell> helo: the payouts in what I'm talking about? yes.
13:20 < petertodd> gmaxwell: not bad
13:21 < gmaxwell> helo: The payouts to the pool itself are generated, the payouts to the users would be instant spendable.
13:21 < maaku_> our current approach (for freimarkets, freicoin we screwed up) is to have the block height indicate the hard-fork transaction format
13:21 < gmaxwell> (I think doing coinbase payments in such a model would add a lot of complexity for not a ton of data)
13:21 < petertodd> gmaxwell: (U)TXO commitments should be structured such that multiple low-bandwidth parties can create a block co-operatively. Shouldn't be too hard to pull off in a trusted scenario, harder in untrusted. (though could be fidelity bonded)_
13:22 < maaku_> which is somewhat undesireable around the transition, although that is one-time and can be mitigated by creating new-format transactions early
13:22 < petertodd> maaku_: that's reasonable, although remember that you can do a nVersion voted hardfork too
13:27 < jtimon_> kind of off-topic, but now that you're talking about coinbase...nVersion=2 of joke I think I heard here
13:29 < jtimon_> The success of coinbase surprises me given that their transactions take 100 blocks to confirm. That latency surprises me even more given that they use mongoDB, whose writes are almost as fast as writes to /dev/null
13:31 < jtimon_> just a mix of jokes really
13:31 < petertodd> jtimon_: well, that was more funny than the comedian they hired for the san jose conference
13:31 < jtimon_> hehe
13:31 < jtimon_> I saw him a little bit, but yeah, not funny at all, I couldn't watch the whole video
13:31 < gmaxwell> jtimon_: I think it's because they have to send their transactions all the way to blockchain in the UK for processing.
13:32 < jtimon_> hehe
13:32 < petertodd> gmaxwell: these services need a little <hex> button that gives you the raw hex of your tx
13:35 < gmaxwell> petertodd: We got blockchain.info to add that. (well not a button but a ?format=hex on the transaction page)
13:35 < petertodd> gmaxwell: nice!
15:00 < orperelman> Jtimon & Peter, it's all about the PR and marketing, one of the reasons they are so successful, they are doing an amazing PR work - gotta give them that
15:01 < orperelman> It's amazing me to this day  - there is almost no normal wallet out there today that I can recommend to new bitcoin users heh
15:45 < adam3us> gmaxwell: proof of (holding) bitcoin - (for bandwidth allocation in bitmessage etc) but with 100btc i can take 100 shares of bandwidth at no cost (if i was holding them anyway).
15:46 < adam3us> gmaxwell: "as of right now in git bitcoin allows data in OP_RETURN though given what people are saying I hope we back that out." dont object to backing out (say NO to block-chain spam!), but what are they saying missing context?
16:17 < adam3us> gmaxwell: ps still musing about how to do a subliminal channel free sig (motivated by such things).  one thing wondering is the existing possibility to make a ECDSA key that can sig that is valid for two different msg hashes (by chosing public key at time one msg is known). thinking it might be enuf flexibility to do something
16:37 < gmaxwell> adam3us: there have been a number of articles about how bitcoin has been "upgraded" to enable "distributed storage" and such horrifying things like that.
16:40 < adam3us> gmaxwell: ah yes.  its a scary situation indeed.  the flip side is there are then people who will stego encode then in multisigs if you dont, and create needless non-compactable TXOs and on.  Cant win:(  well maybe... there's the subliminal channel plugging drive - could try how far you can get with that.  eg all outputs are blinded  somehow by the next mining event and unblinded by recipient or inputs blinded by spender and unblinded by mi
16:41 < gmaxwell> adam3us: thats why I didn't oppose it initially. Though the trade off of people thinking it is a good non-antisocial and supported application is concerning.
16:41 < gmaxwell> Esp what happens if abusive use arises and it must be turned back, but there is also non-abusive use?
16:41 < adam3us> gmaxwell: pegged side-chain, pegged side-chain, pegged side-chain
16:42 < gmaxwell> I mean there is a whole seperate stupid altcoin  "datacoin"
16:43 < adam3us> gmaxwell: seriously.  if that can be bootstrapped there is no rational excuse for not using one.  i mean maybe we'll need a pegged-side-chain-gen.io because of lameness but otherwise...
16:45 < adam3us> gmaxwell: yes it seems like the msg was interpreted badly as a big GREEN light, that people can do any random stuff like its an API, or I dunno "HTTP on top of TCP"
18:13 < gmaxwell> andytoshi: I wonder in a public CJ server if there would be a value in using a socialist millionaire protocol so that a prospective CJ player could query the available sessions to test for an output size match, without disclosing what size they're looking for (and without learning what any of the ongoing sizes is)
18:17 < andytoshi> gmaxwell: what would they learn in the case that a match exists?
18:18 < andytoshi> it seems like they could get a good idea of the sessions just by testing various output values to see if they can join
18:18 < gmaxwell> andytoshi: you can limit them by making them show you inputs they're interested in using as a rate limiter.
18:19 < andytoshi> ok, fair enough
18:20 < andytoshi> i'll put this on my list of "things to do when we have enough people for more than one session at once" :)
18:20 < gmaxwell> I mean ultimately what you can do is a multiparty computation where the server has a list of possible CJ's and the user has a set of inputs/outputs they're interested in and the MPC tells the user and the server which one they ought to be joining and no one learns anything beyond that... but thats getting into moon technology where socialist millionaire protocol is straightforward.
18:20 < andytoshi> well, if it's tractable moon technology then i'll look into using it one of these days ..
18:21 < andytoshi> i am being selfish and using other peoples' privacy desires for my own learning purposes
18:23 < andytoshi> if i can get my bitcoind back to life i'll have a coinjoin client written by sunday evening, then this week we'll see if i can spur some popularity
18:23 < gmaxwell> It's not intractable, but not a 1 hour hack either.
18:31 < gmaxwell> there may be a 'simple' way to implement it where the server and the client disclose a bunch of fake data about the candidate joins and inputs/outputs (including the real data), and then the server and the client compute which would go with which, and then you do a far simpler multiparty computation just to learn a single one of matchups which involve real transactions.
18:32 < gmaxwell> (lets you keep the coinjoin matching outside of the multiparty computation.. the multiparty computation would just be "take two bitstrings, return a random index which has a 1 in both bitstrings"
18:32 < gmaxwell> )
18:44 < maaku> gmaxwell: would there be a chance at analagous technology for the p2p case?
18:45 < maaku> for my architecture I'm still assuming a broadcast architecture for requesting potential joins
18:46 < maaku> which isn't as privacy enhancing as I would like...
18:48 < gmaxwell> maaku: nothing fundimentally prevents it, e.g. you could do multiparty computation with any number of parties. Though I think the complexity of hacks like I suggested to keep the mpc part maximally simple would not scale well.
19:21 < jgarzik> New torrent, http://gtf.org/garzik/bitcoin/bootstrap.dat.torrent
19:21 < gmaxwell> maaku: fwiw, you can do a very easy implementation of socalist millionaire using only blind signing.
19:23 < gmaxwell> maaku: you hava a database you'd like me to check for matches it. You sign each entry and give me the signatures. I learn nothing useful from this.  Then when I want to see if X is in the database, I blind X and ask you to sign it. You learn nothing about X. Then I unblind and can see if it was in your list.
19:34 < Emcy> jgarzik do you have the previous 2 or 3 bootstrap torrents you made anywhere?
19:34 < gmaxwell> maaku: though I think until someone works out what an 'optimal' CJ decision looks like, it's hard to reason about what it would take for some magical private process to generate them.
19:34 < Emcy> it occurs to me i can seed them all from the same file
19:39 < Emcy> well actually ive got 3, 4.5gb, 9gb and this new 13gb
19:39 < Emcy> i think thats all of them right
19:41 < maaku> gmaxwell: what do you mean by 'optimal coinjoin decision'?
19:56 < jgarzik> Emcy, sf.net/projects/bitcoin has current; above is current+1
19:58 < Emcy> huh?
19:58 < Emcy> thats the bitcoin client
19:58 < gmaxwell> maaku: I mean, say given a set of transactions, which partipants will not gain any privacy under an assumption that the attacker understands coinjoins and are unravling them based on the assumption that users_inputs==users_outputs?
22:18 < gmaxwell> oh. I think I just reduced the complexity of my trivial NIZK proof to O(N) without substantially increasing the complexity of it, though by adding a discrete log hardness assumption.
22:19 < gmaxwell> The point I'd made at the end is that you could remove the N^2 by using an xor-homorphic commitment as that would allow you to just combine the gate key commitments directly.
22:23 < gmaxwell> But really the xor-homorphic commitment only needs to be xor-homorphic for a single bit, which means straight up additive homorphism over any field should work. E.g. the commitment can be X*g in some EC group.
23:38 < gmaxwell> Oh, interesting. I can get a simpler CoinSwap protocol if prior to any transactions, one party proves to the other H(X),H(Y),X xor Y for some undisclosed X,Y  in other words, having this proof in hand you know that if you know the preimage of H(X) the you also know the preimage of H(Y).
23:39 < gmaxwell> I think I can do a proof for H(X),H(Y),X^Y with sha256 under 40 megabytes now.
23:40 < gmaxwell> (the coinswap is simpler from a protocol perspective because you just prove this relation externally to me, then we can just make parallel hashlocked payments knowing that one will reveal the other without a public linkage.
--- Log closed Sat Jan 11 00:00:25 2014