Timo Hanke [ARCHIVE] on Nostr: 📅 Original date posted:2013-02-09 📝 Original message:On Fri, Feb 08, 2013 at ...
📅 Original date posted:2013-02-09
📝 Original message: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
📝 Original message: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