[Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
So in a previous mail I described a simple, extremely efficient and easy to implement symmetric key commitment that is unlinkable until reveal time (at bottom). I think this can help improve the byzantine generals problem, that bitcoin only defends to simple majority (with one vote per CPU power), and so assumes most nodes by cpu power are honest. With this simple protocol change you dont need any honest nodes, just some honest clients to spend to, to have your transaction accepted. You can think of this in terms of a (somewhat distributed) server performing validations, but in a way that it sufficiently blind to the details of the validations that it can not selectively enforce a policy, it power is limited to random DoS. There are other situations where you can rely on a server for one property but not another - eg a somewhat distributed encrypted backup (like Tahoe LAFS) you rely on for availability, but not integrity nor confidentiality (because you encrypt those, and some sharing scenarios still work.) So this is in that class of protocols - zero-trust in server, but can extract service and some guarantees from the (optionally distributed) server anyway. (Bitcoin does not use known better than majority results for byzantine generals based on fair coin toss, relying instead on simple majority and an assumed largely unjammable network. I notice Nick Szabo was complaining about this on his blog and saying bitcoins majority is not even a standard or proven byzantine voting protocol - something adhoc. I think the bitcoin unjammable network assumption is a false at the limit so that someone with strong network hacking capabilities can create network splits long enough to even overcome the network majority vote without having any compute power of their own. All they need is to have a split with enough power to plausibly quickly get the victims their desired number of (split) confirmations.) Anyway this should be a clear voting improvement, that is efficient. Imagine a couple of big pools or ASIC miners started enforcing some arbitrary coin policy, eg say coins must not have some taint according to its list of black coins, or coins must be certified by some entity, be traceable to some type of event etc. Well call these miners/voters dishonest, in that they are not following the intended zero-policy protocol. If the coins dont match their chosen policy, the dishonest miners will refuse to include transactions in blocks they issue. If they see a transaction which does not match their policy in a block by someone else they will ignore it and try to make it into an orphan. As they have say 75% of the network power they can do that successfully. Even with current validation protocols in the clients, so the but clients wont accept the change argument does not apply - the existing clients will accept the policy change, because they cant detect it, nor prove it, and dont have the voting power to impose honest policies. (For realism of this risk, note that according to Kaminsky there already exist multiple entities with reserve ASIC power each exceeding current network difficulty who are holding part of their power in reserve for profit maximisation reasons. This is a coming to fruition of the concentration of power issue I was talking about in my first bitcoin forum post. People who have that kind of power in reserve have clearly invested millions of dollars, which probably makes them more vulnerable to political influence.) Alright so the solution. Use the commitment protocol (below) which even though it is symmetric key strongly hides the committed transaction public key. (Symmetric in the sense that the validation steps are all highly efficient symmetric key based). Now send the transaction (which includes the public key) direct to the receiver, over a secure channel, or an assumed non-eavesdropped direct channel, with no p2p flood of the transaction. The receiver can check the hash to the commitment, and decide how many confirmtions he needs. Once he has eg 6 confirmations he reveals the commitment to the transaction (by publishing it). The sender may also send the reveal/transaction to the network directly himself, if the recipient is offline. However there is no advantage to publishing early so it seems better to let the recipient do it when he is ready to incorporate the payment into his wallet. Now the powerful dishonest voters if they try to apply their policy when they see the reveal triggers it, must redo the work of the 6-commitments that they computed themselves. This is like starting 6-steps behind in the statstical gamblers ruin game that Nakamoto describes in the bitcoin paper. Consequently even with 75%, they will find it very hard to outcompete their own prior work, to create a 6 chain long orphan while the 25% is moving forward on the honest chain. Each time they see transactions which violate their policy, they have to restart their chain recalculation again
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
On Wed, May 15, 2013 at 12:25:09PM +0200, Adam Back wrote: Protocols aren't set in stone - any attacker that controls enough hashing power to pose a 51% attack can simply demand that you use a Bitcoin client modified to provide the attack with the full transactions from the beginning. Any blocks containing transactions with unknown contents will be attacked into oblivion. On the other hand if the attacker has less than 50% of the hashing power, they have no choice but to let other blocks through, and provided miners are free from regulation imposed on them you can bid to get your transactions mined with fees. Anyone using a blockchain-based crypto-currency simply has to accept that mining is a random process and getting a transaction confirmed is inherently unreliable. So in a previous mail I described a simple, extremely efficient and easy to implement symmetric key commitment that is unlinkable until reveal time (at bottom). I think this can help improve the byzantine generals problem, that bitcoin only defends to simple majority (with one vote per CPU power), and so assumes most nodes by cpu power are honest. With this simple protocol change you dont need any honest nodes, just some honest clients to spend to, to have your transaction accepted. -- 'peter'[:-1]@petertodd.org 01754b62829d854463fa72fe7d972a7b7d13d0c30fc86423773c signature.asc Description: Digital signature -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] 2BTC reward for making probabalistic double-spending via conflicting transactions easy
Now that I have the replace-by-fee reward, I might as well spread the wealth a bit. So for all this discussion about replace-by-fee and the supposed security of zero-conf transactions, no-one seems to think much about how in practice very few vendors have a setup to detect if conflicting transactions were broadcast on the network simultaneously - after all if that is the case which transaction gets mined is up to chance, so much of the time you'll get away with a double spend. We don't yet have a mechanism to propagate double-spend warnings, and funny enough, in the case of a single txin transaction the double-spend warning is also enough information to allow miners to implement replace-by-fee. So I'm offering 2BTC for anyone who comes up with a nice and easy to use command line tool that lets you automagically create one version of the transaction sending the coins to the desired recipient, and another version sending all the coins back to you, both with the same transaction inputs. In addition to creating the two versions, you need to find a way to broadcast them both simultaneously to different nodes on the network. One clever approach might be to use blockchain.info's raw transaction POST API, and your local Bitcoin node. If you happen to be at the conference, a cool demo would be to demonstrate the attack against my Android wallet. I'll buy Bitcoins off of you at Mt. Gox rates + %10, and you can see if you can rip me off. Yes, you can keep the loot. :) This should be videotaped so we can put an educational video on youtube after. -- 'peter'[:-1]@petertodd.org 00bafd0a55f013e058cc2a672ee0c66b9265a02390d80e4748f5 signature.asc Description: Digital signature -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
I can't see this working, if 51% of the mining power doesn't like your coins, when you create the commitment they will reject it. If the commitment is opaque at the time of inclusion in the block then I will create multiple commitments and then after revealing the commitment and spend to you I will reveal the earlier commitment which commits the coins to an address I control. On the topic of reversibility, I suspect in the long term the lack of chargebacks will create issues as criminals learn that for the first time in history, kidnap ransom is effective. Suffice to say after the first = $10mn kidnapping-for-bitcoin heist, governments will be forced to decide how they view the system. It will likely fall somewhere between arrest/question anyone identified holding tainted coins to something nonsensical and reactionary like blocking bitcoin as Iran does TOR. Thanks, Caleb On 05/15/2013 07:49 AM, Adam Back wrote: On Wed, May 15, 2013 at 07:19:06AM -0400, Peter Todd wrote: Protocols aren't set in stone - any attacker that controls enough hashing power to pose a 51% attack can simply demand that you use a Bitcoin client modified [to facilitate evaluation of his policy] Protocol voting is a vote per user policy preference, not a CPU vote, which is the point. Current bitcoin protocol is vulnerable to hard to prove arbitrary policies being imposable by a quorum of 50% miners. The blind commitment proposal fixes that, so even an 99% quorum cant easily impose policies, which leaves the weaker protocol vote attack as the remaining avenue of attack. That is a significant qualitative improvement. The feasibility of protocol voting attacks is an open question, but you might want to consider the seeming unstoppability of p2p protocols for a hint. Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] double-spend deletes (or converts to fees) (Re: reward for making probabalistic double-spending via conflicting transactions easy)
On Wed, May 15, 2013 at 07:38:27AM -0400, Peter Todd wrote: no-one seems to think much about how in practice very few vendors have a setup to detect if conflicting transactions were broadcast on the network simultaneously - after all if that is the case which transaction gets mined is up to chance, so much of the time you'll get away with a double spend. We don't yet have a mechanism to propagate double-spend warnings, and funny enough, in the case of a single txin transaction the double-spend warning is also enough information to allow miners to implement replace-by-fee. About double-spends it might be better if the double-spend results in no-one keeping the money ie it gets deleted by definition (except for the fees, or the whole payment gets converted into a 0BTC output so 100% fees). Ideally you'd want a way for known double spends to be circulated at priority in the p2p network, even routed directly to earlier recipients if known. However have to watch out for even the fees being double spent in other transactions. Maybe the fees could be demanded to be self-created (no trusted green-coin issuer) 6-confirmation spend-to-miner green-coins. (Note double spends are not-binary. An attacker can spend a 25BTC coin via 50x 1BTC transactions. Which 25 are valid? Currently it is the first 25 from the network perspective of the miner that succeeds on the current block. (And that view overrides, even if other miners had differing views, unless the block later becomes an orphan). Its surely easy for a double spender to accumulate fast connections to known powerful miners to get the spends that benefit him to them first.) In that way (with double-spend deletes) the would be double-spender can not gain within the bitcoin protocol by double spending. He can gain outside of the protocol eg by persuading merchants to give him non-revocable resellable non-physical goods (or physical but anonymous goods). But that is harder work, and people selling goods with no recourse will be defensive about confirmations. ps I still dont think replace-by-fee is a good idea, at least the way it was implemented with changeable outputs, but I think that discussion seemed closed, so I wont rehash it. Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 2BTC reward for making probabalistic double-spending via conflicting transactions easy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You can do this right now, with Armory. If you switch Armory to Expert usermode, you can combine coin-control with unsigned transactions to do exactly this. It's because Armory doesn't lock coins used in previous unsigned transactions, until they're actually broadcast and confirmed to be out in the wild. This was done for simplicity to avoid people getting arbitrarily-locked coins, even though it means you end up accidentally double-spending if you try to create two different unsigned transactions from the same wallet without signbroadcasting the first one. So here's what you do: (1) Switch to Expert usermode in Armory (2) Open any wallet (you don't need a watch-only wallet, full wallet is fine) (3) In the Send Bitcoins window, click coin-control (4) Create a transaction using one sufficiently large input (5) Click Create Unsigned Transaction and save it (6) Repeat 3-5 with the same coin, but sending to yourself, specify a larger fee (7) Go into Offline Transactions and Sign and Broadcast Transactions (8) Load tx1, sign broadcast (9) Load tx2, sign broadcast This only works if your Bitcoin-Qt/bitcoind client has the replace-by-fee patch, since Armory uses Bitcoin-Qt/bitcoind as a gateway to the network. Otherwise, the second tx will be DOA. But you don't have to mess with Armory other than switching it to Expert mode to get to the coin-control feature. - -Alan P.S. -- If you try this, Armory is likely to not show the second tx as having ever happened (Bitcoin-Qt will send it back to us and we ignore it because we already have a tx). But if your Bitcoin node has the modification, it /will/ reach the network On 05/15/2013 08:19 AM, Peter Todd wrote: On Wed, May 15, 2013 at 07:38:27AM -0400, Peter Todd wrote: So I'm offering 2BTC for anyone who comes up with a nice and easy to use command line tool that lets you automagically create one version of the transaction sending the coins to the desired recipient, and another version sending all the coins back to you, both with the same transaction inputs. In addition to creating the two versions, you need to find a way to broadcast them both simultaneously to different nodes on the network. One clever approach might be to use blockchain.info's raw transaction POST API, and your local Bitcoin node. Oh, and while we're at it, a good starting point for your work would be Gavin's spendfrom utility in the contrib/spendfrom directory in the Bitcoin-QT respository. Also please do keep in mind that it's much better for the community if an attack is demonstrated first, followed by releasing the code some time later. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRk441AAoJEBHe6b77WWmFZNQP/02t6cQkhih/CcA1oSCM72np KMRW0Z+piHShORxLyhMX3cIpi3ICJ2lJ/Pm6GfDn74oSHq8wipIFoV88xhy810bL MnJtbPH900v8PHh/ji2nWMig9NibeUa1zV9/tp31rYjUT3mmMoC4yQlyxKII8GWK iignkAHV/UL5kQGmhmr1RKN127cthSMeIzAYWXfIWVObPNm85pvizVZdgqzSK73h vwdfeFOelNbVn8ZCNT19OsxWfAKZSaBMywAX95wQBs0BtY2ZgDRmeXa6MdQKpXGW KP3O2zjjJC2CKc4+L6elMfsoL1doEsk35w/GuI4HZK4MLAI8BChi6ZPnAYjdRvir eHeszyxkKDCEaJ9JPLA/AszqkYHIB+56wTtrpVb1duyTwuqgVT5dcpMPIH8bDqjq k3I8C9zCSeQ6JgyvOd8grKJchRtq0SOWYt2bB3ytePzwOs+W+6mRenb/WtMt2dQg ntDTEIG7pCsWHenipeTBzvJNqeSsAAoIXnkGY20iDxCB+uFkTzisoCQqpOIglArm vD+Cl2nv3OKU3NTVTUt2VinoFskezI7xvsxHD8xs2V/hrlpPbPRAo+l7ER6aTazj wrONfmllHSE2XCM7wb/bX3gBNmsM3zUIgSBmNSH/SQeTy8PvwvlkZ/RRYmtVSmHL rUTp7x4U63JiIDO1jj+T =JiPo -END PGP SIGNATURE- -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
On Wed, May 15, 2013 at 08:40:59AM -0400, Caleb James DeLisle wrote: If the commitment is opaque at the time of inclusion in the block then I will create multiple commitments and then after revealing the commitment and spend to you I will reveal the earlier commitment which commits the coins to an address I control. Bit-commitments are based on deterministic one-way functions eg like SHA1( SHA256( public key ) ) Obviously it has to be a different one-way function to the coin address calculation which is RIPEMD( SHA256( public key ) ) as that is already public. Alternatively it can be a different serialization using the same hash eg RIPEMD( SHA256( 1 || public key ) ). There is only one commitment possible per public key - so you can only create one commitment that would validate to a receiver, or to the network. The network checks that there are no non-blind double spends of committed coins which it can do as spends require disclosure of the public key, which allows existing commitments to be verified, and it similarly qchecks that there are no blind double-commitments. Each committed coin would be: one-spend-commit = Com( spender pub ), Com( transaction ) where Com is implemented as the above hash. The network just places the commitments in order as with conventional transactions. The committed coins are not linkable to your non-blind coin because you did not reveal your public key in the (largely passive) act of receiving to a coin address. On the topic of reversibility, I suspect in the long term the lack of chargebacks will create issues as criminals learn that for the first time in history, kidnap ransom is effective. The temporary unlinkability (until commitment reveal) is a necessary side effect, not a cryptographic anonymity feature like zerocoin. The transactions are identical to bitcoins once revealed. How long the committed transaction chains can be between reveals is an implementation choice could be 1 hop, or as long as you like. (Actually it appears to be up to the individual users how long the maximum chain they accept is - the network itself, though ordering the committed spends (if there are multiple spends on the same key) cant even tell how long the commitment payment chains are). Obviously the first coins in the network ordered committed coins on the same key up to the coin value are spends as verified by the recipient, the rest are double-spend and ignored. If someone wants to waste fees by sending more spends than there inputs thats up to them. Probably the typical user doesnt care about long committed chains other than their wallet will bloat if the chains are too long, so probably they would periodically compact it by revealing the long chains. Committed coins are probably a bit less SPV client friendly, though with correct formatting in the merkle trees between blocks, probably a committed coin holder can provide enough proof to an SPV client to verify even multi-spend committed coins directly (without a network feed). About privacy, up to the entire commitment chain can be opened at any time (to other people or to the bitcoin network in general) with the cooperation of any user on the chain (up to the point they saw it), so while the blind commitment protocol is not vulnerable to a 50% power quorum unilaterally imposed policy (without even needing client updates), it is fully dependent on the good will of the recipients for its temporary unlinkability. Thats the point: it puts policy control in the users hands not in the 50% power quorum. If you want cryptographic anonymity its better to look to zerocoin. You may have noticed zero coin talked about optional fraud tracing. Its usually trivial to add tracing to an otherwise privay preserving protocol. The blind commitment if implemented as described (and its not obvious how to get more privacy from it) offers somewhat like community policing. Users on the chain can still themselves do fraud tracing, or any policy they choose, on any blind committed coins that they receive. If they dont like the colour of them they can refund them. The point is to enforce that this is a free uncoerced community choice, by individual end users, not a 50% cpu power quorum choice surreptitiously imposed. Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
On 05/15/2013 12:21 PM, Adam Back wrote: On Wed, May 15, 2013 at 08:40:59AM -0400, Caleb James DeLisle wrote: If the commitment is opaque at the time of inclusion in the block then I will create multiple commitments and then after revealing the commitment and spend to you I will reveal the earlier commitment which commits the coins to an address I control. Bit-commitments are based on deterministic one-way functions eg like SHA1( SHA256( public key ) ) Obviously it has to be a different one-way function to the coin address calculation which is RIPEMD( SHA256( public key ) ) as that is already public. Alternatively it can be a different serialization using the same hash eg RIPEMD( SHA256( 1 || public key ) ). Ahh thanks for clearing that up, although it would limit the possibilities of scripting it is silly of me not to think of it. There is only one commitment possible per public key - so you can only create one commitment that would validate to a receiver, or to the network. The network checks that there are no non-blind double spends of committed coins which it can do as spends require disclosure of the public key, which allows existing commitments to be verified, and it similarly qchecks that there are no blind double-commitments. Each committed coin would be: one-spend-commit = Com( spender pub ), Com( transaction ) where Com is implemented as the above hash. The network just places the commitments in order as with conventional transactions. The committed coins are not linkable to your non-blind coin because you did not reveal your public key in the (largely passive) act of receiving to a coin address. On the topic of reversibility, I suspect in the long term the lack of chargebacks will create issues as criminals learn that for the first time in history, kidnap ransom is effective. The temporary unlinkability (until commitment reveal) is a necessary side effect, not a cryptographic anonymity feature like zerocoin. The transactions are identical to bitcoins once revealed. How long the committed transaction chains can be between reveals is an implementation choice could be 1 hop, or as long as you like. (Actually it appears to be up to the individual users how long the maximum chain they accept is - the network itself, though ordering the committed spends (if there are multiple spends on the same key) cant even tell how long the commitment payment chains are). Obviously the first coins in the network ordered committed coins on the same key up to the coin value are spends as verified by the recipient, the rest are double-spend and ignored. If someone wants to waste fees by sending more spends than there inputs thats up to them. Probably the typical user doesnt care about long committed chains other than their wallet will bloat if the chains are too long, so probably they would periodically compact it by revealing the long chains. Committed coins are probably a bit less SPV client friendly, though with correct formatting in the merkle trees between blocks, probably a committed coin holder can provide enough proof to an SPV client to verify even multi-spend committed coins directly (without a network feed). About privacy, up to the entire commitment chain can be opened at any time (to other people or to the bitcoin network in general) with the cooperation of any user on the chain (up to the point they saw it), so while the blind commitment protocol is not vulnerable to a 50% power quorum unilaterally imposed policy (without even needing client updates), it is fully dependent on the good will of the recipients for its temporary unlinkability. Thats the point: it puts policy control in the users hands not in the 50% power quorum. That is indeed interesting. If I understand this properly Alice commits coins to pay to Bob and gives Bob the transaction, Bob then commits to pay to Charlie and gives him the related transaction. If Charlie wants to collect the bitcoin he then reveals Alice's transaction and Bob's. I think what you're trying to do is *almost* possible now (ab)using BIP-0016 In the output of the previous tx you put: OP_HASH160 [20-byte-hash-value] OP_EQUAL and in the next tx you use a new type of input which specifies it's value but not the output which is spent. In the input script you place: OP_DUP OP_1ADD OP_HASH160 [20-byte-hash-value] OP_EQUALVERIFY Then a serialized script containing the normal stuff as well as the last transaction hash and output index would be passed around out of band and the validating nodes would execute each script with a shared stack, beginning with the out of band one, then the input one (the OP_EQUALVERIFY) then the output. When the serialized sigscript reaches the bottom of the stack, having been verified twice, it will now be evaluated as per the rules of P2SH. None of this probably works in the real world since I'm not familiar with the actual implementation of
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
btw I posted some of this thread on the dev forum: https://bitcointalk.org/index.php?topic=206303.msg2157994#msg2157994 A related idea is occuring to me that maybe these committed transactions could actually as a side effect make bitcoin scale slightly better by reducing the p2p flood filled transaction size. As I said on the forum: Note committed transactions are more compact than regular transactions - they are just two hashes, so they reduce network bandwidth and make bitcoin more scalable to the extent that transaction reveals stay off network. (As well as more secure against centralization policy risks). Surely its lower bandwidth for nodes to send only committed transactions to the p2p network, and pass committed payment chains direct to recipients. Say committed transaction size is c (20bytes+32bytes+16bytes +header ~ 72 bytes?) And full transaction smallest size is t (txin=20bytes, amount out 4bytes, sender pub key 32bytes, recip address 20bytes, change address 20bytes, formatting 5 bytes, ECDSA signature 64bytes, script 10 byte surely ~ 175bytes)? Thats over twice the size. Probably average more, and it is sent to every node. Its always going to be lower bandwidth to send transactions to the recipients than to send to the network, even if you have to increase the transaction size with each respend. The alternative is for the entire network to see the same transaction. I think the commitment needs to bind the two parts together eg (blind-sender, auth-tag, tx-commit) blind-sender = SHA1( SHA256( 1, pub ) ) auth = HMAC-SHA256-128( K, tx-commit ) tx-commit = SHA-256( tx ) Or some variantion, and you must not reuse the pub key, and must send change if any to a different address, otherwise chain recipients or malicious forwarders could lock your coin, by putting random junk onto the network which would be unverifiable, and non-disclaimable - you cant prove you dont know the preimage of some junk. The MAC prevents it. Maybe there's a more compact way to do it even, but that works efficient demonstration of security feasibility. Other public key variants could be possible, P = xG is the ECDSA public key, x the private key, G base point. Sender could reveal P' = cP, c some fixed constant (computing c from cP is ECDL problem considered oneway hard), and a signature by private key x' = cx over the tx-commit. That is a publicly auditable commitment also, but one tht can make an ECDSA signature over the tx-commit hash, and can be revealed by revealing P later. However that imposes public key computation on the validation (which it already currently does, but faster validation as above is nicer). With that one you dont even have to verify the transaction signature on reveal :) You already did it, just provide the tx that hashes to the signed hash, and P for the recipient to verify the signature was made by cP. Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
On Wed, May 15, 2013 at 6:24 PM, Gavin gavinandre...@gmail.com wrote: Busy with pre-conference stuff, not following details of this conversation... ... but it sounds a lot like the guy fawkes protocol Zooko was thinking about a year or so ago. Sort of, but in a guy fawkes signature you use the commitment to hide the preimage that proves you had authority to spend a coin. Adam proposes you do this in order to hide _which coin you're spending_. This has obvious anti-DOS complications, but Adam deftly dodged my initial attempts to shoot him down on these grounds by pointing out that you could mix blinded and blinded inputs and have priority and transaction fees come from only the unblinded ones. Effectively, it means that so long as you could convince the network to let you spend some coins, you could also spend other ones along for the ride and the network wouldn't know which ones those were until it was too late for it to pretend it never saw them. I think there are all kinds of weird economic implications to this— a blinded payment would seem to have a different utility level to an unblinded one: you can't use it for fees— except you can unblind it at any time. And the discontinuousness (two types of inputs) and that it would enable mining gibberish (though perhaps not data storage, if you see my preimage solution to that) seems awkward and I think I have to spend some time internalizing it before I can really think through the implications. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
Conceptually it sounds a lot like ZeroCoin (not in implementation)? I'm not really convinced miner cartels that try to exclude transactions are likely to be a big deal, but such schemes could I suppose be kept in a back pocket in case one day I'm proven wrong. On Wed, May 15, 2013 at 6:39 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, May 15, 2013 at 6:24 PM, Gavin gavinandre...@gmail.com wrote: Busy with pre-conference stuff, not following details of this conversation... ... but it sounds a lot like the guy fawkes protocol Zooko was thinking about a year or so ago. Sort of, but in a guy fawkes signature you use the commitment to hide the preimage that proves you had authority to spend a coin. Adam proposes you do this in order to hide _which coin you're spending_. This has obvious anti-DOS complications, but Adam deftly dodged my initial attempts to shoot him down on these grounds by pointing out that you could mix blinded and blinded inputs and have priority and transaction fees come from only the unblinded ones. Effectively, it means that so long as you could convince the network to let you spend some coins, you could also spend other ones along for the ride and the network wouldn't know which ones those were until it was too late for it to pretend it never saw them. I think there are all kinds of weird economic implications to this— a blinded payment would seem to have a different utility level to an unblinded one: you can't use it for fees— except you can unblind it at any time. And the discontinuousness (two types of inputs) and that it would enable mining gibberish (though perhaps not data storage, if you see my preimage solution to that) seems awkward and I think I have to spend some time internalizing it before I can really think through the implications. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
On Wed, May 15, 2013 at 7:22 PM, Mike Hearn m...@plan99.net wrote: Conceptually it sounds a lot like ZeroCoin (not in implementation)? Zerocoin conceals the connection from everyone forever, assuming the underlying trapdoor problem is computational infeasible, but at great cost. Adamcoin, depending on how its done, at most conceals the transactions from people who aren't a party to them... though as time goes on eventually everyone becomes a party to a sufficiently old coin, and avoiding publication creates quadratic costs in evaluating a private clique's claims so instead an implementation would make the identities public but only once they're burred a bit. Perhaps an extreme version of the idea is easier to understand. Ignore DOS attacks for a moment and pretend there is never any address reuse: Everyone creates txouts paying a P2SH addresses that have a OP_PUSH nonce in them and tell you recipient the nonce out of band. When the recipients spend those coins they provide the script but not the nonce. The recipient knows what coins he's spending, but the public does not. The public can tell there is no double spend though, because they'd see the same script twice. The person he's paying may be skeptical that he actually has any coin and didn't just mine some gibberish, but our spender tells that their receiver the nonce, and that person can see the coin available for spending in the chain and also see that there are no double spends. This could actually go on forever with no ambiguity over who owns what, but the out of band proofs that you have to give people when you spend coins would grow with the history of the coins. Since there wouldn't be much privacy once a transaction was sufficiently split up in any case, you instead just publish the unblindings once transactions are sufficiently buried. Thus bounding the growth of the proofs. The reason I say I need to internalize this more is mostly that I need to think about attacks on the publication for 'tained' transactions being more or less isomorphic to just refusing to allow spending of the 'tainted' coins in any case. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
Not only does the size of the proof grow endlessly as the coin is passed around, the size of the UTXO set grows endlessly as more and more of the already spent coins cannot be proven to have been spent because the proofs are passed out-of-band. I never said the idea was good, just interesting :) Thanks, Caleb On 05/15/2013 10:45 PM, Gregory Maxwell wrote: On Wed, May 15, 2013 at 7:22 PM, Mike Hearn m...@plan99.net wrote: Conceptually it sounds a lot like ZeroCoin (not in implementation)? Zerocoin conceals the connection from everyone forever, assuming the underlying trapdoor problem is computational infeasible, but at great cost. Adamcoin, depending on how its done, at most conceals the transactions from people who aren't a party to them... though as time goes on eventually everyone becomes a party to a sufficiently old coin, and avoiding publication creates quadratic costs in evaluating a private clique's claims so instead an implementation would make the identities public but only once they're burred a bit. Perhaps an extreme version of the idea is easier to understand. Ignore DOS attacks for a moment and pretend there is never any address reuse: Everyone creates txouts paying a P2SH addresses that have a OP_PUSH nonce in them and tell you recipient the nonce out of band. When the recipients spend those coins they provide the script but not the nonce. The recipient knows what coins he's spending, but the public does not. The public can tell there is no double spend though, because they'd see the same script twice. The person he's paying may be skeptical that he actually has any coin and didn't just mine some gibberish, but our spender tells that their receiver the nonce, and that person can see the coin available for spending in the chain and also see that there are no double spends. This could actually go on forever with no ambiguity over who owns what, but the out of band proofs that you have to give people when you spend coins would grow with the history of the coins. Since there wouldn't be much privacy once a transaction was sufficiently split up in any case, you instead just publish the unblindings once transactions are sufficiently buried. Thus bounding the growth of the proofs. The reason I say I need to internalize this more is mostly that I need to think about attacks on the publication for 'tained' transactions being more or less isomorphic to just refusing to allow spending of the 'tainted' coins in any case. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
