public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@monetize.io>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Date: Thu, 24 Apr 2014 15:57:04 +0200	[thread overview]
Message-ID: <CAC1+kJPxwTm6qvh2GYT2XMJAPD5O4WHLOGBTRmchRmZ2wS4MSg@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3obO9rXKcX+G7bs2dd3AqEFOsO8pCUF6orrkGeZyr9Ew@mail.gmail.com>

On 4/24/14, Mike Hearn <mike@plan99.net> wrote:
> No! This is a misunderstanding. The mechanism they use to prevent double
> spends is to *ignore double spends*. The blocks they created indicate the
> ordering of transactions they saw and proof of work is used to arrive at a
> shared consensus ordering given the possibility that transactions arrived
> at different times.
>
> I'm continually amazed at how many people seem to see the current algorithm
> as the goal in and of itself, instead of an imperfect but workable means of
> achieving the actual goal.

I'm not saying proof of work is the goal, the goal is still p2p
transaction serialization.
And that's achieved through proof of work, not through "miner's honesty".

> This definition of honesty is not my own, the one Bitcoin has always used.

Whatever, let's keep calling stupid miners "honest miners", smart
miners "dishonest-by-replace-by fee miners" and miners that do replace
by fee and also hash on top of old blocks "utterly dishonest miners".

> Obviously if Satoshi had wanted transactions to be double spendable by fee
> in the mempool he would have made Bitcoin work that way, instead of coming
> up with the nSequence based replacement scheme instead.

Maybe Satoshi hadn't thought in depth about replace-by-fee when he
wrote the code.
Why should we care?
If nSequence was a design mistake Satoshi did, should we maintain it
to somehow honor him?
Maybe the payment protocol shouldn't have been developed because he
had some weird ideas about paying to ips? Maybe we shouldn't write any
tests because he didn't do so?
This persistent argument from authority is annoying.

> First-seen *is* a protocol rule, as much as Set-Cookie storing data in a
> browser is an HTTP protocol rule. The fact that auditing compliance with it
> is harder to do than some others does not make it less of a rule.

It is not a protocol rule that validators can use to discriminate the
longest valid chain and therefore is not enforceable. Not even through
a softfork because miners can't know which transactions other miners
saw first.
So if it is a protocol rule, I think it shouldn't be.

> Again you are hopelessly confused. Miners that are trying to double spend
> are *by definition* not making transactions irreversible, they are trying
> to make transactions reversible.

Miners that mine on top of the longest valid chain are helping in
making transactions irreversible whether they implement a first-saw or
a replace-by-fee policy.

> Look at it this way. There is no inherent reason BitUndo has to undo only
> Finney attacks. If it gets sufficient hash power it could offer undoing of
> 1-confirm transactions too, right? Sure it'll mostly fail but that's
> already a part of its business model. Sometimes it'll get two blocks in a
> row and succeed. It's a very minor tweak to what they're doing. Would you
> argue these miners are still useful? After all, it's impossible to be
> certain after the fact that miners built on top of the "wrong" block
> because forks occur naturally.

That's not what I'm saying. Miners that don't mine on top of the
longest chain are dishonest by my own definition as well.
You want to equate replace-by-fee "dishonesty" with
trying-to-rewrite-history dishonesty by saying that the transactions
that "have been seen" in the network are already history and that's
where we disagree. I think only what's in the chain is history and I
also think that's the whole point of proof of work.
And I also disagree that all the people who think this way are
"hopelessly confused". We may be confused, but I think there's always
hope for removing confusions provided that there's will to learn,
which I think it is at least my case.

> What I said is, if you believe all miners are willing to double spend for a
> fee then this resolves the experiment as a failure. This is also obvious -
> if you can pay miners to go back and rewrite the chain at will, Bitcoin
> doesn't work.

This is in fact quite polemic and thus obviously not obvious.
Bitcoin works because rewriting the chain gets exponentially more
expensive as time passes.

> Because all miners follow this ridiculous policy, they should be willing to
> fork the chain at any point to claim the higher fee on the new tx. After
> ...
>
> Do you see now why your definition of honesty is completely broken?

I see now that I may have not properly expressed myself in the earlier
post since you clearly misunderstood what I meant by "smart miners".
By that I mean miners implementing replace-by-fee and
child-pays-for-parent policies Not miners trying to rewrite history,
which I agree is about as smart as mining on top of orphan blocks.



  reply	other threads:[~2014-04-24 13:57 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23  7:55 [Bitcoin-development] Coinbase reallocation to discourage Finney attacks Mike Hearn
2014-04-23  9:57 ` Andy Parkins
2014-04-23 11:07   ` Mike Hearn
2014-04-23 11:39     ` Andy Parkins
2014-04-23 11:45       ` Mike Hearn
2014-04-23 13:21         ` Andy Parkins
2014-04-23 13:31           ` Mike Hearn
2014-04-24  9:21             ` Andy Parkins
2014-04-23 12:43 ` Christophe Biocca
2014-04-23 12:51   ` Mike Hearn
2014-04-23 14:52 ` Justus Ranvier
2014-04-23 15:07   ` Mike Hearn
2014-04-23 17:19     ` Justus Ranvier
2014-04-23 17:47       ` Gavin Andresen
2014-04-23 17:49         ` Justus Ranvier
2014-04-23 17:57           ` Mike Hearn
2014-04-23 18:04             ` Justus Ranvier
2014-04-23 18:15               ` Peter Todd
2014-04-23 18:20                 ` Justus Ranvier
2014-04-23 18:37                   ` Mike Hearn
2014-04-23 18:49                     ` Justus Ranvier
2014-04-23 19:01                       ` Drak
2014-04-23 18:58                     ` Tier Nolan
2014-04-23 15:04 ` Alex Mizrahi
2014-04-23 15:09   ` Mike Hearn
2014-04-23 15:38     ` Alex Mizrahi
2014-04-23 16:04       ` Christophe Biocca
2014-04-23 16:19         ` Chris Pacia
2014-04-23 16:21         ` Mike Hearn
2014-04-23 16:33         ` Kevin
2014-04-24 11:22     ` Jorge Timón
2014-04-24 11:43       ` Mike Hearn
2014-04-24 13:57         ` Jorge Timón [this message]
2014-04-24 14:28           ` Mike Hearn
2014-04-24 15:37             ` Jorge Timón
2014-04-24 17:07               ` Justus Ranvier
2014-04-25  4:31             ` Gareth Williams
2014-04-25 10:17               ` Mike Hearn
2014-04-25 13:19                 ` Gareth Williams
2014-04-25 15:28                   ` Mike Hearn
2014-04-26 12:15                     ` Gareth Williams
2014-04-27  1:42                       ` Christophe Biocca
2014-04-27 12:53                         ` Gareth Williams
2014-04-27 14:31                           ` Mike Hearn
2014-04-27 23:10                             ` Gareth Williams
2014-04-28 21:41                           ` Adam Back
2014-04-29 14:13                             ` Mike Hearn
2014-04-29 14:21                               ` Gregory Maxwell
2014-04-29 14:26                                 ` Mike Hearn
2014-04-30 13:12                                   ` Gareth Williams
2014-04-30 13:55                                     ` Mike Hearn
2014-04-30 14:31                                       ` Gareth Williams
2014-04-29 19:29                               ` Justus Ranvier
2014-04-30 13:00                               ` Gareth Williams
2014-04-30 17:06                                 ` Troy Benjegerdes
2014-04-30 17:13                                   ` Jameson Lopp
2014-04-30 14:08                               ` Gareth Williams
2014-04-23 15:28   ` Peter Todd
2014-04-23 15:34 ` Kevin
2014-04-23 15:41   ` Pieter Wuille
2014-04-23 15:55     ` Peter Todd
2014-04-23 18:57 ` Gregory Maxwell
2014-04-23 19:19   ` Mike Hearn
2014-04-23 19:47     ` Gregory Maxwell
2014-04-23 19:59       ` Mike Hearn
2014-04-23 20:24         ` Gregory Maxwell
2014-04-23 20:37           ` Mike Hearn
2014-04-23 20:44             ` Adam Ritter
2014-04-23 20:51               ` Mike Hearn
2014-04-24 15:13                 ` Sergio Lerner
2014-04-24 15:34                   ` Mike Hearn
2014-04-23 20:53               ` Gregory Maxwell
2014-04-23 21:23                 ` Tier Nolan
2014-04-23 21:39                   ` Gregory Maxwell
2014-04-23 22:26                     ` Tier Nolan
2014-04-24  0:55                   ` Tom Harding
     [not found]                 ` <CAKuKjyWDniyP503XSw8=tK9XQW-T58j+VD6ajXCxz=HihN93mQ@mail.gmail.com>
2014-04-24 14:52                   ` [Bitcoin-development] Fwd: " Adam Ritter
2014-04-23 20:41         ` [Bitcoin-development] " Daniel Krawisz
2014-04-23 22:06     ` Alex Mizrahi
2014-04-24  7:58       ` Mike Hearn
2014-04-24  8:19         ` Gregory Maxwell
2014-04-24  8:39           ` Mike Hearn
2014-04-24  9:25             ` Gregory Maxwell
2014-04-24  9:56               ` Mike Hearn
2014-04-24 13:44                 ` Peter Todd
2014-04-24 14:09                   ` Mike Hearn
2014-04-24 14:47                     ` Christophe Biocca
2014-04-24 15:03                       ` Peter Todd
2014-04-24 16:05                         ` Christophe Biocca
2014-04-24 16:14                         ` Mike Hearn

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=CAC1+kJPxwTm6qvh2GYT2XMJAPD5O4WHLOGBTRmchRmZ2wS4MSg@mail.gmail.com \
    --to=jtimon@monetize.io \
    --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