Adam Back [ARCHIVE] on Nostr: 📅 Original date posted:2013-05-06 📝 Original message:On Mon, May 06, 2013 at ...
📅 Original date posted:2013-05-06
📝 Original message:On Mon, May 06, 2013 at 03:08:57PM -0400, Peter Todd wrote:
>> Hmm: maybe one could use a Brands private credential with offline double
>> spend detection, with the reputation but not coin address of the node
>> disclosed, and the nodes coin address embedded in the proof. Each node
>> could be is own CA, providing a ZKP. If the node ever double spends a coin,
>> it loses its reputation as the coin address is revealed.
>
>Be careful not to mix up the concept of a relay node with someone
>posessing Bitcoins. Node's don't spend coins, people/wallets do.
My comment was to say that a good behaviour bond for a relay node could be
put on an address that is defined as unspendable until such time as an
auditor can prove the node engaged in the undesired behaviour, at which
point the audit receives the payment as part of his proof. Or until the
node ceases to operate. Its a smart contract.
However I added to that, that it is still possible to do that while
preseving privacy, to point out that it is technically possible, for people
to be aware of in their mental toolbox, if it helps solve an otherwise
tricky problem.
So that would be a privacy preserving smart contract, the parties are
unknown, and unknowable (with unconditional security even), but still the
smart contract executes. In some sense a privacy preserving smart-contract
is closer to the real point of Szabo's smart-contract idea because you cant
try to renege on the contract in a conventional court - because you cant
identify your counter-party. Bitcoins privacy feature is fairly weak so
that is probably often not true.
Of course you'd probably need zerocoin to stand much chance of proving an
address private key of an unlinked coin was in the double-spend disclosed
attribute in the first place, and as we know zerocoin is not that efficient.
> Make the node identity expensive to obtain. For instance, construct PoW's
> including the node pubkey somehow,
that could be easily done with the work of creating a vanity address. eg
address containing many leading 0s.
Adam
📝 Original message:On Mon, May 06, 2013 at 03:08:57PM -0400, Peter Todd wrote:
>> Hmm: maybe one could use a Brands private credential with offline double
>> spend detection, with the reputation but not coin address of the node
>> disclosed, and the nodes coin address embedded in the proof. Each node
>> could be is own CA, providing a ZKP. If the node ever double spends a coin,
>> it loses its reputation as the coin address is revealed.
>
>Be careful not to mix up the concept of a relay node with someone
>posessing Bitcoins. Node's don't spend coins, people/wallets do.
My comment was to say that a good behaviour bond for a relay node could be
put on an address that is defined as unspendable until such time as an
auditor can prove the node engaged in the undesired behaviour, at which
point the audit receives the payment as part of his proof. Or until the
node ceases to operate. Its a smart contract.
However I added to that, that it is still possible to do that while
preseving privacy, to point out that it is technically possible, for people
to be aware of in their mental toolbox, if it helps solve an otherwise
tricky problem.
So that would be a privacy preserving smart contract, the parties are
unknown, and unknowable (with unconditional security even), but still the
smart contract executes. In some sense a privacy preserving smart-contract
is closer to the real point of Szabo's smart-contract idea because you cant
try to renege on the contract in a conventional court - because you cant
identify your counter-party. Bitcoins privacy feature is fairly weak so
that is probably often not true.
Of course you'd probably need zerocoin to stand much chance of proving an
address private key of an unlinked coin was in the double-spend disclosed
attribute in the first place, and as we know zerocoin is not that efficient.
> Make the node identity expensive to obtain. For instance, construct PoW's
> including the node pubkey somehow,
that could be easily done with the work of creating a vanity address. eg
address containing many leading 0s.
Adam