* [Bitcoin-development] Trusted identities @ 2012-04-26 15:49 Peter Todd 2012-04-26 17:11 ` Peter Vessenes 0 siblings, 1 reply; 5+ messages in thread From: Peter Todd @ 2012-04-26 15:49 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3043 bytes --] It recently occured to me that we can use the public nature of the block chain to create trusted identities, for a specific form of trust. Lets suppose Alice has some bitcoins held at bitcoin address A. She wants to establish trust in the "identity" associated with the ECC keypair associated with A, for instance for the purpose of having other users trust her not to attempt to double spend. Since the trust she seeks is financial in nature, she can do this by valuing the identity associated with A, by delibrately throwing away resources. A simple way to do this would of course be to transfer coins to a null address, provably incurring a cost to her. A more socially responsible way would be for her to create a series of transactions that happen to have large, and equal, transaction fees. Bitcoin makes the assumption that no one entity controls more than 50% of the network, so if she makes n of these transactions consecutively, each spending m BTC to transaction fees, there is a high probability that she has given up at least n/2 * m BTC of value. This of course is all public knowledge, recorded in the block chain. It also increases the transaction fees for miners, which will be very important for the network in the future. Now Bob can easily examine the block chain, and upon verifying Alice's trust purchase, can decide to accept a zero-confirmation transaction at face value. If Alice breaks that promise, he simply publishes her signed transaction proving that Alice is a fraudster, and future Bob's will distrust Alice's trusted identity, thus destroying the value needed to create it. In effect, we now have a distributed green address system. Now Alice could try to mount a double-spend attack on a whole bunch of people at once, hoping to have them all accept the transaction. However as it is the "just trust them" model works pretty well already. A good usecase for this idea, beyond the obvious fast payments application, is a distributed anonymizer. Alice can now publish her request to anonymize coins, and other trusted identities can make their bids. If Alice accepts a bid from Bob, she will want Bob to send her the anonymized coins *prior* to her transaction going through, thus breaking the temporal connection between the transactions. Now Alice can give Bob the signed payment transaction, and Bob can submit his payment transaction to the network first, knowing that Alice isn't going to try to rip him off. Bob can also have a trusted identity which signed the contract for the anonymizer transaction, and similarly if he rips Alice off, she can publish it for the world to see. A more subtle effect, is this makes sybil attacks more difficult. To pretend to be a thousand identities is going to now require 1,000 * n coins, and attempting to pull this attack off inherently strengthens the bitcoin network. Obviously we can apply this principle to other things like tor nodes as well. -- http://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Trusted identities 2012-04-26 15:49 [Bitcoin-development] Trusted identities Peter Todd @ 2012-04-26 17:11 ` Peter Vessenes 2012-04-26 17:30 ` Peter Todd 2012-04-26 17:59 ` Amir Taaki 0 siblings, 2 replies; 5+ messages in thread From: Peter Vessenes @ 2012-04-26 17:11 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 5140 bytes --] These are interesting thoughts, karma for bitcoins essentially. I would like CoinLab to publish a 'cost of subverting 1-n transactions with 90% probability' metric soon, and I think it would help everyone to understand what that number is. When we started out, you probably needed to wait 5 blocks for $10 or $20 of bitcoin value transfer. Now, I'd happily accept a $1k transaction with 1 confirmation. More difficulty shortens the safe time we can transact large volumes in, which is good for the network. I'm not sure of the current implementation of replacement transactions, can anyone on the core team speak to this? Can I replace transactions, or is that part of the spec unimplemented or deprecated right now? Peter On Thu, Apr 26, 2012 at 8:49 AM, Peter Todd <pete@petertodd.org> wrote: > It recently occured to me that we can use the public nature of the block > chain to create trusted identities, for a specific form of trust. > > Lets suppose Alice has some bitcoins held at bitcoin address A. She > wants to establish trust in the "identity" associated with the ECC > keypair associated with A, for instance for the purpose of having other > users trust her not to attempt to double spend. Since the trust she > seeks is financial in nature, she can do this by valuing the identity > associated with A, by delibrately throwing away resources. A simple way > to do this would of course be to transfer coins to a null address, > provably incurring a cost to her. > > A more socially responsible way would be for her to create a series of > transactions that happen to have large, and equal, transaction fees. > Bitcoin makes the assumption that no one entity controls more than 50% > of the network, so if she makes n of these transactions consecutively, > each spending m BTC to transaction fees, there is a high probability > that she has given up at least n/2 * m BTC of value. This of course is > all public knowledge, recorded in the block chain. It also increases the > transaction fees for miners, which will be very important for the > network in the future. > > Now Bob can easily examine the block chain, and upon verifying Alice's > trust purchase, can decide to accept a zero-confirmation transaction at > face value. If Alice breaks that promise, he simply publishes her signed > transaction proving that Alice is a fraudster, and future Bob's will > distrust Alice's trusted identity, thus destroying the value needed to > create it. > > In effect, we now have a distributed green address system. > > Now Alice could try to mount a double-spend attack on a whole bunch of > people at once, hoping to have them all accept the transaction. However > as it is the "just trust them" model works pretty well already. > > > A good usecase for this idea, beyond the obvious fast payments > application, is a distributed anonymizer. Alice can now publish her > request to anonymize coins, and other trusted identities can make their > bids. If Alice accepts a bid from Bob, she will want Bob to send her the > anonymized coins *prior* to her transaction going through, thus breaking > the temporal connection between the transactions. Now Alice can give Bob > the signed payment transaction, and Bob can submit his payment > transaction to the network first, knowing that Alice isn't going to try > to rip him off. Bob can also have a trusted identity which signed the > contract for the anonymizer transaction, and similarly if he rips Alice > off, she can publish it for the world to see. > > A more subtle effect, is this makes sybil attacks more difficult. To > pretend to be a thousand identities is going to now require 1,000 * n > coins, and attempting to pull this attack off inherently strengthens the > bitcoin network. Obviously we can apply this principle to other things > like tor nodes as well. > > -- > http://petertodd.org 'peter'[:-1]@petertodd.org > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJPmW6EAAoJEH+rEUJn5PoEZfEH/ixptlMX9MzP71bCHMkj7YN1 > y6GEkc1vNhyHu01NX77vzSqR4trbVnWJeJ5hH8EB5tgYRwmI17XoQW6Iz8yEXXgO > JqUKCTBBexGE+F5RfBkizJ9ap5wXwVrAOIMy/KurSdST+PWMXIPQFaGark01uKcG > M4VXg3U9fc/0Zz1QyKpRTI5O7ZSBqPzEh/Xf4TujR39nUtaI5mkT/bmA3+Te7oRT > 34QO7ryF7U001Xz2VJCfm9AE8mPPZjMavLTs/XvPSqTdliVCZpjGGHzcJ2BPrni5 > LEPBsBBxNsuwFGjnRobQwrkPtmYGFntseMLzCJ3iGXWYwedssBg2LLOx9QaXG04= > =PftQ > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 Skype: vessenes Google+ <https://plus.google.com/112885659993091300749> [-- Attachment #2: Type: text/html, Size: 6949 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Trusted identities 2012-04-26 17:11 ` Peter Vessenes @ 2012-04-26 17:30 ` Peter Todd 2012-04-26 18:00 ` Alan Reiner 2012-04-26 17:59 ` Amir Taaki 1 sibling, 1 reply; 5+ messages in thread From: Peter Todd @ 2012-04-26 17:30 UTC (permalink / raw) To: Peter Vessenes; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2031 bytes --] On Thu, Apr 26, 2012 at 10:11:51AM -0700, Peter Vessenes wrote: > These are interesting thoughts, karma for bitcoins essentially. > > I would like CoinLab to publish a 'cost of subverting 1-n transactions with > 90% probability' metric soon, and I think it would help everyone to > understand what that number is. There's gotta be a lot of subtlies there. For instance, if I just want to double-spend, the easiest approach would be to first buy a whole bunch of VPS's, each with different /16's for their IP address to defeat that anti-sybil measure. Then figure out what is the set of nodes closest to my target - easier for an active target that makes a lot of transactions. Then it's just a matter of giving them my transaction, and immediately flooding the network faster with my nodes than their single node. It's not block-replacement, but it would be effective against people who accept 0-confirmations. (although as Gavin has pointed out elsewhere, in the future miners may be very happy to replace transactions for more fees in that kind of circumstance) Of course, this whole trusted identities business could be equally used for the bitcoin flood network as a whole to prevent sybil's, and perhaps even get guarantees of behavior like "My node respects nLockTime and won't ignore it for a higher-fee transaction replacement" > When we started out, you probably needed to wait 5 blocks for $10 or $20 of > bitcoin value transfer. > > Now, I'd happily accept a $1k transaction with 1 confirmation. Yup, especially when a human is in the loop. > More difficulty shortens the safe time we can transact large volumes in, > which is good for the network. > > I'm not sure of the current implementation of replacement transactions, can > anyone on the core team speak to this? Can I replace transactions, or is > that part of the spec unimplemented or deprecated right now? My understanding is it's completely disabled. -- http://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Trusted identities 2012-04-26 17:30 ` Peter Todd @ 2012-04-26 18:00 ` Alan Reiner 0 siblings, 0 replies; 5+ messages in thread From: Alan Reiner @ 2012-04-26 18:00 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1470 bytes --] On 04/26/2012 01:30 PM, Peter Todd wrote: > >> More difficulty shortens the safe time we can transact large volumes in, >> which is good for the network. >> >> I'm not sure of the current implementation of replacement transactions, can >> anyone on the core team speak to this? Can I replace transactions, or is >> that part of the spec unimplemented or deprecated right now? > My understanding is it's completely disabled. Went on a scavenger hunt with Gavin a couple weeks concerning tx replacement. The conclusion was that if, (1) Transaction has lock-time in the future AND (2) Transaction has non-maximum sequence number Then the transaction will both propagate and be accepted into nodes' memory pools, but will not go into any block until locktime expires. If the lock-time is in the past OR sequence number on all TxIns is 0xffffffff, then it will be immediately valid and included in the blockchain. But the actual "replacement" mechanism is disabled. Therefore, the nodes accept the tx as if it's replaceable, but don't allow it to be replaced. This means that it is effectively replaceable *once*, but only if you inject a final transaction into the blockchain. You can't broadcast a final version of the same tx, because it will conflict with the non-final one sitting in all the other nodes' memory pools. You need a miner to agree to remove the non-final tx from their memory pool and specifically include your replacement. -Alan [-- Attachment #2: Type: text/html, Size: 2059 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Trusted identities 2012-04-26 17:11 ` Peter Vessenes 2012-04-26 17:30 ` Peter Todd @ 2012-04-26 17:59 ` Amir Taaki 1 sibling, 0 replies; 5+ messages in thread From: Amir Taaki @ 2012-04-26 17:59 UTC (permalink / raw) To: bitcoin-development look at the first line of the if statement // Check for conflicts with in-memory transactions CTransaction* ptxOld = NULL; for (unsigned int i = 0; i < tx.vin.size(); i++) { COutPoint outpoint = tx.vin[i].prevout; if (mapNextTx.count(outpoint)) { // Disable replacement feature for now return false; // Allow replacing with a newer version of the same transaction if (i != 0) return false; ptxOld = mapNextTx[outpoint].ptx; if (ptxOld->IsFinal()) return false; if (!tx.IsNewerThan(*ptxOld)) return false; for (unsigned int i = 0; i < tx.vin.size(); i++) { COutPoint outpoint = tx.vin[i].prevout; if (!mapNextTx.count(outpoint) || mapNextTx[outpoint].ptx != ptxOld) return false; } break; } } ________________________________ From: Peter Vessenes <peter@coinlab.com> To: Peter Todd <pete@petertodd.org> Cc: bitcoin-development@lists.sourceforge.net Sent: Thursday, April 26, 2012 6:11 PM Subject: Re: [Bitcoin-development] Trusted identities These are interesting thoughts, karma for bitcoins essentially. I would like CoinLab to publish a 'cost of subverting 1-n transactions with 90% probability' metric soon, and I think it would help everyone to understand what that number is. When we started out, you probably needed to wait 5 blocks for $10 or $20 of bitcoin value transfer. Now, I'd happily accept a $1k transaction with 1 confirmation. More difficulty shortens the safe time we can transact large volumes in, which is good for the network. I'm not sure of the current implementation of replacement transactions, can anyone on the core team speak to this? Can I replace transactions, or is that part of the spec unimplemented or deprecated right now? Peter On Thu, Apr 26, 2012 at 8:49 AM, Peter Todd <pete@petertodd.org> wrote: It recently occured to me that we can use the public nature of the block >chain to create trusted identities, for a specific form of trust. > >Lets suppose Alice has some bitcoins held at bitcoin address A. She >wants to establish trust in the "identity" associated with the ECC >keypair associated with A, for instance for the purpose of having other >users trust her not to attempt to double spend. Since the trust she >seeks is financial in nature, she can do this by valuing the identity >associated with A, by delibrately throwing away resources. A simple way >to do this would of course be to transfer coins to a null address, >provably incurring a cost to her. > >A more socially responsible way would be for her to create a series of >transactions that happen to have large, and equal, transaction fees. >Bitcoin makes the assumption that no one entity controls more than 50% >of the network, so if she makes n of these transactions consecutively, >each spending m BTC to transaction fees, there is a high probability >that she has given up at least n/2 * m BTC of value. This of course is >all public knowledge, recorded in the block chain. It also increases the >transaction fees for miners, which will be very important for the >network in the future. > >Now Bob can easily examine the block chain, and upon verifying Alice's >trust purchase, can decide to accept a zero-confirmation transaction at >face value. If Alice breaks that promise, he simply publishes her signed >transaction proving that Alice is a fraudster, and future Bob's will >distrust Alice's trusted identity, thus destroying the value needed to >create it. > >In effect, we now have a distributed green address system. > >Now Alice could try to mount a double-spend attack on a whole bunch of >people at once, hoping to have them all accept the transaction. However >as it is the "just trust them" model works pretty well already. > > >A good usecase for this idea, beyond the obvious fast payments >application, is a distributed anonymizer. Alice can now publish her >request to anonymize coins, and other trusted identities can make their >bids. If Alice accepts a bid from Bob, she will want Bob to send her the >anonymized coins *prior* to her transaction going through, thus breaking >the temporal connection between the transactions. Now Alice can give Bob >the signed payment transaction, and Bob can submit his payment >transaction to the network first, knowing that Alice isn't going to try >to rip him off. Bob can also have a trusted identity which signed the >contract for the anonymizer transaction, and similarly if he rips Alice >off, she can publish it for the world to see. > >A more subtle effect, is this makes sybil attacks more difficult. To >pretend to be a thousand identities is going to now require 1,000 * n >coins, and attempting to pull this attack off inherently strengthens the >bitcoin network. Obviously we can apply this principle to other things >like tor nodes as well. > >-- >http://petertodd.org 'peter'[:-1]@petertodd.org > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.10 (GNU/Linux) > >iQEcBAEBAgAGBQJPmW6EAAoJEH+rEUJn5PoEZfEH/ixptlMX9MzP71bCHMkj7YN1 >y6GEkc1vNhyHu01NX77vzSqR4trbVnWJeJ5hH8EB5tgYRwmI17XoQW6Iz8yEXXgO >JqUKCTBBexGE+F5RfBkizJ9ap5wXwVrAOIMy/KurSdST+PWMXIPQFaGark01uKcG >M4VXg3U9fc/0Zz1QyKpRTI5O7ZSBqPzEh/Xf4TujR39nUtaI5mkT/bmA3+Te7oRT >34QO7ryF7U001Xz2VJCfm9AE8mPPZjMavLTs/XvPSqTdliVCZpjGGHzcJ2BPrni5 >LEPBsBBxNsuwFGjnRobQwrkPtmYGFntseMLzCJ3iGXWYwedssBg2LLOx9QaXG04= >=PftQ >-----END PGP SIGNATURE----- > >------------------------------------------------------------------------------ >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security and >threat landscape has changed and how IT managers can respond. Discussions >will include endpoint security, mobile security and the latest in malware >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 Skype: vessenes Google+ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-04-26 18:01 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-26 15:49 [Bitcoin-development] Trusted identities Peter Todd 2012-04-26 17:11 ` Peter Vessenes 2012-04-26 17:30 ` Peter Todd 2012-04-26 18:00 ` Alan Reiner 2012-04-26 17:59 ` Amir Taaki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox