* Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees
[not found] <mailman.212267.1402952308.2171.bitcoin-development@lists.sourceforge.net>
@ 2014-06-17 20:40 ` Goss, Brian C., M.D.
2014-06-17 22:28 ` Mark Friedenbach
0 siblings, 1 reply; 3+ messages in thread
From: Goss, Brian C., M.D. @ 2014-06-17 20:40 UTC (permalink / raw)
To: <bitcoin-development@lists•sourceforge.net>
Can two signed transactions using the same output as an input (ie, a double spend) be used to trigger a third transaction?
It would be nice if I could sign a tx that would pay m bitcoins to an arbitrary address if and only if someone could present proof that I signed more than 1 transaction using the same output. Thus, a merchant could trust that I would not attempt a double spend for a purchase of n < m bitcoins.
Can this type of transaction be expressed in Bitcoin's scripting language?
Chaum had a similar feature in Digicash way back when...a double spend would let the second merchant compute the identity of the double spender and serve as proof of double spending. It didn't automate punishment though!
My apologies if this has been discussed previously.
-----------------------------
>
> Message: 2
> Date: Mon, 16 Jun 2014 16:50:41 -0400
> From: Peter Todd <pete@petertodd•org>
> Subject: Re: [Bitcoin-development] Fidelity bonds for decentralized
> instant confirmation guarantees
> To: Daniel Rice <drice@greenmangosystems•com>
> Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>, Lawrence
> Nahum <lawrence@greenaddress•it>
> Message-ID: <20140616205041.GA21784@savin>
> Content-Type: text/plain; charset="us-ascii"
>
>> On Mon, Jun 16, 2014 at 01:37:52PM -0700, Daniel Rice wrote:
>> True, that would work, but still how are you going to bootstrap the trust?
>> TREZOR is well known, but in a future where there could be 100 different
>> companies trying to release a similar product to TREZOR it seems like one
>> company could corner the market by being the only one that is an accepted
>> instant provider at most vendors. It seems to encourage monopoly unless
>> there is a standard way to bootstrap trust in your signature.
>
> You can always use fidelity bonds, or as I called it at the time(1),
> "Trusted identities":
>
> 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.
>
> Note that the second paragraph is seriously obsolete - better to either
> use announce-commit sacrifices, or much preferably, simple destruction
> of coins. (sacrifice to fees encourages mining centralization for
> obvious reasons)
>
> 1) "[Bitcoin-development] Trusted identities", Apr 26th 2012, Peter Todd,
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg01005.html
>
> Incidentally, my first post to this mailing list!
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000058ca7ee3a40438ea5a96e499910638352468c6d69abdb226
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 685 bytes
> Desc: Digital signature
>
> ------------------------------
>
>
>
> End of Bitcoin-development Digest, Vol 37, Issue 27
> ***************************************************
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees
2014-06-17 20:40 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Goss, Brian C., M.D.
@ 2014-06-17 22:28 ` Mark Friedenbach
0 siblings, 0 replies; 3+ messages in thread
From: Mark Friedenbach @ 2014-06-17 22:28 UTC (permalink / raw)
To: bitcoin-development
Not with current script, but there are mechanisms by which you can do a
digital signature where signing two pieces of information reveals the
ECDSA k parameter, thereby allowing anyone to recover the private key
and steal the coins.
Practically speaking, these are not very safe systems to use. For
example, imagine accidentally loading up the same wallet on two machines
or the wallet software crashing after signing and sending the
transaction, and the user recreates & sends on recovery.
It also invalidates reasonably legitimate use cases for repeating
addresses (in the absence of other solutions), and its not really
possible to prevent people from sending multiple coins to the same
address (which could then be stolen).
On 06/17/2014 01:40 PM, Goss, Brian C., M.D. wrote:
> Can two signed transactions using the same output as an input (ie, a
> double spend) be used to trigger a third transaction?
>
> It would be nice if I could sign a tx that would pay m bitcoins to an
> arbitrary address if and only if someone could present proof that I
> signed more than 1 transaction using the same output. Thus, a
> merchant could trust that I would not attempt a double spend for a
> purchase of n < m bitcoins.
>
> Can this type of transaction be expressed in Bitcoin's scripting
> language?
>
> Chaum had a similar feature in Digicash way back when...a double
> spend would let the second merchant compute the identity of the
> double spender and serve as proof of double spending. It didn't
> automate punishment though!
>
> My apologies if this has been discussed previously.
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees
2014-06-16 20:37 ` Daniel Rice
@ 2014-06-16 20:50 ` Peter Todd
0 siblings, 0 replies; 3+ messages in thread
From: Peter Todd @ 2014-06-16 20:50 UTC (permalink / raw)
To: Daniel Rice; +Cc: Bitcoin Dev, Lawrence Nahum
[-- Attachment #1: Type: text/plain, Size: 2814 bytes --]
On Mon, Jun 16, 2014 at 01:37:52PM -0700, Daniel Rice wrote:
> True, that would work, but still how are you going to bootstrap the trust?
> TREZOR is well known, but in a future where there could be 100 different
> companies trying to release a similar product to TREZOR it seems like one
> company could corner the market by being the only one that is an accepted
> instant provider at most vendors. It seems to encourage monopoly unless
> there is a standard way to bootstrap trust in your signature.
You can always use fidelity bonds, or as I called it at the time(1),
"Trusted identities":
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.
Note that the second paragraph is seriously obsolete - better to either
use announce-commit sacrifices, or much preferably, simple destruction
of coins. (sacrifice to fees encourages mining centralization for
obvious reasons)
1) "[Bitcoin-development] Trusted identities", Apr 26th 2012, Peter Todd,
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg01005.html
Incidentally, my first post to this mailing list!
--
'peter'[:-1]@petertodd.org
000000000000000058ca7ee3a40438ea5a96e499910638352468c6d69abdb226
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-06-17 22:28 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.212267.1402952308.2171.bitcoin-development@lists.sourceforge.net>
2014-06-17 20:40 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Goss, Brian C., M.D.
2014-06-17 22:28 ` Mark Friedenbach
2014-06-16 16:30 [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Lawrence Nahum
2014-06-16 16:45 ` Mike Hearn
2014-06-16 16:56 ` Lawrence Nahum
2014-06-16 17:01 ` Mike Hearn
2014-06-16 17:16 ` Lawrence Nahum
2014-06-16 18:02 ` Alex Kotenko
2014-06-16 18:09 ` Mike Hearn
2014-06-16 20:29 ` Daniel Rice
2014-06-16 20:32 ` Mike Hearn
2014-06-16 20:37 ` Daniel Rice
2014-06-16 20:50 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox