--- Log opened Tue Jul 02 00:00:04 2013
12:29 < jgarzik> petertodd, RE announce/commit, sorry missed that
12:31 < petertodd> Basically because we allow "pubkeys" to be up to 120bytes in size in the standard transaction code fitting a whole tx in a tx is actually pretty easy.
12:32 < jgarzik> petertodd, FWIW I'm currently thinking about how an alt-blockchain for this identity data could be timestamped into the blockchain in a normal transaction
12:32 < petertodd> Did you see my write-up in -dev for a 1s resolution timestamp chain? Not dissimilar...
12:33 < jgarzik> petertodd, what, do a 1-of-20 (picking absurd example) multisig, and stuff the whole tx in there?
12:34 < jgarzik> petertodd, I was pondering a rule that permits an OP_TRUE w/ a standard transaction inside, to be made standard
12:34 < jgarzik> petertodd, validate the inner tx according to IsStandard and spendable rules
12:34 < petertodd> Nope, a 1-of-3 just fits: 2d201879608ed2d14c362dff713a6d17d680cb42d5175dfe42e960e94736be04
12:35 < jgarzik> I dislike multisig hackery ;p
12:35 < petertodd> I was thinking of that too - weirdly like P2SH...
12:35 < jgarzik> petertodd, precisely!
12:35 < jgarzik> better than stuffing unvalidated data in odd places, IMO
12:36 < petertodd> I can see the anti-spam argument, although myself I'd lean more towards just allowing OP_RETURN <data> to have a decently sized payload.
12:37 < jgarzik> <= 80 bytes OR standard, spendable TX
12:38 < petertodd> As always unless we go to the extreme of gmaxwell's P2SH^2 people will always stuff data in the system.
12:38 < jgarzik> indeed
12:39 < jgarzik> IMO you strike a zen balance.  Make it easy but not too easy
12:39 < Luke-Jr> petertodd: extreme? seems perfectly reasonable to me
12:39 < petertodd> The tx validation machinery could easily have it's own bugs...
12:39 < petertodd> Luke-Jr: Like it or not sometimes there are *very* good reasons to be able to prove that the whole of Bitcoin was able to see your data.
12:40 < Luke-Jr> petertodd: not good reasons to force the whole of Bitcoin to see/store data they never consented to see/store
12:41 < petertodd> Meh, Bitcoin can be a better financial system with some of these uses.
12:42 < jgarzik> Luke-Jr, disagree.  Plenty of uses for timestamping.  That alone could revolutionize accounting and finance, in a way that bitcoin-the-currency doesn't IMO
12:42 < jgarzik> gotta strike a balance.  the majority of users just want to transfer or hold bitcoins-the-currency.
12:42 < Luke-Jr> jgarzik: timestamping does not require cluttering the bitcoin blockchain
12:43 < Luke-Jr> just shove a hash in the merged-mining merkletree and that's it
12:43 < jgarzik> require? no.  no other chain has the same strength, so rational economic actors will look at the strongest chain.
12:43 < jgarzik> yes, if there was an alt-chain for data, that all pool ops carried, things would be different
12:43 < petertodd> Luke-Jr: There are applications beyond timestamping you know - announce/commit sacrifices are a perfect example where genuine provably visibility is absolutely vital.
12:44 < Luke-Jr> petertodd: those are just timestamping too afaik
12:44 < petertodd> Luke-Jr: No they aren't: timestamping the announce is useless, you *must* prove that the whole of Bitcoin had the opportunity in advance to mine it.
12:45 < Luke-Jr> hmm
12:45 < Luke-Jr> how would a pre-announce merged-mined block not work for that?
12:47 < petertodd> Luke-Jr: Because if the alt-chain is merge mined by, say, 25% of mining pools your sacrifices are already so dubious as to be nearly worthless.
12:47 < petertodd> Luke-Jr: You need strong convincing evidence that the transaction really was visible to all.
12:47 < Luke-Jr> petertodd: not really. even 25% gives you 1 in 4 blocks
12:48 < Luke-Jr> you just need to wait 1-4 blocks additonal
12:48 < Luke-Jr> hmm
12:49 < Luke-Jr> yeah, I think it should be fine
12:49 < Luke-Jr> I do see another problem that affects it regardless of where the pre-announce is done..
12:49 < petertodd> Luke-Jr: It has nothing to do with waiting; the issue is that with 25% a 12.5% pool has sufficient hashing power to 51% attack the proof-of-visibility chain and create sacrifices that were never publicly announced and thus aren't true sacrifices at all.
12:50 < Luke-Jr> petertodd: tie the POV chain to the BC chain
12:50 < Luke-Jr> POV blocks are only valid if they're in the BC chain
12:50 < Luke-Jr> in fact, POV doesn't need a chain of its own at all
12:50 < petertodd> Luke-Jr: Again, that's irrelevant. You need to show that the chain was public knowledge.
12:51 < Luke-Jr> ok, so then make POV a chain again, and each POV block confirms the previous was visible
12:51 < petertodd> Only with a very high participation rate among Bitcoin miners is the proof any good, and frankly at that point you're in the same situation you were before with bloating up a blockchain...
12:52 < Luke-Jr> not the same situation, no
12:52 < Luke-Jr> *users* don't need it
12:52 < petertodd> That's the thing, all it confirms is that x amount of hashing power saw a given transaction, if that x is even just 25% of the main Bitcoin blockchain the proof is already pretty dubious.
12:53 < petertodd> Announce/commit sacrifices already have the issue where you really need to discount them by 50% from the get-go to be sure, and at least 10% or so even if you aren't being cautious.
12:54 < Luke-Jr> why can't you just have a rule that the redemption of a send-to-any must occur in a separate block from the send-to-any itself, to be valid?
12:54 < petertodd> Well, indeed, any type of sacrifice to mining fees, with the possible exception of ones that are only spendable way in the future - months - which can't be done with the current scripting system.
12:55 < petertodd> Luke-Jr: That's what I proposed on the mailing list, and that's a soft fork. The other way is to do the sacrifice as a anyone-can-spend in the coinbase tx.
12:56 < Luke-Jr> petertodd: it's not a soft fork, it just has a risk some miner is a jerk and screws you :p
12:56 < petertodd> Luke-Jr: um... yeah... That's about a 100% risk if fidelity bonds are used even just a bit.
12:56 < petertodd> Luke-Jr: Who doesn't want free BTC?
12:57 < Luke-Jr> too bad there's no nLockTime for scriptPubKeys :P
12:58 < petertodd> Yup...
12:59 < petertodd> Anyway, point is, that's just one example where visibility proofs are essential, and there are a whole lot more out there... dismissing any and all data from the blockchain goes too far.
13:10 < Luke-Jr> I still see no need for it to be part of the BC blockchain
13:11 < Luke-Jr> a merged mine chain can be just as effective while not forcing itself on people who have not agreed to it
13:20 < petertodd> Like jgarzik said with this stuff you want to go for the strongest blockchain, and that'll be Bitcoin. Even merge mining doesn't help there because you are never going to get 100% participation, and if you do, it's damn near equivalent to putting it in the blockchain anyway.
13:22 < Luke-Jr> only equivalent for miners, not for everyone else
13:23 < Luke-Jr> and forcing people to do things against their consent is not justified to get 100%
13:23 < petertodd> Pff, don't give me that consent crap. If you want to enforce that, enforce it with code.
13:23 < Luke-Jr> exactly my point
13:24 < Luke-Jr> POV code should be written so that people can't force others to participate against their consent.
13:24 < petertodd> People run code that accepts arbitrary data right now; to say they aren't consenting to what the code they are running allows is silly.
13:24 < Luke-Jr> ie, if you don't use the merged chain, I won't recognize your proof
13:24 < petertodd> No, Bitcoin-Qt should be written to match what the users wish to consent too.
13:24 < Luke-Jr> petertodd: no, it isn't silly
13:25 < Luke-Jr> yes, gmaxwell proposed a solution to fix this problem on the Bitcoin side
13:25 < petertodd> If we wanted to govern ourselves by social rules we would be using something other than Bitcoin...
13:25 < Luke-Jr> Bitcoin != anarchist
13:25 < petertodd> yup, and gmaxwell's solution works well and if the userbase wishes to they can use it - if you are so concerned about this go and implement that solution!
13:26 < gmaxwell> feh. never that simple.
13:26 < petertodd> But don't give me crap about consent when people are willingly running code that works otherwise.
13:26 < gmaxwell> In a frictionless enviroment what you say is true, but we're not in a frictionless enviroment.
13:28 < gmaxwell> It's not like accepting my hash preimage stuff— even if it were all implemented and tested— is costless. A lot of people would resit it because they're simply unsure or don't understand the implications, even people who are very concerned about people stuffing troublesome data on their disks.
13:28 < gmaxwell> Go look at all the sites that will not pay to 3xxx adddresses. :(
13:28 < petertodd> That is true, but going and pouting that people are putting data in the blockchain obviously doesn't stop people from doing so - technical measures stop people.
13:29 < gmaxwell> I don't agree completely. Society is part of how this works too. Pouting influences behavior, including technical ones.  It may, in fact, be a necessary precondition to deploying the technical solution.
13:30 < gmaxwell> We have lots of tools in our toolbelt, and we'd be fools to not use all of them because we've fixated on a particular kind of tool being right for a particular kind of problem.
13:30 < gmaxwell> Though, let me go back here a bit—
13:31 < gmaxwell> If you're talking about data which is on the order of— say— 32 bytes/txn ... well, you cannot securely bind a transaction to external data any smaller than that.
13:32 < petertodd> Don't get me wrong, I'm not going to say social measures are useless, my point is that they have proven to be not very useful again and again to anyone who has a reason to go against the social measures.
13:32 < petertodd> They're fine for discouraging people working on hobby projects, but that's about it.
13:32 < gmaxwell> Once you start getting bigger you have to worry that (1) deployment of the preimage stuff will actually break your system, (2) desire to preserve your system (I haven't followed the discussion, I assume you were talking about buting sacrifices in pubkeys?) might be used to argue against preimages, which kinda sucks.
13:33 < petertodd> gmaxwell: Well I was mainly using it as an example where you need a genuine proof-of-visibility and anything less just doesn't work.
13:33 < gmaxwell> amusingly I think that social measures are more effective against businesses han hobby projects— the latter is in a better position to say "fuck you, I don't care what _anyone_ thinks"
13:34 < petertodd> gmaxwell: In response to Luke's assertian that merge mine chains and merkle-trees for timestamping is always good enough.
13:34 < petertodd> The problem is in Bitcoin businesses are often totally anonymous, and the issues where the social measures matter are complex technical things.
13:35 < gmaxwell> petertodd: ultimately any idea that depends on getting unjammablity from bitcoin is really fragile, I think. Simply because capacity will kill you if nothing else does.
13:35 < gmaxwell> meh. doesn't really matter if they're anonymous or not, I can deny a business income by social ostracism of their _customers_.
13:35 < petertodd> On the other hand if you can architect in a way where limited capacity is ok, it's the best solution out there.
13:36 < petertodd> But the point is, those anonymous businesses are associated with industries where the customers don't seem to care as much, and in addition the anonymity means their backend stuff is often very obscured. (I'm sure someone is timestamping log files for something, but good luck ever figuring out who they are)
13:38 < gmaxwell> uh, what the heck were you proposing where such a business needs generic worldwide visiblity unjammablity?
13:38 < petertodd> Announce/commit sacrifices are the cannonical example.
13:39 < petertodd> Fraud proofs are another, that's a case where the existance of a "fall-back" way of ensuring global visibility is really valuable even if you have lesser means like merge-mined chains.
13:39 < gmaxwell> But they dont— they need visiblity to the interested parties.
13:40 < gmaxwell> I'm struggling to come up with something which needs visiblity to _disinterested_ parties.
13:40 < gmaxwell> (esp since you can't, you know, make people who don't care pay attention)
13:40 < petertodd> The problem is the only way to prove visibity is by proof-of-work or proof-of-stake, and the former gets really scary fast due to the large pools out there.
13:41 < gmaxwell> but that isn't solved by making things clear-visible in the blockchain.
13:41 < petertodd> The latter is ugly because it's active, and can tightly couple finance into a system where the attack is losing money if the data is made public.
13:42 < gmaxwell> e.g. so you put data in the clear in the blockchain, but thats no proof that anyone who mattered actually noticed it there even if they had the data available to them.
13:42 < petertodd> Sure it is: if it's in the Bitcoin blockchain I can be damn sure that anyone who was interested could have seen it. If it's a merge-mined chain with low hash rate it would be very easy for that data to be hidden by an attacker.
13:43 < gmaxwell> In fact, you've already proved it— you've made all kinds of weird transactions which people could have redeemed and either didn't or took a long time to do so. (or required you pointing them out at least)
13:43 < petertodd> Right, but in any system actually using this stuff the interested parties will look if it matters, and if no-one is interested, so what?
13:44 < gmaxwell> at least the merged mined thing actually creates evidence of seeing it by someone who (programmatically) cares.
13:45 < gmaxwell> We could also introduce a general mechenism for this kind of thing which doesn't create any perpetual storage, I suppose.
13:45 < petertodd> Take the example of a fidelity bonded bank where you want to sell your bank, but also want to be sure that no-one has committed fraud but withheld the fraud proof: you wan to be able to say "if it's not in some blockchain, the fraud never happened"
13:46 < gmaxwell> and, yet, you can still do that just in terms of sum difficulty of a merged mined chain.
13:46 < petertodd> Sure, and you can do that if, for instance, we have UTXO posession proofs as part of the proof-of-work function, and they you would show via UTXO proofs that the data existed in the UTXO set and people posessed it, but they can drop it after the fact. (need a hard fork due to some details obviously)
13:47 < petertodd> gmaxwell: Of course, my point is any merge mined chain will always be inferior to Bitcoin because it will always have a lower hash rate, *or* the system has effectively become part of Bitcoin anyway.
13:47 < gmaxwell> (or sum-stake, or signed by some trusted observer or all of the above)
13:48 < petertodd> Basically have some data in a transaction that you don't need to proove the transaction is valid, but you do need to temporarily posess to fufill your proof-of-posession PoW.
13:48 < gmaxwell> petertodd: okay, let me grant that: but being part of bitcoin itself isn't the same thing as sticking all data at the root level.
13:49 < gmaxwell> As it is today there is no way to do finite lifetime data in bitcoin, and everything you're talking about needs _at most_ finite lifetime.
13:50 < petertodd> Of course, but that's where my temporary forced storage scheme is useful, but that's a soft-fork at minimum and more likely people with the need will just keep stuffing their data into the blockchain.
13:51 < gmaxwell> okay, welll certantly, you can say that a mechenism for temporary storage is virtuious even if we still hold the view that forced non-currency-data storage is wrong and should be technically defeated where possible.
13:53 < petertodd> Exactly. Point is figure out those technical solutions and make them work - don't go whining about social responsibility and "consent" as Luke does because the whole point of Bitcoin is to replace social mechanisms with technical ones, so work within that paradigm.
13:54 < petertodd> Not to mention how bizzare it is to be complaining about people creating prunable data, yet we won't say a thing about low-values transactions. The technical impact of both types of data is exactly the same - the archival blockchain gets bigger. (UTXO bloat is of course another matter, but that's solidly a design flaw)
13:55 < gmaxwell> hah. It's not like the technical stuff appears whole cloth in a vacuum. First it must justify our social responsibility. Absent consent the security of the technology is paper thin.
13:56 < gmaxwell> "won't say a thing" uh, we just nuked very tiny output creation.
13:56 < gmaxwell> And— low value txn is pretty tricky: we don't know where the dividing line is.
13:57 < petertodd> Yes, and I did say that UTXO bloat is a design flaw; nuking tiny output creation is an example of a patch to try to fix that design flaw.
13:57 < gmaxwell> Vs it's easy to say Bitcoin is not a @#$@# storage locker for your nuddies or whatever. :P
13:57 < gmaxwell> harder to actually stop it, but at least agreeing on the goal is easier.
13:57 < petertodd> ...but then is it ok to use bitcoin as a proof-of-visibility for your financial application?
13:58 < gmaxwell> Not really, for one— it just won't work. Limited channel capacity will make that unpredictably fail for you.
13:59 < petertodd> Limited channel capacity makes the entire *system* fail unpredictably by that logic.
13:59 < petertodd> There are *lots* of applications where the fact that the channel capacity is limited is not only acceptable, but actually kind of a good thing.
13:59 < gmaxwell> It makes the future system's scale uncertian. But bitcoin doesn't just fail because it becomes slow to make transactions, your financial application certantly might.
14:00 < gmaxwell> kind of a good thing— sure, and bitcoin itself is one of them. But the challege there is limited channel where the capacity gets eaten up by _something else_ is not so obviously a good thing.
14:01 < petertodd> Any financial application will need to make transactions; you can easily design your need for data bandwidth to correspond to your need for transaction bandwidth.
14:02 < petertodd> Part of that design is of course determining how resistant you want to be to efforts to stamp out data in the blockchain, but you can always get some amount of data in there so the option always exists.
14:03 < gmaxwell> Okay, well we go back to my comment earlier that some small sidechannel— like 32 bytes per transaction— is probably something we can tolerate because there are just too many useful things that cannot be done without it. So figure out how to fit into that model and _MAYBE_ you have something that is still viable, maybe. Not certantly: since if the whole world was using bitcoin it isn't clear that any particular user would be able to get
14:04 < gmaxwell> But anything more than that, and it's not clear that it wouldn't trivially be stampped out by the first persistant effort to really cram in some nasty stuff in the broadcast channel.
14:04 < petertodd> But that's the thing: a sidechannel of any size just puts a price on the data relative to a transaction. We can push that price one way or another, but we know we want make that price infinity - there are just too many ways to stuff data in transactions.
14:04 < gmaxwell> I mean. jesus, don't design business plans that can be shut down by a bored 12 year old.
14:05 < gmaxwell> petertodd: we can make anything that has uxto storage be a hash preimage.
14:05 < jgarzik> hehe that says it all ;p
14:05 < petertodd> I'm not talking about UTXO storage, I'm talking about in-blockchain data.
14:06 < petertodd> UTXO storage is something we can go very far in preventing, up to having to perform partial hash collisions, but in-blockchain data isn't something we can stop - you can always play games with pubkeys.
14:08 < gmaxwell> petertodd: oh, well I'm actually far less concerned with that, as you can simply puncture the validation rules. There is a balance that provides adequate pratical security.
14:08 < petertodd> puncture the validation rules?
14:08 < gmaxwell> There are plenty of people who think it would be perfectly sane to just forget all the spent txo before height 210000 or whatever.
14:08 < petertodd> Ah, yeah, which for the proof-of-visibility application is completely fine.
14:09 < gmaxwell> Not just in a pruning sense, but completely.
14:09 < jgarzik> I still like the idea of modifying my OP_RETURN patch to permit standard, spendable transactions || size <= 80
14:09 < gmaxwell> Depends on what you're trying to prove visible to who.
14:09 < jgarzik> gmaxwell, in this case, https://en.bitcoin.it/wiki/Identity_protocol_v1
14:09 < petertodd> Sure, but you can always prove your data was as visible as any other blockchain data in the time period, and that's all you need frankly.
14:09 < jgarzik> (that was the genesis of this whole proof-of-visibility discussion)
14:10 < jgarzik> indeed
14:11 < petertodd> jgarzik: ...and I strongly think OP_RETURN should be slightly cheaper at stuffing data in the blockchain than the P2SH+multisig games that we can-not stop, as a harm reduction measure
14:11 < petertodd> jgarzik: Well, half the cost is probably a decent number to make it clear that doing the right thing is the way to go.
14:11 < gmaxwell> jgarzik: I do think we should have some way of binding a hash to a transaction under signature, setup so the data is prunable and so the space usage is strictly limited.  Esp if such a tool makes it easier for people to use _hashes_ instead of raw data that just has a lot of additional problems for us.
14:12 < jgarzik> currently patch definitely provides that
14:12 < jgarzik> timestamping an entire transaction is another use case, which obviously requires more data transited
14:13 < jgarzik> cannot have proof of visibility otherwise
14:14 < gmaxwell> proof of txn visibility is an interesting special case, because the list of interested parties is 1:1 with miners, I think it would really unfortunate to enable random data storage just to enable txn timestamping.
14:14 < petertodd> We already have random data storage and can't do *anything* about it.
14:15 < gmaxwell> petertodd: That isn't the case for the utxo set.
14:15 < gmaxwell> oh but this is op_return.
14:15 < gmaxwell> Hm.
14:15 < petertodd> Lets suppose P2SH^2 was implemented and we even forced P2SH^2 spends to have signatures for every pubkey, you could *still* make special pubkeys by modular addition from a known point and just subtract that known point to recover the data.
14:15 < jgarzik> gmaxwell, "interested parties ?1:1" not really.  Or at least not right now.  The link just given is anyone-can-spend.
14:16 < petertodd> gmaxwell: Sheesh, took you awhile to notice that...
14:16 < gmaxwell> part of the problem is— however— I can't prove an output was @#$@# OP_RETURN to you without actually giving you it. :(
14:16 < petertodd> But you can't prove an output was spent correctly without giving you it either.
14:16 < gmaxwell> jgarzik: well, at least interested in _theory_; not my fault that miners aren't economically rational in any simple sense. :P
14:17 < jgarzik> heh.  Well maintenance costs of carrying a patched bitcoind forever also factor into rational economic decisions
14:17 < petertodd> OP_RETURN isn't special in that regard, and future UTXO proof stuff will allow for pretty good certainty that a given txout was prunable because it never made it to the UTXO set.
14:17 < gmaxwell> thius 'simple sense' :P
14:18 < jgarzik> ;p
14:18 < jgarzik> petertodd, sipa's pullreq already does similar
14:18 < gmaxwell> petertodd: ideally it should be possible to sync a chain minus instaprunable data.
14:19 < petertodd> Remember that provided the inner tx of an announce-commit is standard interested *users* can always ensure sacrifices are actual sacrifices to keep whatever service they are using maximally honest.
14:19 < petertodd> gmaxwell: Yup, but that's going to require a soft-fork.
14:19 < petertodd> jgarzik: His prune OP_RETURN one? Yeah, it's not exactly rocket science...
14:20 < jgarzik> petertodd, nod.  proving an inner tx is already a known quantity
14:21 < gmaxwell> So?  For example, I'd rather require the OP_RETURN to only have 32 bytes, and then have a soft forking rule that there is additional out of transaction data required for you to accept the transaction near the tip. The fact that the soft fork would take a while to deploy is moot.. it will take years to deploy the sacrifices, so the fact that their security is weak initially is no big deal.
14:21 < jgarzik> obviously you can only prove unspent at that point in time, but it's still a lot of validation
14:21 < petertodd> gmaxwell: Look, like it or not, all you can do is make data in the blockchain more or less expensive relative to standard transactions. That's *it*
14:22 < gmaxwell> lol. Are you pounding a table? Careful. You might break it!
14:22 < petertodd> gmaxwell: If you want to do something, submit a pull-req to make CHECKMULTISIG's not in a P2SH !IsStandard() for instance - it'll up the cost.
14:22 < jgarzik> gmaxwell, I'm working on the identity stuff now, and certainly won't wait years :)
14:23 < gmaxwell> petertodd: but it simply isn't so, I can many any of it get hidden behind hash preimages... from where it becomes much easier to cut-along-the-dotted-line
14:23 < petertodd> All limiting OP_RETURN does is sends a *social* message.
14:23 < jgarzik> gmaxwell, the alternative is simply yucky but still doable (1-of-X pubkeys is actually valid)
14:23 < gmaxwell> jgarzik: you don't have to wait years for it to be used.
14:23 < adam3us> could there be another store and forward channel for tx data that doesnt need to be in the block chain, so the data doesnt need to be in the block chain can still be sent if the users are not both online at the same time can do so without resorting to email; and then try to minimize the bytes on the block chain via commitments etc
14:23 < gmaxwell> petertodd: no, ithat really isn't true.
14:23 < petertodd> gmaxwell: "I can many any" <- ?
14:24 < petertodd> adam3us: We're talking about proof-of-visibility here.
14:25 < adam3us> yeah i know, was lurking, but also about bloating the blockchain
14:25 < adam3us> theres a diff between everyone must see (validation) and must be available/pruneable or not
14:26 < petertodd> gmaxwell: Right now I can put 360 bytes of data in a given OP_CHECKMULTISIG txout. Making OP_RETURN limited to 32 bytes when CHECKMULTISIG abuse exists is sending a social message. So if you want to do that, ban OP_CHECKMULTISIG's not in P2SH at the sametime.
14:27 < gmaxwell> jgarzik: basically an identity transaction whos visiblity proof depends on a soft forking change to not mine it unless you've seen the hash elided data is usable to you today. But less secure until the soft forking change happens.
14:28 < gmaxwell> petertodd: There is no reason that you have to do (B) before (A) when your concern is just that it remains possible to do (B) in the future.
14:28 < petertodd> gmaxwell: Yes, but until you do (B) all you are doing is sending a social message because anyone who actually has a use-case for the 360 bytes will just do (A)
14:28 < gmaxwell> And I do think it's important to not enable more random data storage in a manner which is incompatible with hiding it behind a hash.
14:29 < petertodd> gmaxwell: Be clear: are you talking about UTXO data or blockchain data?
14:29 < jgarzik> gmaxwell, in general I agree, hence the proposal of "80 bytes || standard tx"
14:29 < jgarzik> gmaxwell, because the latter is a special case (PoV)
14:30 < jgarzik> the vast amount of timestamping works just fine with a hash
14:30 < petertodd> jgarzik: and the "standard tx" option for data is just the Bitcoin developers saying "we think *that* use of data is cool, so we'll make it cheaper"
14:30 < jgarzik> petertodd, yes
14:30 < jgarzik> petertodd, which is what all the IsStandard rules are :)
14:31 < gmaxwell> jgarzik: Why quite so much as 80 bytes?   What I'm pointing out is that even the special visiblity stuff can work with a hash too: so long as we add a soft-forking rule that says you don't accept a block unless it comes with the preimage of the hash, when the block is near the tip of the chain. After that the data can be forgotten.
14:31 < petertodd> jgarzik: Emphasis on cheaper. It is *not* us saying blockchain data is banned, because we have no way to make that happen.
14:31 < gmaxwell> (if its not clear my last line was two totally distinct things)
14:32 < petertodd> gmaxwell: Forgotten in what context? UTXO or long-term blockchain data?
14:32 < midnightmagic> ;seen gavinandresen
14:32 < midnightmagic> ;;seen gavinandresen
14:32 < gmaxwell> Kinda crappy that we just needed to cut down on the additional message data, as that would have been a ducky channel to relay the preimages. :P
14:32 < gmaxwell> petertodd: forgotten in long term blockchain data.
14:33 < petertodd> gmaxwell: That's only possible by adding a proof-of-posession PoW mechanism and having a separate set of data storage.
14:33 < gmaxwell> Derp what?
14:34 < gmaxwell> You have a transaction with a hash in it. For the txn to be valid you must have the preimage of that hash. But this rule only applies when the block is sufficiently new.
14:34 < gmaxwell> You now have proven visiblity once the rule is widely deployed.
14:34 < jgarzik> gmaxwell, Definitely lost me there.  I'll have to ponder/parse :)  I don't see how it solves the proof of visibility, but maybe "hash" is vague
14:34 < gmaxwell> Without adding more than 32 bytes of hash to the long term visible block chain.
14:34 < jgarzik> hrm
14:35 < jgarzik> gmaxwell, in particular for identity, the full tx must be available for anyone to spend
14:35 < petertodd> Right, you've proven visibility in the sense that 1/2 * hashes/second * 10 minutes of hashing power saw it - that's not very good.
14:35 < gmaxwell> jgarzik: Think of it as making the visible data attached to the transaction with a perforation: Rip along the dotted line.  But you're not allowed to rip it until the block is sufficiently old. You can define how sufficiently (maybe even encode that in the txn).
14:35 < petertodd> All I have to do to make invalid sacrifices is temporarily hack into a few big pools for an hour.
14:36 < petertodd> s/sacrifices/proof-of-visibility/
14:36 < gmaxwell> petertodd: No, thats not the case.
14:36 < petertodd> gmaxwell: Why not?
14:37 < gmaxwell> petertodd: You can choose the security parameter to where that isn't an issue. If the rippable sections must be provided for 144 blocks— lets say—  are you speculating that someone will perform a 144 block reorg in order to make bogus sacrifices?  Might as well give up.   You've already accepted some maximum depth by virtue of the nlocktime offset.
14:38 < gmaxwell> I don't know what parameter makes sense. I'd have to think more. But the important thing is that you can make the data possible to rip out, so that _no one_ has to remember it once an adequate announcement window has passed.
14:40 < gmaxwell> And this is important— if we can't prevent the data from containing nasty stuff, okay well by the time anyone complaints the data can be deleted from all computers _forever_. Thats protective of the system.
14:40 < petertodd> The problem is that there is absolutely nothing stopping a miner from changing their software to ignore that rule, for instance because some large pools got hacked and the attacker deleted the data and no-one feels like screwing up everything for that minor feature.
14:40 < petertodd> Whereas actual proof-of-posession proves that the miner really did have that data.
14:40 < petertodd> And proof-of-posession still lets you define a deletion period.
14:41 < gmaxwell> huh? It's the same as any other network rule (once deployed). Nodes will reject blocks that they didn't get the attached data for, until the block is well and burried.
14:42 < gmaxwell> petertodd: if you stuff the data into the output then the data can never be deleted. :(
14:42 < petertodd> No, unlike other network rules you *can't* verify that it was actually followed after the fact because the data doesn't exist anymore.
14:43 < gmaxwell> petertodd: you can verify it was followed _during the window_. So unless you hypotheize a >window reorg, you can't.
14:43 < petertodd> gmaxwell: I'm not saying stuff data into an output, I'm saying put a hash of the data in your specially marked output, provide it with relaying, *and* incorporate a proof-of-posession into the proof-of-work scheme.
14:43 < gmaxwell> okay okay whatever.
14:43 < gmaxwell> Look, good luck changing the proof of work. :P
14:43 < petertodd> gmaxwell: No you can't. Miners can agree to not follow it and you have no way of knowing. Where as with any other network rule the data is still there and you can verify it yourself.
14:44 < gmaxwell> petertodd: you won't accept their blocks for some huge gap— indeed, this data has only SPV security past that gap. Thats the point.
14:44 < petertodd> gmaxwell: But you *are* talking about a soft-fork, and it's not a hard proof of work, just a "well my PoW spat out this nonce, and I'll quickly provide a merkle path picked randomly to prove I had the data"
14:45 < petertodd> gmaxwell: Yeah, that's kinda my point... you've created a system that can't have better than SPV security, while with the slight change of just adding a proof-of-posession it has full security.
14:45 < gmaxwell> These things aren't mutually exclusive either, if your want your proof of possession just strenghtens what I'm suggesting, but I don't think its needed.
14:45 < petertodd> Yes, it strengthns it from very weak SPV to something much stronger; why not take that trivial extra step if you are going to all that trouble?
14:45 < gmaxwell> adding proof of possession gums up deleted forever, — a big liability.
14:46 < petertodd> No it doesn't, those are just merkle paths and anyone interested can retain sufficient data so that they can verify the merkle paths.
14:46 < gmaxwell> because you need for forever store the possession proof— which is smaller than the data (E.g. if its a cut and choose that only shows one item)
14:47 < gmaxwell> petertodd: no because then people didn't possess the data, they might have possessed H(data)
14:47 < petertodd> But that's it: you *don't* need to even store the item, or even the merkle path at all unless you want to prove your data was visible!
14:47 < gmaxwell> otherwise you could call the txn itself with the hash a proof of possession: you can't prove that they had more than the hash. :P
14:47 < petertodd> No, the algorithm is calculate H(nonce | data), and everyone other than those interested in the data stores nothing more than the tip of the merkle path.
14:48 < gmaxwell> for your PoP the proof that gets committed will have to include at least one of the data elements under proof or its not actually a PoP.
14:48 < gmaxwell> otherwise it's just SPV security. :P
14:48 < petertodd> But the thing is the only people who care that the data was actually visible, and need to prove that, are the people with the data! Everyone else *can* throw away the PoP's.
14:49 < gmaxwell> Okay, H(nonce|data) is interesting.
14:49 < petertodd> Remember, we're calculating H(nonce | data) for each bit of data (or a subset), making a merkle tree of that, and putting the digest in our block somewhere. We temporarily relay the PoP's, and then throw them out after n blocks.
14:49 < petertodd> People who need to prove visibility save those PoP's when they are being created, everyone else throws them away.
14:50 < gmaxwell> But I don't follow "Everyone else can throw away"— if you make it part of block validation then everyone who wants to validate a block needs the data, otherwise they might accept an invalid one.
14:50 < petertodd> Right, but they only need to store it temporarily.
14:50 < petertodd> For the average miner of course they're just getting SPV security for the PoP validation... but they don't care!
14:51 < petertodd> (I mean, they're getting SPV security that PoP validation was done correctly *in the past* if they are synching up fresh and weren't mining in the past)
14:51 < gmaxwell> petertodd: so, lets say 99% of miners just have SPV security for the pop validation. And oops. some minority cheats them. What happens?
14:52 < gmaxwell> I'm still trying to grasp what PoP really provides over my ripabble data with SPV security.  Both cases reduce to SPV security at some point or you're stuck keeping around data, right?
14:52 < petertodd> Nothing without fraud proofs, and because PoP's are relayed in full temporarily, you can be sure that the last, say, 144 blocks were done honestly.
14:53 < petertodd> The thing is my case reduces to SPV security for the people who don't care if the data was visibile, your case reduces to SPV security for the people who need the security!
14:53 < gmaxwell> but you could also be sure that last 144 blocks were honest just by not accepting them without getting a copy of the rippable data.
14:53 < petertodd> Yes, but you have no way of proving that in the future.
14:54 < gmaxwell> Got it.
14:54 < gmaxwell> Cool.
14:54 < petertodd> Heh
14:55 < petertodd> ....we gotta start writing papers for this shit...
14:56 < gmaxwell> Fuck that, make it real. :P
14:56 < gmaxwell> In any case, now I'm trying to figure how how simply it could be implemented.
14:56 < petertodd> Yeah... actually I had a nice idea for a timestamping alt-chain that I should implement.
14:57 < petertodd> Though rippable data might be easier to implement...
14:57 < petertodd> I wish the scripting system was more sophisticated; you could write scripts that evaluate the proofs and pay miners for having made them directly.
14:57 < gmaxwell> I think that prior to today it hadn't been clear to me that a strong short term visibility proof was completely compatible with not-perpetual-storage.
14:58 < gmaxwell> But now we have a problem that some crap scheme that results in perpetual storage is realistically what is going to get deployed.
14:59 < petertodd> I've also been fleshing out a alt-coin with decentralized mining that depends a lot on proof-of-visibility so it's been on my mind.
14:59 < gmaxwell> because it's 100x easier than anything we discussed.
14:59 < petertodd> Yup, you can't win there.
15:00 < gmaxwell> so the question I have: is there a limited form of the trivial dumb way that won't preclude implementing something smarter later?
15:02 < petertodd> I'd say OP_RETURN is exactly that - you can always just use the UTXO proofs + sha256 midstates as your way of tossing the data when safe with a limited impact on long-term validation.
15:02 < gmaxwell> IIRC the order of the transaction isn't so helpful for midstate compression.
15:03 < petertodd> Yeah, because the txin's come first.
15:04 < petertodd> But other than one outpoint you can verify everything, and UTXO proofs themselves will eventually offer an alterative to the standard transaction merkle tree anyway.
15:05 < petertodd> Once it's a hard rule I'd say that's just as good proof as anything else.
15:06 < gmaxwell> this sounds like a reason to restrict the OP_RETURN to be the last txout though.
15:06 < petertodd> No, restrict it to the first txout.
15:07 < petertodd> Although a sane UTXO proof system will make a merkle tree within the transaction itself, IE hashing txins and txouts.
15:07 < gmaxwell> right yea, I'd proposed making the transactions a merkel tree like a year ago to make it easier to subset the 2#$#@ data.
15:08 < petertodd> PoW is always energy anyway, so you just need to store the parts of blocks you need to prove + UTXO proof stuff + block header and verify that. After a year or two that's a year's worth of PoW - pretty damn good confidence.
15:08 < gmaxwell> petertodd: hm. putting it first doesn't help because you can't even check the signatures anymore. :(
15:08 < petertodd> From an energy point of view the last 3 months of PoW mean as much as the other 4 years.
15:09 < gmaxwell> petertodd: sure though at some point we'll reach an equlibrium
15:10 < petertodd> Right, but you can even stuff your data in the scriptSig if you hash it so that it's authenticated. Though the signatures of the first txout are still meaningless.
15:10 < petertodd> An equilibrium sure, but the point is you can have very good security by just waiting for the PoW to build up.
15:46 < adam3us> maybe i missed the very beginning of this topic but whats the motivation for proof of possession?
15:47 < adam3us> (I am inferring a proof of possession of a preimage of the hash stuffed int the block chain - but why, what do you use it for, what could you build on it?)
15:51 < Luke-Jr> adam3us: you prove it's a hash
15:51 < Luke-Jr> adam3us: ie, you're not spamming data
15:51 < adam3us> ok so to stop people stuffing up the blockchain with stupid stuff that doesnt belong is the motivation?  that sounds like a good idea
15:54 < adam3us> to do validation later however, you are going to need the preimage (eg validate back to genesis full validation , new full client comes online) and storing data + h(nonce|data) isnt smaller than storing data
15:54 < adam3us> if the data is not necessary for validation however, that'd be a good idea and does not need to be stored, only maybe relevant to people sending/receiving the payent
15:55 < gmaxwell> adam3us: petertodd is talking about more than proving its a hash, he wants to also prove that the public knew the preimage at some time.
15:55 < gmaxwell> The reason that peter wants that because he wants to use bitcoin as a jamming resistant communications channel.
15:56 < adam3us> and you'd do that in 2 phases, commit first, then disclose hash pre-image?
15:56 < gmaxwell> (In order to do things like announce an anyone can spend transaction in order to prove that funds were thrown away.)
15:57 < petertodd> adam3us: Nope, disclose fully first - I'm not assuming censorship.
15:58 < adam3us> doesnt the tx itself prove funds were spent to anyone?
15:58 < adam3us> (the tx is part of the tx history so anyone can verify that)
15:58 < gmaxwell> adam3us: no, because a miner could spend anyone can spend transactions that no one saw before they were in the block.
15:58 < petertodd> adam3us: A miner can mine and spend the funds to themselves in one go.
15:58 < gmaxwell> So he could be paying himself.
15:59 < adam3us> ah ok i remember that discussion from before
16:00 < petertodd> adam3us: It's a tough problem because the miner might even be making a whole bunch of sacrifices at once, so much so that the sum of the value makes throwing away blocks to find a lucky sequence of a few in a row is still profitable.
16:01 < adam3us> so to prevent that you say, a tx is not considered sacrificed, unless it was announced, for some time, and then released, presuming more than one miner contributed you are reasonably confident no individual miners spent it to themselves
16:01 < petertodd> Basically the interval between announce and commit is proof that n blocks * hashes/second * 10 minutes of hashing power integral saw the transaction.
16:01 < petertodd> Hence proof-of-visibility.
16:15 < adam3us> petertodd: ok, and remind me what is the use case for proof of sacrifice; you mentioned pseudonym reputation (misbehave you lose the pseudonym & sacrifice cost) - anything else?
16:21 < petertodd> adam3us: You can use it as an alternative to PoW
16:21 < petertodd> adam3us: Anti-spam, or even constructing a whole blockchain.
16:23 < adam3us> petertodd: in the form discussed in this thread it is a payment to miners, the PoW uses would need a direct mined version?
16:24 < adam3us> petertodd: proof that i worked towards mining bitcoins for the benefit of miners, which may or may not have resulted in actual coins being created .. eg only 1 in 10000 would it succeed because of limited power
16:26 < petertodd> adam3us: What you are describing is proof-of-work towards a sacrifice; proof-of-sacrifice is more general than that.
16:26 < petertodd> adam3us: You don't need hashing power at all to make a sacrifice proof.
16:27 < adam3us> petertodd: correct, but u said could be used as a PoW - giving bitcoins to miners is like a charitable act
16:27 < adam3us> petertodd: i am not sure you can eg back an alt-coin in the PoW of giving bitcoins to miner charity?
16:28 < petertodd> adam3us: No, as an alterative to a PoW
16:28 < petertodd> adam3us: For instance you can make a consensus key-value system where consensus is achieved by looking for the highest sacrifice of Bitcoins rather than largest proof-of-work.
16:29 < adam3us> petertodd: oh ok, for the stated applications of anti-spam, pseudonym reputation; but you also said as a PoW for constructing a block chain?
16:29 < petertodd> adam3us: As a replacement for a PoW
16:30 < adam3us> petertodd: ok, msg crossed
16:30 < petertodd> What's good about sacrifice rather than proof-of-work is that often getting access to hashing power is hard or inconvenient; making it a sacrifice levels the playing field and simplifies things.
16:30 < adam3us> petertodd: however thats like us politics: one $ one vote - the outcome is biased in favor of the rich criminals?
16:31 < amiller> only if they get the $ after ward
16:31 < amiller> one $ one vote is actually pretty reasonable if you force them to pay
16:31 < amiller> i think its the best you can get
16:31 < amiller> sorry only if they don't* get the $ afterward
16:32 < petertodd> adam3us: Meh, it's the best we have in a decentralized digital system.
16:32 < amiller> if it were actually one $ one vote it would drive out all the richest people who enjoy higher gain investments elsewhere
16:32 < adam3us> petertodd: this sounds a bit like your pay to replace idea: the tx with the highest fee (or fee commit) is going to win period
16:33 < petertodd> adam3us: Well yeah, again, it's a decentralized digital system; there are no alternatives.
16:33 < petertodd> adam3us: It's not like we can have a little AI that evaluates original topical poems as the work function.
16:34 < adam3us> wait wait: if the consensus is in terms of which transaction is considered first (like bitcoin), then one $ one vote is not so good eh?  wait for user to accept payment, take goods, outpay their fee to pay to self and override your own previous transaction?
16:34 < petertodd> As always, zero-conf is insecure; wait for sufficient confirmations.
16:35 < Luke-Jr> adam3us: on the other hand, the merchant can screw the scammer by putting 100% of the coins into fee
16:36 < petertodd> (It's interesting to note how proof-of-captcha would be possible if only you could make a captcha whose answer you provably didn't know in advance)
16:36 < Luke-Jr> petertodd: you'd also need to make a captcha that works
16:36 < amiller> one $ one vote is best attainable because if you assume a $ is power incarnate that can purchase anything, which is what money is, then you can literally buy people with it and there isn't really anything that can be done about that
16:36 < petertodd> Luke-Jr: I said possible. :P
16:36 < Luke-Jr> these days I have to try them like 5 times, and the people trying to automate it just hire slaves
16:37 < petertodd> Luke-Jr: Well, slaves is still involving people... actually with a TPM proof-of-captcha would be possible trivially.
16:37 < gmaxwell> yea, I really wish there were some addon that used the commercial captcha solving services. The spammers have driven the captcha prices pretty low.
16:37 < petertodd> gmaxwell: lol!
16:37 < amiller> if you have a tpm then you just use the tpm for all your money and a captcha isn't necessary
16:37 < amiller> you just mean a tpm
16:37 < adam3us> i think the problem with $ for voting is while mining hardware & electricity costs $ also, actual $ is completely elastic supply
16:38 < petertodd> amiller: You might still want proof-of-human though - it might not be a currency we're using this for.
16:38 < adam3us> so it hard to build a fair consensus based on biggest fee wins?
16:38 < petertodd> adam3us: Right, which is why s/$/BTC/...
16:38 < amiller> proof-of-human is nonsense too tbh, what are we gonna do when we have to economize with the hivemind slime mold creatures in space
16:38 < adam3us> yes but i can buy btc for $
16:38 < petertodd> adam3us: No it's trivial for some definition of "fair"
16:39 < petertodd> adam3us: Irrelevant, inflating the $ supply just makes the BTC more expensive.
16:39 < adam3us> petertodd: the other thing is i think the scammer has more incentive to pay stupidly high fees than real users and real merchants, so the scammer always wins
16:41 < gmaxwell> adam3us: as luke pointed out before, if the merchant is aware of that he can 100% fee in response and so the scammer never wins in that world.
16:41 < adam3us> the other thing is bitcoin consensus is not just saying which tx happened first out of a double-spend set, it is also validating transactions add up
16:42 < adam3us> so how would this work: collect a block of txs, validate them, and attach a fee if you care about a tx in there
16:43 < petertodd> adam3us: All this is silly, just don't accept zero-conf and you're fine.
16:43 < petertodd> adam3us: Or trust in the scorched earth policy that makes scamming useless.
16:43 < petertodd> adam3us: There are *so* many ways to double-spend...
16:43 < adam3us> petertodd: ok no zero-conf, still how does it work
16:44 < adam3us> fee is a signature on the fee tx and the block
16:44 < adam3us> and person who pays biggest fee wins? .. that'll preusmably be the guy with the biggest tx ... eg guy who just bought a house
16:45 < petertodd> adam3us: wins what?
16:45 < adam3us> no one accept the fee-signed block to build on unless they agree there are no double spends in it
16:45 < adam3us> (is considered valid vs competing block signatures?)
16:46 < petertodd> Huh? The definition of a block is that there can be no double-spends in it.
16:46 < adam3us> well relative to previous blocks too
16:47 < petertodd> The definition is also that it can't double-spend previous blocks.
16:48 < adam3us> yes and that fact is validated by full nodes is all i mean
16:48 < petertodd> I don't get where you are going with this...
16:50 < adam3us> just thinking aloud seeing where it goes (using Po sacrifice in place of PoW) strangely it seems to sort of work?
16:51 < petertodd> ah, you mean if you had a cryptocurrency whose block ordering was chosen by PoS
16:52 < adam3us> yep
16:53 < adam3us> i think the problem will come with splits: if some part of the network creates conflicting transactions that are not broadcast until later
16:53 < adam3us> the bitcoin resolution protocol no longer works , instead there will be a bidding war to win, rather than a CPU race
16:54 < adam3us> (even after say 3 blocks where some users may have locally accepted the transaction)
16:55 < petertodd> Well the resolution protocol can easily have the blockchain be a directed acyclic graph instead where non-conflicting transactions in different forks on the graph can be merged back together later.
16:56 < petertodd> The incentive to broadcast your blocks (which can be just a single transaction) would then be to prevent rewriting by being on a part of the graph with maximal sacrifice.
16:56 < petertodd> Problem is how do you distribute the coins in the first place?
16:57 < petertodd> It'd also have ugly problems if transaction volume was low, because you're only safe from a rewrite once more coins have been sacrificed by *others* than your transaction was worth.
16:57 < petertodd> Hard to bootstrap that...
16:58 < petertodd> It is interesting though how it suggests that a proof-of-stake cryptocoin is probably more viable if there isn't a block reward.
17:01 < petertodd> Not much more viable mind you: it's still the fundemental problem of how do you know time has moved forward without a random beacon. (IE signing for a bunch of stake is something I can only do once - after that more signatures are meaningless, yet there's no good way to decide on what % ofthe outstanding coins should participate)
--- Log closed Wed Jul 03 00:00:07 2013