* [Bitcoin-development] Blockchain as root CA for payment protocol @ 2013-02-08 10:03 Timo Hanke 2013-02-08 11:01 ` Peter Todd 2013-02-11 19:39 ` Rick Wesson 0 siblings, 2 replies; 8+ messages in thread From: Timo Hanke @ 2013-02-08 10:03 UTC (permalink / raw) To: bitcoin-development There have been proposals to use the blockchain to establish "identities". firstbits is a simple example. I would like to announce a project that extends this idea to turn the blockchain into a "root CA" that can sign arbitrary certificates. The purpose is to use these certificates in the payment protocol, where some might consider traditional centralized root CAs unsatisfactory. Code is here: https://github.com/bcpki Technical specification and full-length examples are found in the wiki. I therefore spare myself from repeating the details here, even though, of course, discussion about those details is welcome on this list. Excerpt from README.md follows: First, we have drafted a quite general specification for bitcoin certificates (protobuf messages) that allow for a variety of payment protocols (e.g. static as well as customer-side-generated payment addresses). This part has surely been done elsewhere as well and is orthogonal to the goal of this project. What is new here is the signatures _under_ the certificates. We have patched the bitcoind to handle certificates, submit signatures to the blockchain, verify certificates against the blockchain, pay directly to certificates (with various payment methods), revoke certificates. Signatures in the blockchain are stored entirely in the UTXO set (i.e. the unspend, unprunable outputs). This seems to make signature lookup and verification reasonably fast: it took us 10s in the mainnet test we performed (lookup is instant on the testnet, of course). Payment methods include: static bitcoin addresses, client-side derived payment addresses (pay-to-contract), pay-to-contract with multisig destinations (P2SH) Full-length real-world examples for all payment methods are provided in the tutorial pages. These examples have actually been carried out on testnet3. For further details and specifications see the wiki. timo hanke ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Blockchain as root CA for payment protocol 2013-02-08 10:03 [Bitcoin-development] Blockchain as root CA for payment protocol Timo Hanke @ 2013-02-08 11:01 ` Peter Todd 2013-02-09 14:33 ` Timo Hanke 2013-02-11 19:39 ` Rick Wesson 1 sibling, 1 reply; 8+ messages in thread From: Peter Todd @ 2013-02-08 11:01 UTC (permalink / raw) To: Timo Hanke; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3127 bytes --] On Fri, Feb 08, 2013 at 11:03:54AM +0100, Timo Hanke wrote: > First, we have drafted a quite general specification for bitcoin certificates (protobuf messages) that allow for a variety of payment protocols (e.g. static as well as customer-side-generated payment addresses). > This part has surely been done elsewhere as well and is orthogonal to the goal of this project. > What is new here is the signatures _under_ the certificates. > > We have patched the bitcoind to handle certificates, submit signatures to the blockchain, verify certificates against the blockchain, pay directly to certificates (with various payment methods), revoke certificates. > Signatures in the blockchain are stored entirely in the UTXO set (i.e. the unspend, unprunable outputs). > This seems to make signature lookup and verification reasonably fast: > it took us 10s in the mainnet test we performed (lookup is instant on the testnet, of course). Why don't you use namecoin or another alt-chain for this? The UTXO set is the most expensive part of the blockchain because it must be stored in memory with fast access times. It's good that you have designed the system so that the addresses can be revoked, removing them from the UTXO set, but it still will encourage the exact same type of ugly squatting behavior we've already seen with first-bits, and again it'll have a significant cost to the network going forward for purposes that do not need to be done on the block chain. In https://github.com/bcpki/bitcoin/wiki/Technical you say that you have a minimum amount required for an outpoint to be valid, set at 0.05BTC. That's a nice touch, and sort of works because this is a consensus protocol, but if the exchange rate climbs significantly there will be a lot of pressure to reduce that value. (setting minimum value by chain height) What will happen then is there will be a mad rush to squat on previously unaffordable domains, further disrupting Bitcoin's purpose as a financial network. In addition you'll also have a second problem: squatting of subsequent transactions, particularly for valuable bcvalues. Basically if someone already has "microsoft" insert bcvalues after their tx in case they accidentally spend it. Of course, this will be done by people buying bcvalues as well. Again, all this further clogs up the UTXO set. I also can't figure out why you say signature lookup and verification takes 10s - this should be an O(1) operation if you maintain a mapping of candidate pubkeys to linked-lists of sorted applicable transactions. Finally, why is this implemented within the reference client? Use the raw transaction API and make up your own database. If you want, create a RPC command that allows you to query the UTXO set directly; this would be a useful feature to have. This patch will never be accepted to the reference client, so you'll just wind up having to maintain a fork. Even for a prototype this approach is ill-advised - prototypes have a bad way of turning into production code. In short, please don't do this. -- 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Blockchain as root CA for payment protocol 2013-02-08 11:01 ` Peter Todd @ 2013-02-09 14:33 ` Timo Hanke 2013-02-09 19:01 ` Luke-Jr 2013-02-11 11:21 ` Peter Todd 0 siblings, 2 replies; 8+ messages in thread From: Timo Hanke @ 2013-02-09 14:33 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-development On Fri, Feb 08, 2013 at 06:01:08AM -0500, Peter Todd wrote: > On Fri, Feb 08, 2013 at 11:03:54AM +0100, Timo Hanke wrote: > > First, we have drafted a quite general specification for bitcoin certificates (protobuf messages) that allow for a variety of payment protocols (e.g. static as well as customer-side-generated payment addresses). > > This part has surely been done elsewhere as well and is orthogonal to the goal of this project. > > What is new here is the signatures _under_ the certificates. > > > > We have patched the bitcoind to handle certificates, submit signatures to the blockchain, verify certificates against the blockchain, pay directly to certificates (with various payment methods), revoke certificates. > > Signatures in the blockchain are stored entirely in the UTXO set (i.e. the unspend, unprunable outputs). > > This seems to make signature lookup and verification reasonably fast: > > it took us 10s in the mainnet test we performed (lookup is instant on the testnet, of course). > > Why don't you use namecoin or another alt-chain for this? Because namcoin tries to solve a different problem, DNS, whereas I want to establish an identity for a payment protocol. Your incoming payments will land on addresses that are derived (regardless which way) from this idenity. This makes your identity as important (securitywise) as anything else involved in the bitcoin protocol. Therefore I would not want to have payment-ids rely on anything _less_ than bitcoin's own blockchain. In particular not on PKI with centralized root CAs. But also not on namecoin or any other (weaker) alt-chains. You can argue that alt-chains _can_ be as strong as bitcoin, but they don't _have to_ be. There is no guarantee how many people will cross-mine. The alt-chain could even disappear at some point. If at some point your alt-chain is no longer being worked on, then how do you prove that some old bitcoin transaction went to an address for which there was a valid id/certificate at the time of sending? If the certificate is based inside bitcoin's blockchain then you will have a proof for the correct destinations of all your old transactions as long as bitcoin exists. Besides all this, as you mentioned namecoin specifically, that is overkill if you just want to link two hashes together. A single 2-of-2 multisig output would suffice for that. > The UTXO set is the most expensive part of the blockchain because it > must be stored in memory with fast access times. It's good that you have > designed the system so that the addresses can be revoked, removing them > from the UTXO set, but it still will encourage the exact same type of > ugly squatting behavior we've already seen with first-bits, and again > it'll have a significant cost to the network going forward for purposes > that do not need to be done on the block chain. You are probably right that storing this in the _spent outputs_ would be better. There doesn't seem to be any type of client out there that would benefit from having to search UTXO only. Timo ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Blockchain as root CA for payment protocol 2013-02-09 14:33 ` Timo Hanke @ 2013-02-09 19:01 ` Luke-Jr 2013-02-11 19:12 ` Timo Hanke 2013-02-11 11:21 ` Peter Todd 1 sibling, 1 reply; 8+ messages in thread From: Luke-Jr @ 2013-02-09 19:01 UTC (permalink / raw) To: bitcoin-development, timo.hanke On Saturday, February 09, 2013 2:33:25 PM Timo Hanke wrote: > > Why don't you use namecoin or another alt-chain for this? > > Because namcoin tries to solve a different problem, DNS, whereas I want > to establish an identity for a payment protocol. What is the technical difference here? Namecoin ties names to data; DNS is a specific namespace in it. There is no reason I know of that this identity stuff cannot be a new namespace. > You can argue that alt-chains _can_ be as strong as bitcoin, but they > don't _have to_ be. There is no guarantee how many people will > cross-mine. This is true of namecoin, but it does not have to be true of new merged-mined data. You could very well require the Bitcoin proof-of-work to be valid and the master header to be in the Bitcoin blockchain. > The alt-chain could even disappear at some point. If at some point your alt- > chain is no longer being worked on, then how do you prove that some old > bitcoin transaction went to an address for which there was a valid > id/certificate at the time of sending? If the certificate is based inside > bitcoin's blockchain then you will have a proof for the correct destinations > of all your old transactions as long as bitcoin exists. Yes, if people stop using your system, it won't work. Consider that a "this idea failed" scenario, where it doesn't matter. Luke ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Blockchain as root CA for payment protocol 2013-02-09 19:01 ` Luke-Jr @ 2013-02-11 19:12 ` Timo Hanke 2013-02-11 19:21 ` Gregory Maxwell 0 siblings, 1 reply; 8+ messages in thread From: Timo Hanke @ 2013-02-11 19:12 UTC (permalink / raw) To: Luke-Jr, Peter Todd; +Cc: bitcoin-development On Sat, Feb 09, 2013 at 07:01:48PM +0000, Luke-Jr wrote: > On Saturday, February 09, 2013 2:33:25 PM Timo Hanke wrote: > > namcoin tries to solve a different problem, DNS, whereas I want > > to establish an identity for a payment protocol. > > What is the technical difference here? Namecoin ties names to data; DNS is a > specific namespace in it. There is no reason I know of that this identity > stuff cannot be a new namespace. It's not about technical differences, but about the different use or purpose, which can result in different security demands. I argue that DNS has a lower demand in this respect than payment ids have. So DNS data can be in a chain with a hashrate lower than bitcoin's hashrate but payment ids _for_ bitcoin have to be in a chain with equal hashrate. > > You can argue that alt-chains _can_ be as strong as bitcoin, but they > > don't _have to_ be. There is no guarantee how many people will > > cross-mine. > > This is true of namecoin, but it does not have to be true of new merged-mined > data. You could very well require the Bitcoin proof-of-work to be valid and > the master header to be in the Bitcoin blockchain. Ok, true. This does the trick. If few miners merge-mine then the new chain just becomes slower. But is this still an alt-chain? It is not independently verifiable anymore, like the alt-chains described in the wiki are. Instead, you need to refer to the bitcoin's chain to see if the target is correct. Not sure if I got you right on this. But it seems to be essentially a more efficient version of what I proposed, rather than a true alt-chain. I suppose you suggest to place the master header hash into the coinbase. A drawback may be that it puts miners at a great advantage over regular users. This could (but doesn't have to) become relevant depending on your counter-measures against excessive alias registration. I think Peter addressed this (below). On Fri, Feb 08, 2013 at 06:01:08AM -0500, Peter Todd wrote: > Finally, why is this implemented within the reference client? Use the > raw transaction API and make up your own database. If you want, create a > RPC command that allows you to query the UTXO set directly; this would > be a useful feature to have. This patch will never be accepted to the > reference client, so you'll just wind up having to maintain a fork. Even > for a prototype this approach is ill-advised - prototypes have a bad way > of turning into production code. This was not intended to be a prototype and will certainly not be maintained. It is a demo to be run on the testnet to get a feel of how the user interface (RPC) and the "work flow" could look like, starting from the creation of a certificate all the way to paying to a customer-derived payment addresses (pay-to-contract) when the merchant's base address is defined in the certificate. There's an appeal to be able to issue ./bitcoind sendtoalias foo deadbeef 10 and being sure that 10 BTC go, e.g., to a unique P2SH multisig address that is derived for order number 'deadbeef' from the two pubkeys that foo defined in his certificate. And having the certificate verification happen automatically in the background. The demo is in the reference client a) to simulate this feel, b) because it was the fastest way to code it. Apart from that, it could have just as well been separate, and an UTXO query-RPC would certainly be nice. Another reason for this demo was the fun of devising a certificate that can handle all this. BTW, I'm sure that some form of certificate handling will find its way directly into the reference client. The user will want to trust only one piece of software running on one piece of dedicated hardware. On Mon, Feb 11, 2013 at 06:21:03AM -0500, Peter Todd wrote: > In what way are you not solving the same problem as DNS? I don't mean > the Luke-Jr's (quite correct) technical point about key-value maps, I > mean the human problem that I have these unique numbers that I can't > memorize, and I have some non-unique names that I can. > > By creating Yet Another Totally Different System you are just creating > another way that users can be confused into thinking some name snatched > up by some scammers in some little-used PKI system is who they are > supposed to be communicating with. Fortunately your PKI system isn't > actually used and probably never will be, so it's not a big deal yet, > but ultimately you are adding to the problem. What exactly is the problem, the "little-used"? Otherwise it's the same as it is now, you pick up an interesting domain name on the street, type it in, and start communicating with who you think it is, and maybe even pay them. The EV that centralized PKI offers prevents only some attacks, and may even create a false sense of security. > Go work on namecoin and make it more usable. Then add some PKI to it > using the *same* domain names so when I see a PKI certificate for "foo" > I know it must be the same "foo" website I just visited and the same > "foo@foo" I just emailed. No. I outlined above why I think namecoin is unsuitable (but Luke's suggestion for a new alt-chain may be). BTW, if you want to link aliases of some "bitcoin PKI" and "domain names", they should not correspond bijectively to each other. The "bitcoin alias" corresponds to a payment base address, which I see as a more universal identifier than a domain name. First, bitcoin alias foo can have several domains foo.com, foo.co.uk, etc. but still only one "bitcoin certificate". This can be achieved by either writing the domain names directly into the certificate, or better, by having the "bitcoin certificate" sign an SSL sub-certificate and tell your browser to ask bitcoind to verify it. Second, a bitcoin alias can be meaningful without any domain names, e.g. it can be a certificate for all vending machines of a certain seller, with who you interact directly, say NFC. To summarize, I would either not link bitcoin aliases with domain names, or put SSL certificates "below" bitcoin certificates in the verification chain. Also BTW, it is the beauty of the pay-to-contract principle that authenticated communication is not even required. This means that if you know you have the correct "bitcoin certificate" stored with your bitcoind and you pay to it, then it doesn't matter if you ordered on a wrong or fake website. The worst-case scenario is that you have to call in via another channel and re-submit your order, but funds are never lost. > Alt-chains don't have to be based on mining you know. Your proof-of-work > can be replaced by proof-of-sacrifice, specifically Bitcoins. > [...] > 1) https://github.com/petertodd/trustbits/blob/master/fidelitybond.md Yes, I already read your discussing of sacrifice-methods after your first reply and found it interesting.. The problem I see is to dynamically (and automatically) adjust the minimum sacrifice amount. A strict limit on the number of registrations like namecoin has is not desirable. A constant sacrifice, as you mentioned earlier, is also undesirable. A good measure could be the average transaction fee taken over several blocks. Maybe the minimum sacrifice should be a constant times that. > > You are probably right that storing this in the _spent outputs_ > > would be better [than UTXO]. There doesn't seem to be any type of > > client out there that would benefit from having to search UTXO only. > > The blockchain grows at a maximum rate of 55GiB/year. Do you think your > users will all want to have that available just to validate some PKI > certificates? Actually yes. They are also willing to do that to verify their payments, so why not for the certificate? But true, this was the reason why I thought of putting it in the UTXO. To enable some future dedicated "hardware wallet" to keep only the UTXO and to verify against it. Where would you store you alt-chain block header hashes? UTXO? BTW, suppose you avoid any squatting (there would certainly be ways to do that). Then with my original proposal of one transaction per registration you would grow the UTXO by O(n), n is the number of users. Each user would create a small constant number of aliases. This number will certainly be dwarfed by the number of unspend outputs that each user keeps anyway as a result of their regular transactions. So it would not present a problem for the UTXO. Actually, anything above the dust threshold should not be a problem, or the system is misdesigned. But of course the alt-chain header hashes would only take O(1), much better. Timo ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Blockchain as root CA for payment protocol 2013-02-11 19:12 ` Timo Hanke @ 2013-02-11 19:21 ` Gregory Maxwell 0 siblings, 0 replies; 8+ messages in thread From: Gregory Maxwell @ 2013-02-11 19:21 UTC (permalink / raw) To: timo.hanke; +Cc: bitcoin-development On Mon, Feb 11, 2013 at 11:12 AM, Timo Hanke <timo.hanke@web•de> wrote: > It's not about technical differences, but about the different use or > purpose, which can result in different security demands. I argue that > DNS has a lower demand in this respect than payment ids have. So DNS > data can be in a chain with a hashrate lower than bitcoin's hashrate but > payment ids _for_ bitcoin have to be in a chain with equal hashrate. It seems you're not very well informed about what namecoin does— it's a multiple namespace key-value store. And, as Peter pointed out— a non-parasitic system can have exactly the same POW hashpower. Namecoin chose a model which made it so that namecoin could survive even if Bitcoin failed, but you don't have to. I strongly recommend you listen to Peter and Luke— externalizing the costs of your services onto people who do not care about them is not going to produce good results for anyone. It's possible to accomplish what you want to accomplish without taking resources from the users of the Bitcoin currency without their consent— and you have people here who are willing to help you figure out how. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Blockchain as root CA for payment protocol 2013-02-09 14:33 ` Timo Hanke 2013-02-09 19:01 ` Luke-Jr @ 2013-02-11 11:21 ` Peter Todd 1 sibling, 0 replies; 8+ messages in thread From: Peter Todd @ 2013-02-11 11:21 UTC (permalink / raw) To: Timo Hanke; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 6274 bytes --] On Sat, Feb 09, 2013 at 03:33:25PM +0100, Timo Hanke wrote: > > Why don't you use namecoin or another alt-chain for this? > > Because namcoin tries to solve a different problem, DNS, whereas I want > to establish an identity for a payment protocol. Your incoming payments > will land on addresses that are derived (regardless which way) from this > idenity. This makes your identity as important (securitywise) as > anything else involved in the bitcoin protocol. Therefore I would not > want to have payment-ids rely on anything _less_ than bitcoin's own > blockchain. In particular not on PKI with centralized root CAs. But also > not on namecoin or any other (weaker) alt-chains. In what way are you not solving the same problem as DNS? I don't mean the Luke-Jr's (quite correct) technical point about key-value maps, I mean the human problem that I have these unique numbers that I can't memorize, and I have some non-unique names that I can. By creating Yet Another Totally Different System you are just creating another way that users can be confused into thinking some name snatched up by some scammers in some little-used PKI system is who they are supposed to be communicating with. Fortunately your PKI system isn't actually used and probably never will be, so it's not a big deal yet, but ultimately you are adding to the problem. Go work on namecoin and make it more usable. Then add some PKI to it using the *same* domain names so when I see a PKI certificate for "foo" I know it must be the same "foo" website I just visited and the same "foo@foo" I just emailed. > You can argue that alt-chains _can_ be as strong as bitcoin, but they > don't _have to_ be. There is no guarantee how many people will > cross-mine. The alt-chain could even disappear at some point. If at some > point your alt-chain is no longer being worked on, then how do you prove > that some old bitcoin transaction went to an address for which there was > a valid id/certificate at the time of sending? If the certificate is > based inside bitcoin's blockchain then you will have a proof for the > correct destinations of all your old transactions as long as bitcoin > exists. Alt-chains don't have to be based on mining you know. Your proof-of-work can be replaced by proof-of-sacrifice, specifically Bitcoins. A particularly nice scheme is to use transaction fees and Bitcoin block height. Specifically every block in your alt-chain will have a merkle path to a transaction in a Bitcoin block. Of course there can be more than one such block, so you introduce a tie-breaker rule: the transaction with the highest mining fee wins. The reason why this is nice is because it becomes really easy to be sure that a better chain won't turn up after the fact - make sure the transaction linking the alt-chain to the Bitcoin block has the highest fee in the block. Thus if you want to, say, register a domain name, do so in the alt-chain, then "mine" the block by creating a suitable transaction. Make sure it's the biggest fee, wait a few confirmations, and you're good to go with the same level of security as Bitcoin proper. Because the rule is that a merkle *path* exists, multiple alt-chains can use this mechanism at the same time, with the exact same security guarantee re: max fees. (note that you're chain needs to store copies of the txin's for the tx sacrificing the fee, transactions by themselves do not prove fees) Multiple parties can also colaborate to create the transaction, each providing, and signing for, an input for their portion of the total fee. There is the problem that miners get to keep the fee, thus they can create these special proof-of-sacrifice transactions at low cost, and potentially make it difficult to get a block mined, or to be sure a block won't be undone later. This problem can be solved with my "two-step sacrifice" protocol.(1) Essentially you create a transaction that is invalid until some time in the future and sacrifices Bitcoins to mining fees, then create a second transaction that includes the first one as data. You publish the second in the block chain, proving the whole world had an opportunity to mine it. Eventually the first is in fact mined, thus sacrificing Bitcoins to a miner you have no control over. For a alt-chain you would consider the sacrifice to be a "balance" and then spend that balance as required in later blocks in a way that is guaranteed to be public so you can still check the security guarantee of knowing your tx had the max fee. For instance with the contract protocol I describe in (1), shave off what ever percentage of the original sacrifice, linking the merkle-root of the merkel tree of alt-chains at the same time. Anyone can still monitor the set of all two-step sacrifices and associated contract movements and check that their one in a block was the largest possible. Finally if you want to be nice, modify the contract value rules so only the successful max contract value tx has it's balance decreased. 1) https://github.com/petertodd/trustbits/blob/master/fidelitybond.md Actually, you know gmaxwell, the above would be a great way to run the alt-chain I'm probably going to need for the fraud proofs in Trustbits. Although it does have the minor problem of being ludicrously complex... > > The UTXO set is the most expensive part of the blockchain because it > > must be stored in memory with fast access times. It's good that you have > > designed the system so that the addresses can be revoked, removing them > > from the UTXO set, but it still will encourage the exact same type of > > ugly squatting behavior we've already seen with first-bits, and again > > it'll have a significant cost to the network going forward for purposes > > that do not need to be done on the block chain. > > You are probably right that storing this in the _spent outputs_ would be > better. There doesn't seem to be any type of client out there that would > benefit from having to search UTXO only. The blockchain grows at a maximum rate of 55GiB/year. Do you think your users will all want to have that available just to validate some PKI certificates? -- 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Blockchain as root CA for payment protocol 2013-02-08 10:03 [Bitcoin-development] Blockchain as root CA for payment protocol Timo Hanke 2013-02-08 11:01 ` Peter Todd @ 2013-02-11 19:39 ` Rick Wesson 1 sibling, 0 replies; 8+ messages in thread From: Rick Wesson @ 2013-02-11 19:39 UTC (permalink / raw) To: timo.hanke; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2911 bytes --] I prefer to leverage the signing of the (.) root in the DNS tree. The amount of effort in signing the root holds more weight than building a CA off the bitcoin blockchain. If you want to associate identifiers for payment addresses I suggest putting those in DNSSEC signed records in the DNS. For routing around x.509 CAs I suggest participating in the DANE working group in the IETF. -rick On Fri, Feb 8, 2013 at 2:03 AM, Timo Hanke <timo.hanke@web•de> wrote: > There have been proposals to use the blockchain to establish > "identities". firstbits is a simple example. I would like to announce a > project that extends this idea to turn the blockchain into a "root CA" > that can sign arbitrary certificates. The purpose is to use these > certificates in the payment protocol, where some might consider > traditional centralized root CAs unsatisfactory. > > Code is here: https://github.com/bcpki > > Technical specification and full-length examples are found in the wiki. > I therefore spare myself from repeating the details here, even though, > of course, discussion about those details is welcome on this list. > > Excerpt from README.md follows: > > First, we have drafted a quite general specification for bitcoin > certificates (protobuf messages) that allow for a variety of payment > protocols (e.g. static as well as customer-side-generated payment > addresses). > This part has surely been done elsewhere as well and is orthogonal to the > goal of this project. > What is new here is the signatures _under_ the certificates. > > We have patched the bitcoind to handle certificates, submit signatures to > the blockchain, verify certificates against the blockchain, pay directly to > certificates (with various payment methods), revoke certificates. > Signatures in the blockchain are stored entirely in the UTXO set (i.e. the > unspend, unprunable outputs). > This seems to make signature lookup and verification reasonably fast: > it took us 10s in the mainnet test we performed (lookup is instant on the > testnet, of course). > > Payment methods include: static bitcoin addresses, client-side derived > payment addresses (pay-to-contract), pay-to-contract with multisig > destinations (P2SH) > > Full-length real-world examples for all payment methods are provided in > the tutorial pages. > These examples have actually been carried out on testnet3. > > For further details and specifications see the wiki. > > timo hanke > > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 3655 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-02-11 20:08 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-02-08 10:03 [Bitcoin-development] Blockchain as root CA for payment protocol Timo Hanke 2013-02-08 11:01 ` Peter Todd 2013-02-09 14:33 ` Timo Hanke 2013-02-09 19:01 ` Luke-Jr 2013-02-11 19:12 ` Timo Hanke 2013-02-11 19:21 ` Gregory Maxwell 2013-02-11 11:21 ` Peter Todd 2013-02-11 19:39 ` Rick Wesson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox