public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99•net>
To: Kyle Schlansker <kylesch@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Anti DoS for tx replacement
Date: Wed, 17 Apr 2013 11:19:43 +0200	[thread overview]
Message-ID: <CANEZrP2PEB8n_Ov1bXi_ZoAkLwfz7_JtM9PPHr+8ei5KCgwdEg@mail.gmail.com> (raw)
In-Reply-To: <CAD0SH_WOG8jQvzsNzwud3fYjaxqTJo0CS7yP6XZeKvap_yqtqg@mail.gmail.com>

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

> Or are you talking about some sort of new decentralized high frequency
> trading system that is self-matching and self-clearing? (I'd be very
> interested in hearing more if this is the case).
>

I'm using the term "high frequency trading" because Satoshi did. Like the
way he used the word "contract" it is perhaps a bit misleading, but we lack
anything better to describe this new concept.

Today HFT typically means companies that submits tons of micro-trades to
centralised asset exchanges to try and exploit statistically expected
correlations. HFT using tx replacement has nothing to do this with - it is
instead a way that N parties can negotiate amongst themselves as fast as
they can compute and verify signatures.

Here is how Satoshi explained it to me, in his words:

An unrecorded open transaction can keep being replaced until nLockTime.  It
may contain payments by multiple parties.  Each input owner signs their
input.  For a new version to be written, each must sign a higher sequence
number (see IsNewerThan).  By signing, an input owner says "I agree to put
my money in, if everyone puts their money in and the outputs are this."
 There are other options in SignatureHash such as SIGHASH_SINGLE which
means "I agree, as long as this one output (i.e. mine) is what I want, I
don't care what you do with the other outputs.".  If that's written with a
high nSequenceNumber, the party can bow out of the negotiation except for
that one stipulation, or sign SIGHASH_NONE and bow out completely.

The parties could create a pre-agreed default option by creating a higher
nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties
to sign to complete the signature.  The parties hold this tx in reserve and
if need be, pass it around until it has enough signatures.

One use of nLockTime is high frequency trades between a set of parties.
 They can keep updating a tx by unanimous agreement.  The party giving
money would be the first to sign the next version.  If one party stops
agreeing to changes, then the last state will be recorded at nLockTime.  If
desired, a default transaction can be prepared after each version so n-1
parties can push an unresponsive party out.  Intermediate transactions do
not need to be broadcast.  Only the final outcome gets recorded by the
network.  Just before nLockTime, the parties and a few witness nodes
broadcast the highest sequence tx they saw.

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

  parent reply	other threads:[~2013-04-17  9:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-16 17:39 Mike Hearn
2013-04-16 18:43 ` Peter Todd
2013-04-17  9:48   ` Mike Hearn
2013-04-17 19:44     ` Alan Reiner
2013-04-18  6:07     ` John Dillon
2013-04-18  8:14       ` Peter Todd
2013-04-19  4:38         ` John Dillon
2013-04-19  4:55           ` Jeff Garzik
2013-04-18  8:32       ` Mike Hearn
2013-04-18  9:04         ` Peter Todd
2013-04-18  9:28           ` Peter Todd
2013-04-18  9:32             ` Mike Hearn
2013-04-18  9:28           ` Mike Hearn
2013-04-18  9:34             ` Mike Hearn
2013-04-18 10:08             ` Peter Todd
2013-04-18 10:19               ` Mike Hearn
2013-04-18 13:37                 ` Gavin Andresen
     [not found] ` <CAD0SH_WOG8jQvzsNzwud3fYjaxqTJo0CS7yP6XZeKvap_yqtqg@mail.gmail.com>
2013-04-17  9:19   ` Mike Hearn [this message]
2013-04-20  1:48 Jeremy Spilman
2013-07-18 11:13 ` Peter Todd
2013-07-18 12:53   ` Jeff Garzik
2013-07-18 13:43     ` Peter Todd
2013-07-18 16:09   ` Peter Todd
2013-04-20 20:51 Jeremy Spilman
2013-04-22 11:07 ` Mike Hearn
2013-04-23 12:40 ` John Dillon

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=CANEZrP2PEB8n_Ov1bXi_ZoAkLwfz7_JtM9PPHr+8ei5KCgwdEg@mail.gmail.com \
    --to=mike@plan99$(echo .)net \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=kylesch@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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