public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Natanael <natanael.l@gmail.com>
To: Mike Hearn <mike@plan99.net>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Date: Thu, 12 Feb 2015 14:02:20 +0100	[thread overview]
Message-ID: <CAAt2M19UinurnQQVJWbR_UcSmCBsdFyksnhTfL4ESDMfny+UQQ@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP2YJxwVEocNXjc5cadcq6Wwed7vTLh_4zEX2ct7bTCz5g@mail.gmail.com>

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

Den 12 feb 2015 13:49 skrev "Mike Hearn" <mike@plan99.net>:
>>
>> Are you not counting collateralized multisignature notaries? Its an
extended version of the Greenaddress.it model.
>
> It makes unconfirmed transactions useless in the classical Bitcoin model.
Obviously if you introduce a trusted third party you can fix things, but
then you're back to having the disadvantages of centralised trust.

That trust you put in them is extremely limited, and temporary.

First of all, the standard multisignature notary model applies like how I
originally described it in my blog post over a year ago.

You can prove a doublespend instantly by showing two conflicting
transactions both signed by thar party. This pair can be distributed as a
proof of malice globally in seconds via a push messaging mechanism.

After confirmation in the blockchain, you have standard Bitcoin transaction
security.
To profit, the notary would have to be sure the payout from agreeing on
collusion (or to perform the doublespend themselves) would pay out better
than acting honestly for a given amount of time info the future. This means
transactions for small sums are secure.

To provide security for high value transactions, NRW adds a collateral
transaction that the notary stands for and signs in advance, and gives to
the seller. The key here is that it is constructed such that if the
original payment gets doublespent, then this collateral transaction to the
seller becomes spendable.

So there is two outcomes - either the customer or the notary pays the
seller. The customer can't force a doublespend. The notary can't steal or
freeze funds (due to nlocktime fund recovery option). The seller knows
he'll get the funds for sure before delivering the goods. Nobody is at
risk.

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

  reply	other threads:[~2015-02-12 13:02 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-12  6:47 [Bitcoin-development] replace-by-fee v0.10.0rc4 Peter Todd
2015-02-12  7:23 ` Tamas Blummer
2015-02-12  7:45   ` Peter Todd
2015-02-12  8:27     ` Tamas Blummer
2015-02-12  8:49       ` Peter Todd
2015-02-12  9:01         ` Tamas Blummer
2015-02-15 20:51       ` Troy Benjegerdes
2015-02-12  8:16   ` Alex Mizrahi
2015-02-12 11:58 ` Mike Hearn
2015-02-12 12:23   ` Natanael
2015-02-12 12:49     ` Mike Hearn
2015-02-12 13:02       ` Natanael [this message]
2015-02-12 13:44         ` Mike Hearn
2015-02-12 14:36           ` Natanael
2015-02-12 14:53             ` Mike Hearn
2015-02-12 15:20               ` Natanael
2015-02-12 15:30                 ` Justus Ranvier
2015-02-12 13:36       ` Oleg Andreev
2015-02-12 12:52   ` Alex Mizrahi
2015-02-12 13:18     ` Mike Hearn
2015-02-12 13:45       ` Alex Mizrahi
2015-02-12 13:52         ` Mike Hearn
2015-02-12 14:04       ` Tamas Blummer
2015-02-12 14:16         ` Mike Hearn
2015-02-12 14:25           ` Tamas Blummer
2015-02-12 23:08             ` Tom Harding
2015-02-12 14:32       ` Alex Mizrahi
2015-02-12 15:15         ` Mike Hearn
2015-02-12 15:32           ` Natanael
2015-02-12 15:42             ` Mike Hearn
2015-02-12 15:54               ` Natanael
2015-02-12 16:57           ` Btc Drak
2015-02-12 17:24             ` Oleg Andreev
2015-02-12 18:11               ` Justus Ranvier
2015-02-12 18:37                 ` Allen Piscitello
2015-02-12 19:15                   ` Alan Reiner
2015-02-12 19:34                     ` Justus Ranvier
2015-02-12 19:45                       ` Peter Todd
2015-02-12 19:49                         ` Justus Ranvier
2015-02-12 19:47                       ` Allen Piscitello
2015-02-12 19:52                         ` Justus Ranvier
2015-02-12 20:02                           ` Natanael
2015-02-12 20:36                           ` Allen Piscitello
2015-02-14 14:47                             ` Ross Nicoll
2015-02-12 20:06                     ` Peter Todd
2015-02-12 19:49       ` Gregory Maxwell
2015-02-12 20:18         ` Peter Todd
2015-02-13 11:34         ` Mike Hearn
2015-02-12 12:54   ` Tamas Blummer
2015-02-12 14:42   ` Alex Mizrahi
2015-02-12 15:27   ` Jeff Garzik
2015-02-15 21:25     ` Troy Benjegerdes
2015-02-15 21:40       ` Adam Gibson
2015-02-19  8:56         ` Troy Benjegerdes
2015-02-21 19:09           ` Jorge Timón
2015-02-21 20:30             ` Mark Friedenbach
2015-02-21 22:47               ` Jeff Garzik
2015-02-22  1:15                 ` Peter Todd
2015-02-22  3:25                 ` Jorge Timón
2015-02-22  4:06                   ` Jeff Garzik
2015-02-22 11:41                     ` Eric Lombrozo
2015-02-22 12:06                       ` Eric Lombrozo
2015-02-22 13:41                         ` Eric Lombrozo
2015-02-22 13:53                           ` Peter Todd
2015-02-22 23:29                             ` Eric Lombrozo
2015-02-24  1:11                               ` Jeff Garzik
2015-03-01 17:59                         ` Troy Benjegerdes
2015-03-01 19:05                           ` Neil Fincham
2015-03-01 17:44                 ` Troy Benjegerdes
2015-02-12 16:15   ` Lawrence Nahum
2015-02-12 18:14 ` Tom Harding
2015-02-12 21:40 ` Josh Lehan
2015-02-22 16:36 ` Tom Harding
2015-02-22 17:12   ` Peter Todd
2015-02-22 19:25     ` Tom Harding
2015-02-22 21:50       ` Peter Todd
2015-05-04  4:36 ` [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1 Peter Todd
2015-05-05  2:23   ` Kevin Greene
2015-05-23 18:26   ` [Bitcoin-development] Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAt2M19UinurnQQVJWbR_UcSmCBsdFyksnhTfL4ESDMfny+UQQ@mail.gmail.com \
    --to=natanael.l@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox