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
Published at
2023-06-07 11:31:20Event JSON
{
"id": "86ef200c825a3a7ae4d91d8b1306be2f6f69ce8af8af173f17a80ab14a6c8bfb",
"pubkey": "6b41dfcce682764d40c00fd6580a99614b6bbe8a8332085dea07afbc47ba9e8f",
"created_at": 1686137480,
"kind": 1,
"tags": [
[
"e",
"e992a0596803801bdc60b39e6a8f2a9b5632f4cd93d71e49809fd4b4885dc86d",
"",
"root"
],
[
"e",
"4ce6cb3c62b56b6728f4ec2d3e30b2a11089833a952c4312ea39f9348b77d2fa",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2013-02-09\n📝 Original message:On Fri, Feb 08, 2013 at 06:01:08AM -0500, Peter Todd wrote:\n\u003e On Fri, Feb 08, 2013 at 11:03:54AM +0100, Timo Hanke wrote:\n\u003e \u003e 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).\n\u003e \u003e This part has surely been done elsewhere as well and is orthogonal to the goal of this project.\n\u003e \u003e What is new here is the signatures _under_ the certificates.\n\u003e \u003e \n\u003e \u003e 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.\n\u003e \u003e Signatures in the blockchain are stored entirely in the UTXO set (i.e. the unspend, unprunable outputs). \n\u003e \u003e This seems to make signature lookup and verification reasonably fast: \n\u003e \u003e it took us 10s in the mainnet test we performed (lookup is instant on the testnet, of course).\n\u003e \n\u003e Why don't you use namecoin or another alt-chain for this?\n\nBecause namcoin tries to solve a different problem, DNS, whereas I want\nto establish an identity for a payment protocol. Your incoming payments\nwill land on addresses that are derived (regardless which way) from this\nidenity. This makes your identity as important (securitywise) as\nanything else involved in the bitcoin protocol. Therefore I would not\nwant to have payment-ids rely on anything _less_ than bitcoin's own\nblockchain. In particular not on PKI with centralized root CAs. But also\nnot on namecoin or any other (weaker) alt-chains.\n\nYou can argue that alt-chains _can_ be as strong as bitcoin, but they\ndon't _have to_ be. There is no guarantee how many people will\ncross-mine. The alt-chain could even disappear at some point. If at some\npoint your alt-chain is no longer being worked on, then how do you prove\nthat some old bitcoin transaction went to an address for which there was\na valid id/certificate at the time of sending? If the certificate is\nbased inside bitcoin's blockchain then you will have a proof for the\ncorrect destinations of all your old transactions as long as bitcoin\nexists.\n\nBesides all this, as you mentioned namecoin specifically, that is\noverkill if you just want to link two hashes together. A single 2-of-2\nmultisig output would suffice for that. \n\n\u003e The UTXO set is the most expensive part of the blockchain because it\n\u003e must be stored in memory with fast access times. It's good that you have\n\u003e designed the system so that the addresses can be revoked, removing them\n\u003e from the UTXO set, but it still will encourage the exact same type of\n\u003e ugly squatting behavior we've already seen with first-bits, and again\n\u003e it'll have a significant cost to the network going forward for purposes\n\u003e that do not need to be done on the block chain.\n\nYou are probably right that storing this in the _spent outputs_ would be\nbetter. There doesn't seem to be any type of client out there that would\nbenefit from having to search UTXO only. \n\nTimo",
"sig": "3f6535a68003630e98f193b660107790cb2c33267dc356bb301f334cee505c592e4644bfc94fcc75947ea8e5871df1627450648c00acd55acbe071bfaf7c3e58"
}