{"type":"rich","version":"1.0","author_name":"npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj","author_url":"https://nostr.ae/npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-05-15\n📝 Original message:So in a previous mail I described a simple, extremely efficient and easy to\nimplement symmetric key commitment that is unlinkable until reveal time (at\nbottom).  I think this can help improve the byzantine generals problem, that\nbitcoin only defends to simple majority (with one vote per CPU power), and\nso assumes most nodes by cpu power are honest.  With this simple protocol\nchange you dont need any honest nodes, just some honest clients to spend to,\nto have your transaction accepted.  \n\nYou can think of this in terms of a (somewhat distributed) server performing\nvalidations, but in a way that it sufficiently blind to the details of the\nvalidations that it can not selectively enforce a policy, it power is\nlimited to random DoS.\n\nThere are other situations where you can rely on a server for one property\nbut not another - eg a somewhat distributed encrypted backup (like Tahoe\nLAFS) you rely on for availability, but not integrity nor confidentiality\n(because you encrypt those, and some sharing scenarios still work.) So this\nis in that class of protocols - zero-trust in server, but can extract\nservice and some guarantees from the (optionally distributed) server anyway.\n\n(Bitcoin does not use known better than majority results for byzantine\ngenerals based on fair coin toss, relying instead on simple majority and an\nassumed largely unjammable network.  I notice Nick Szabo was complaining\nabout this on his blog and saying bitcoins majority is not even a standard\nor proven byzantine voting protocol - something adhoc.  I think the bitcoin\nunjammable network assumption is a false at the limit so that someone with\nstrong network hacking capabilities can create network splits long enough to\neven overcome the network majority vote without having any compute power of\ntheir own.  All they need is to have a split with enough power to plausibly\nquickly get the victims their desired number of (split) confirmations.)\n\nAnyway this should be a clear voting improvement, that is efficient.\n\nImagine a couple of big pools or ASIC miners started enforcing some\narbitrary coin policy, eg say coins must not have some taint according to\nits list of black coins, or coins must be certified by some entity, be\ntraceable to some type of event etc.  Well call these miners/voters\n\"dishonest\", in that they are not following the intended zero-policy\nprotocol.\n\nIf the coins dont match their chosen policy, the dishonest miners will\nrefuse to include transactions in blocks they issue.  If they see a\ntransaction which does not match their policy in a block by someone else\nthey will ignore it and try to make it into an orphan.  As they have say 75%\nof the network power they can do that successfully.  Even with current\nvalidation protocols in the clients, so the \"but clients wont accept the\nchange\" argument does not apply - the existing clients will accept the\npolicy change, because they cant detect it, nor prove it, and dont have the\nvoting power to impose honest policies.\n\n(For realism of this risk, note that according to Kaminsky there already\nexist multiple entities with reserve ASIC power each exceeding current\nnetwork difficulty who are holding part of their power in reserve for profit\nmaximisation reasons.  This is a coming to fruition of the concentration of\npower issue I was talking about in my first bitcoin forum post.  People who\nhave that kind of power in reserve have clearly invested millions of\ndollars, which probably makes them more vulnerable to political influence.)\n\n\nAlright so the solution.  Use the commitment protocol (below) which even\nthough it is symmetric key strongly hides the committed transaction public\nkey.  (Symmetric in the sense that the validation steps are all highly\nefficient symmetric key based).  Now send the transaction (which includes\nthe public key) direct to the receiver, over a secure channel, or an assumed\nnon-eavesdropped direct channel, with no p2p flood of the transaction.  The\nreceiver can check the hash to the commitment, and decide how many\nconfirmtions he needs.  Once he has eg 6 confirmations he reveals the\ncommitment to the transaction (by publishing it).  The sender may also send\nthe reveal/transaction to the network directly himself, if the recipient is\noffline.  However there is no advantage to publishing early so it seems\nbetter to let the recipient do it when he is ready to incorporate the\npayment into his wallet.  \n\nNow the powerful dishonest voters if they try to apply their policy when\nthey see the reveal triggers it, must redo the work of the 6-commitments\nthat they computed themselves.  This is like starting 6-steps behind in the\nstatstical gamblers ruin game that Nakamoto describes in the bitcoin paper. \nConsequently even with 75%, they will find it very hard to outcompete their\nown prior work, to create a 6 chain long orphan while the 25% is moving\nforward on the honest chain.  Each time they see transactions which violate\ntheir policy, they have to restart their chain recalculation again from\nscratch.  Often if simple lower powered intermittent recipient sends the\ncoin will be burried hundreds of blocks back.  In addition 6 chain long\nbranches are extremely unlikely with honest payers, so clients can (and\nmaybe already do?) act with suspicion of they see one.\n\n\nGoing further, I said for best security, the recipient should never even\nreveal (to the network) until he is actually about to spend, but futher he\ndoes not even have to reveal publicly ever, he can choose to reveal only to\nthe recipient with a direct connection (no p2p flood fill of transaction.)\nAnd the direct spend argument composes, ie the 2nd recipient can not do the\nsame thing again.  (public key A sends to public key B sends to public key\nC: B publishes COM( transaction B-\u003eC ), sends the reveal of COM( transaction\nA-\u003eB ), and COM transaction B-\u003eC ) to C.  C waits 6 confirmations and is\nconvinced.  So its the approach is composable, and in fact the network\ndoesnt learn the size of the transaction even, though the spend grows each\ntime.  Eventually presumably someone will publish will the confirmations to\nthe network to trim the tansaction size, though it is not strictly\nnecessary, and the transaction flow is small and direct (no network scaling\nissues), so that it wouldnt be a huge problem to have a 1MB payment\nrepresenting 1000s of hops of network blind transactions.  (For the\ncomposable network blind respending the commitment has to commit publicly to\nboth the sender and next hop recipient keys, so the network can see how long\nthe chain is).\n\nProbably you can cope with multiple inputs and outputs, and maybe given even\nyou can work with a 100% dishonest network mining network (all the dishonest\nminer can do is selectively DoS transactions if they are all network blind\nexcept the mining), maybe the mining can even be decoupled from the voting,\nas you no longer demand much from the voting process.  That admits more\ninteresting things like pool free direct mining, low variance hashcash\ncoins, probably.  Many things to think through.\n\nI suppose the commitment could be described as a blind symmetric commitment.\n\nAdam\n\nOn Tue, May 14, 2013 at 04:09:02PM +0200, Adam Back wrote:\n\u003e [...]\n\u003e\n\u003eOne related concept is commitments.  I think its relatively easy to commit\n\u003eto a payment and lock a coin without identifying yourself, until the\n\u003ecommitment is released.  You might do the commitment, wait 6-blocks for\n\u003econfirmation, then reveal the commitment.  Then that is like a self-issued\n\u003egreen coin with no need for trust, that can be immediately cleared.  The\n\u003erecipient has to be committed to at the same time to prevent double\n\u003espending.\n\u003e\n\u003eSo just commit = H( input-pub ) H( transaction ) and put it in the block\n\u003echain.  Where transaction the is usual ( input signature, output-pub,\n\u003escript).  (Fee for the commit would have to come from an unlinked coin or\n\u003ethe input-pub reveals the coin).  Wait 6 blocks, send/reveal the transaction\n\u003e(free because fee was already paid).  Validators check input-pub hash\n\u003eagainst committed coins by hash, check the transaction hash, and the usual\n\u003eransaction validations = sum inputs, otherwise reject.  The user better pay\n\u003echange if any to a different public key, as the inputs public keys are one\n\u003euse - are after the reveal they are DoS lockable by other people reposting\n\u003eH( input-pub ).\n\u003e\n\u003eThe input-pub coin is locked as normal transactions have their public key hash\n\u003evalidate as not being locked.\n\u003e\n\u003eAdam"}