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 17:37:22 +0200 [thread overview]
Message-ID: <CAC1+kJOO1DyfWTex5OgsWx2ypsbBzz+r==-2JRDvRFymA0Ww1w@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP2PZFVvH3oJyLW80e9W_Fa4bvqQ25E7T-ZFFuG9u-q1hQ@mail.gmail.com>
On 4/24/14, Mike Hearn <mike@plan99•net> wrote:
> You can't disentangle the two. Proof of work just makes a block chain hard
> to tamper with. What it contains is arbitrary. Honest miners build a block
> chain that's intended to stop double spending. Dishonest miners don't.
> They're both engaging in proof of work, to different ends.
Yes, you can disentangle replace-by-fee policies from "rewriting
history" attacks.
That's exactly what I'm saying.
Proof of work is the most important thing that makes the blockchain
hard to tamper with.
>> Whatever, let's keep calling stupid miners "honest miners"
>>
>
> No, let's not. Your definition of "smart miner" is one I'd called "stupid
> miner" (or possibly "short bitcoin miner"). They are miners who would
> reduce the value of their coins, by making their own system less useful.
> That's not smart, that's simply short termism taken to an extreme, sort of
> like a business owner who puts so much pressure on his employees they all
> quit. He might have gained a bit more profit in the short term, but only at
> the cost of destroying his business that would have given lower but
> sustainable returns over the long term.
Whatever, pick the terms yourself but let's just stick to the same ones, please.
I've read this argument before, but I simply don't buy it because I
disagree with the premise that replace-by-fee reduces the value of the
coins (not to mention we shouldn't assume miners stock coins for
long).
I think replace-by-fee policies are actually an improvement over
first-saw-first-included policies.
>> This persistent argument from authority is annoying.
>>
>
> Peter always says this too, but it's again an incorrect position. This is
> not an argument from authority.
I don't know about other occasions with other people but what you just
used with me was an argument from authority fallacy. Now you're using
a false analogy to try to convince us you didn't.
If I was saying "we should change the maximum from 21 M to 100 M
because mining subsidies could continue for longer".
"Mining subsidies aren't necessarily a good thing" or
"That's no justification for a hardfork" or
"That could destroy people's confidence in the currency"
would be logical arguments.
"No, because Satoshi picked 21 M" would be an argument from authority fallacy.
>> 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.
>>
>
> Right, but I don't accept this definition of honesty. That's not a
> definition any man on the street would use:
Whatever let's use whatever definitions you want, if I don't like your
definition of honesty I will just invent a new term to define my own.
> "If you pay for something with forged bank notes and walk out
> immediately, you are honest. But if you pay for something with forged bank
> notes and hang around for longer than 10 minutes, you are dishonest"
Sorry, I don't see the analogy.
> That would sound silly to anyone because what's so special about 10
> minutes? It's the act of passing counterfeit money and stealing from the
> merchant that's the dishonest act, how long it takes is irrelevant.
10 minutes is what Satoshi picked. Just kidding...
> In Bitcoin, the dishonest act by the user is signing for the same output
> twice (ignoring special protocols here), and the dishonest act by the miner
> is deviating from normal behaviour for a fee to try and trick the recipient
> into believing they have been paid. The exact details are something
> computer scientists care about, but the average Bitcoin user would not.
People need to understand that Bitcoin transactions are not instant.
For instants transactions you need to rely somehow on trust, use some
trust-less offchain mechanism or use a payment protocol that would
make double-spending irrational (like the one described in the other
thread that uses replace-by-fee).
So I think miner's default behavior should be replace-by-fee. But that
doesn't imply that I want miners to rewrite pow-validated history.
next prev parent reply other threads:[~2014-04-24 15:37 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-23 7:55 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
2014-04-24 14:28 ` Mike Hearn
2014-04-24 15:37 ` Jorge Timón [this message]
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+kJOO1DyfWTex5OgsWx2ypsbBzz+r==-2JRDvRFymA0Ww1w@mail.gmail.com' \
--to=jtimon@monetize$(echo .)io \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/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