Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees

Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees

[Goss, Brian C., M.D.]

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
> ***************************************************

Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees

[Mark Friedenbach]

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.
> 

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

[Lawrence Nahum]

Mike Hearn <mike <at> plan99.net> writes:

> Please see https://github.com/bitcoin/bitcoin/pull/3883 which implements 
this exact scheme. It can solve some kinds of double spends (probably), but 
others - like ones done by corrupt miners (see bitundo) - can't be solved 
this way.

I read the comments on the PR. I mean no disrespect but this patch can't 
prevent double spends minutes apart and a solution is as good as it's 
weakest link.

It also seems to suffer from potential ddos and otherwise may provide a 
false sense of security. I wouldn't call it a solution in sight just yet.


> Lawrence's motivation for this BIP is essentially to act as a backup in 
case the Bitcoin native double spending protections end up being too weak to 
be useful. It reintroduces a notion of centralised trust as a layer on top 
of the Bitcoin protocol, but only for cases where the seller/recipient feels 
it'd be useful. In this way it gives us slack: if someone is able to 
reliably double spend and the merchants losses due to payment fraud go up, 
we can fall back to TTPs for a while until someone finds a solution for 
Bitcoin, or we just give up on the Bitcoin experiment, but hey - at least we 
now have a better intermediary protocol than SWIFT 

I wouldn't put it just like that. Sure, it's a backup to the double spend 
solution in case we don't reach one - but also, even if you reach some 
reasonable compromise I assume it won't be instant and instant confirmation 
between exchanges can create huge arbitrage opportunities and as such 
liquidity.

It's not really aimed at the merchant but more at service providers and 
payment processors - or simply, between users that don't know each other in 
local traders environments/squares, assuming they are ok trusting a 
known/respected/reputable third party.

> In practice of course this is something payment processors like Bitpay and 
Coinbase will think about. Individual cafes etc who are just using mobile 
wallets won't be able to deal with this complexity: if we can't make native 
Bitcoin work well enough there, we're most likely to just lose that market 
or watch it become entirely centralised around a handful of payment 
processing companies.


What do you expect for e-commerce and escrow to happen? Don't you think the 
market will naturally converge to a handful of hubs that will helps with 
refunds and things like that? Or do you expect to just 'trust' all people on  
online markets and smaller unknown online shops?

I mean, the beauty of Bitcoin is that it brings much more transparency and 
the tools to build such things without huge barriers to entry and without 
using closed protocols - not that it solves _every_ problem.

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

>
> I read the comments on the PR. I mean no disrespect but this patch can't
> prevent double spends minutes apart and a solution is as good as it's
> weakest link.
>

Actually Tom is running a page where he shows double spends detected by his
node or relayed by mine (there are only two nodes in this little detection
network currently), and it does show double spends that occur seconds,
minutes or even days apart.

Regardless, whether that approach helps or not is off topic for this
thread. Let's all hope it does and discuss the details in some other
thread, or on the pull request.


> instant confirmation between exchanges can create huge arbitrage
> opportunities and as such
> liquidity.
>

Yes indeed, if you want to do high frequency trading then every millisecond
counts and you probably don't want to rely on watching transactions
propagate across the block chain. For inter-exchange traffic this BIP would
probably be useful. I've been talking about the consumer case.


> What do you expect for e-commerce and escrow to happen? Don't you think the
> market will naturally converge to a handful of hubs that will helps with
> refunds and things like that?


No, I expect there to be many kinds of trades where dispute mediation is
unnecessary, e.g. when I buy a drink at Starbucks or a burger at McDonalds
the chances of me wanting to charge it back is basically zero. Same for
sending between people who know each other, large corporate transactions
where the threat of a lawsuit is more useful than mediation, etc.

But for transactions where third parties are needed for dispute mediation,
yes, I'd expect there to be a handful of well known trusted names for the
majority of such transactions, and then a long tail of specialists who only
mediate e.g. purchases of rare Aztec artifacts or other things where a
generic company might be easily fooled.

[-- Attachment #2: Type: text/html, Size: 2543 bytes --]

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

[Lawrence Nahum]

Mike Hearn <mike <at> plan99.net> writes:

> Actually Tom is running a page where he shows double spends detected by 
his node or relayed by mine (there are only two nodes in this little 
detection network currently), and it does show double spends that occur 
seconds, minutes or even days apart.

I only meant that double spends minutes apart are possible and that by then 
the sole use of a monitor is too late even if it will tell you.

> Regardless, whether that approach helps or not is off topic for this 
thread. Let's all hope it does and discuss the details in some other thread, 
or on the pull request.

Fair enough.

> Yes indeed, if you want to do high frequency trading then every 
millisecond counts and you probably don't want to rely on watching 
transactions propagate across the block chain. For inter-exchange traffic 
this BIP would probably be useful. I've been talking about the consumer 
case.

That's quite different, granted.

> No, I expect there to be many kinds of trades where dispute mediation is 
unnecessary, e.g. when I buy a drink at Starbucks or a burger at McDonalds 
the chances of me wanting to charge it back is basically zero. Same for 
sending between people who know each other, large corporate transactions 
where the threat of a lawsuit is more useful than mediation, etc.

I wouldn't assume that if bitcoin alone (i.e. without third parties) can't 
be used for medium-high value purchases then it's useless. 

> But for transactions where third parties are needed for dispute mediation, 
yes, I'd expect there to be a handful of well known trusted names for the 
majority of such transactions, and then a long tail of specialists who only 
mediate e.g. purchases of rare Aztec artifacts or other things where a 
generic company might be easily fooled.

Agreed.

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

>
> I only meant that double spends minutes apart are possible and that by then
> the sole use of a monitor is too late even if it will tell you.
>

As long as miners stick to Satoshi's first seen rule, which is the default,
it's useful:

https://bitcointalk.org/index.php?topic=423.msg3819#msg3819

(this is the famous "snack machine" thread from 2010)

If they decide to change to something like highest-fee-always-wins, then
they (again) centralise things by forcing all instant transactions to pay
GreenAddress and its competitors money - much though I like your product
Lawrence, let's hope they don't collectively lemming us all off a cliff by
doing that ;)

[-- Attachment #2: Type: text/html, Size: 1273 bytes --]

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

[Lawrence Nahum]

Mike Hearn <mike <at> plan99.net> writes:

> As long as miners stick to Satoshi's first seen rule, which is the 
default, it's useful:
> 
> 
> https://bitcointalk.org/index.php?topic=423.msg3819#msg3819
> 
> 
> 
> 
> (this is the famous "snack machine" thread from 2010)
> 
> If they decide to change to something like highest-fee-always-wins, then 
they (again) centralise things by forcing all instant transactions to pay 
GreenAddress and its competitors money - much though I like your product 
Lawrence, let's hope they don't collectively lemming us all off a cliff by 
doing that ;)


I assume we can't enforce to miners rules about which tx will go in and 
which won't and therefore whether this will cause more or less double 
spends.


I mean, you can try but I would rather have to option to pick an third party 
instant provider explicitly than  enforce bigger rules on mining which would 
IMHO lead to implicit centralization.

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 2949 bytes --]

Hi Lawrence/All


I'm afraid with this BIP for TTP of instant transactions we will end up in
VISA world again. As I see it - it's not about if the TTPs will centralize,
it's only when. Simply because if economy of scales makes growth profitable
and coming into this market is at least a little expensive - this
(centralization, VISA world) will happen, sooner rather than later.
And while some may argue that coming to market in Bitcoin world is cheap so
the crowd will always have a chance to come in and beat the monopolists -
think of one thing. Right now Bitcoin is not seen as money and not
regulated accordingly anywhere in the world, thanks God, but how many years
away we are from the point when it will start to be regulated that way? And
once it is - the monopolies will make sure that rules are restrictive
enough to prevent competition, especially in conjunction with economy of
scales playing against the small newcomers.
The "instant providers list" is susceptible to regulatory influence, and
once in place and widespread - it will be a timebomb under Bitcoin. We need
to solve the doublespend issue without TTP involvement, or at least without
even a slight chance of making this involvement regulateable. Otherwise I
think the Bitcoin experiment will fail.


Best regards,
Alex Kotenko


2014-06-16 18:16 GMT+01:00 Lawrence Nahum <lawrence@greenaddress.it>:

> Mike Hearn <mike <at> plan99.net> writes:
>
> > As long as miners stick to Satoshi's first seen rule, which is the
> default, it's useful:
> >
> >
> > https://bitcointalk.org/index.php?topic=423.msg3819#msg3819
> >
> >
> >
> >
> > (this is the famous "snack machine" thread from 2010)
> >
> > If they decide to change to something like highest-fee-always-wins, then
> they (again) centralise things by forcing all instant transactions to pay
> GreenAddress and its competitors money - much though I like your product
> Lawrence, let's hope they don't collectively lemming us all off a cliff by
> doing that ;)
>
>
> I assume we can't enforce to miners rules about which tx will go in and
> which won't and therefore whether this will cause more or less double
> spends.
>
>
> I mean, you can try but I would rather have to option to pick an third
> party
> instant provider explicitly than  enforce bigger rules on mining which
> would
> IMHO lead to implicit centralization.
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 4872 bytes --]

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

I think many of us feel it'd be better if this kind of thing were not
needed at all, however, the best way to ensure it doesn't end up being used
is to write code, not to try and block alternative approaches. If Bitcoin
is robust the market should sort it out. If it's robust for some
transactions and not others, that makes for a fun project for a future
generation of hackers to sort out.

OK, enough philosophy - let's try and keep this thread just for discussion
of the BIP itself from now on. If you'd like to continue debating the
Future of Bitcoin please change the subject line and break it out into a
new thread.

[-- Attachment #2: Type: text/html, Size: 716 bytes --]

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

[Daniel Rice]

[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]

I'm trying to think through how to encourage the maximum number of instant
signature providers and avoid the VISA monopoly. Ideal case would be that
people can even be their own instant provider.

What if the protocol allowed multiple instant signatures on a transaction?
Would it encourage more instant providers? For example, a new instant
provider could bootstrap their own trust by paying an already trusted
instant provider to co-sign the same transaction. This would be useful in
the case that a new company tries to release a new wallet once the trust
ring is already established. Nobody will use that wallet because it does
not have the trusted history to do instant transactions, but if they can
pay a small amount per transaction to a third party to cosign, they can
build trust in their own signature till they can eventually have enough
trust on their own. This could be how an individual user could grow trust
in their own instant signature as well.


On Mon, Jun 16, 2014 at 11:09 AM, Mike Hearn <mike@plan99.net> wrote:

> I think many of us feel it'd be better if this kind of thing were not
> needed at all, however, the best way to ensure it doesn't end up being used
> is to write code, not to try and block alternative approaches. If Bitcoin
> is robust the market should sort it out. If it's robust for some
> transactions and not others, that makes for a fun project for a future
> generation of hackers to sort out.
>
> OK, enough philosophy - let's try and keep this thread just for discussion
> of the BIP itself from now on. If you'd like to continue debating the
> Future of Bitcoin please change the subject line and break it out into a
> new thread.
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 2922 bytes --]

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

On Mon, Jun 16, 2014 at 10:29 PM, Daniel Rice <drice@greenmangosystems.com>
wrote:

> I'm trying to think through how to encourage the maximum number of instant
> signature providers and avoid the VISA monopoly. Ideal case would be that
> people can even be their own instant provider.
>

A provider does not have to be an interactive third party. One reason I
suggested using X.509 is so secure hardware devices like the TREZOR could
also be instant providers. The hardware would be tamperproof and assert
using a secret key embedded in it that the tx came from a genuine,
unflashed TREZOR. The the server can know the device won't double spend.

In this way you have decentralised anti-double spending. Of course, it's an
old solution. MintChip sort of worked a bit like this.

[-- Attachment #2: Type: text/html, Size: 1164 bytes --]

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

[Daniel Rice]

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

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.


On Mon, Jun 16, 2014 at 1:32 PM, Mike Hearn <mike@plan99.net> wrote:

> On Mon, Jun 16, 2014 at 10:29 PM, Daniel Rice <drice@greenmangosystems.com
> > wrote:
>
>> I'm trying to think through how to encourage the maximum number of
>> instant signature providers and avoid the VISA monopoly. Ideal case would
>> be that people can even be their own instant provider.
>>
>
> A provider does not have to be an interactive third party. One reason I
> suggested using X.509 is so secure hardware devices like the TREZOR could
> also be instant providers. The hardware would be tamperproof and assert
> using a secret key embedded in it that the tx came from a genuine,
> unflashed TREZOR. The the server can know the device won't double spend.
>
> In this way you have decentralised anti-double spending. Of course, it's
> an old solution. MintChip sort of worked a bit like this.
>

[-- Attachment #2: Type: text/html, Size: 1989 bytes --]

Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees

[Peter Todd]

[-- 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 --]