diff options
| author | Gregory Maxwell <gmaxwell@gmail.com> | 2014-04-24 02:25:02 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-04-24 09:25:10 +0000 |
| commit | 02c534a8225e3c069edc30b0f630bb5ce65b4101 (patch) | |
| tree | 301bfc6d14dafb41978ba8d32f1b7d35c1167640 | |
| parent | d3808e98112e9cffeb225528e53f21ab5b3a5e81 (diff) | |
| download | pi-bitcoindev-02c534a8225e3c069edc30b0f630bb5ce65b4101.tar.gz pi-bitcoindev-02c534a8225e3c069edc30b0f630bb5ce65b4101.zip | |
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
| -rw-r--r-- | 01/7ab6ba0c445dbaf41180ed9a243ba770ebc0a4 | 153 |
1 files changed, 153 insertions, 0 deletions
diff --git a/01/7ab6ba0c445dbaf41180ed9a243ba770ebc0a4 b/01/7ab6ba0c445dbaf41180ed9a243ba770ebc0a4 new file mode 100644 index 000000000..dfe79e64a --- /dev/null +++ b/01/7ab6ba0c445dbaf41180ed9a243ba770ebc0a4 @@ -0,0 +1,153 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <gmaxwell@gmail.com>) id 1WdFu2-0006qU-5O + for bitcoin-development@lists.sourceforge.net; + Thu, 24 Apr 2014 09:25:10 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.215.49 as permitted sender) + client-ip=209.85.215.49; envelope-from=gmaxwell@gmail.com; + helo=mail-la0-f49.google.com; +Received: from mail-la0-f49.google.com ([209.85.215.49]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1WdFu0-0005sq-Vv + for bitcoin-development@lists.sourceforge.net; + Thu, 24 Apr 2014 09:25:10 +0000 +Received: by mail-la0-f49.google.com with SMTP id ec20so1468497lab.36 + for <bitcoin-development@lists.sourceforge.net>; + Thu, 24 Apr 2014 02:25:02 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.112.209.5 with SMTP id mi5mr464761lbc.30.1398331502326; Thu, + 24 Apr 2014 02:25:02 -0700 (PDT) +Received: by 10.112.89.68 with HTTP; Thu, 24 Apr 2014 02:25:02 -0700 (PDT) +In-Reply-To: <CANEZrP3vT6Q72X6PrcDQ8_fDeF90WmV4-M045Ac=kJY+PhuAdg@mail.gmail.com> +References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com> + <CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com> + <CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com> + <CAE28kUSLXG0y350gMiwnv0CoOHUorMgLup9TG77Mjj+BJcuowA@mail.gmail.com> + <CANEZrP0j0KoLUB+SE+W3fL8vTKay0niqoeQ38RKnU9cyGgvvYw@mail.gmail.com> + <CAAS2fgQV0=QfCWhwVh6-mw=eg9MDd1E21P_7rFAnGp0P43c1Fw@mail.gmail.com> + <CANEZrP3vT6Q72X6PrcDQ8_fDeF90WmV4-M045Ac=kJY+PhuAdg@mail.gmail.com> +Date: Thu, 24 Apr 2014 02:25:02 -0700 +Message-ID: <CAAS2fgQFx7-0vZ2AR3RnLORZZCqjBFHyUBqj688Jrz8OuMYPKA@mail.gmail.com> +From: Gregory Maxwell <gmaxwell@gmail.com> +To: Mike Hearn <mike@plan99.net> +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Score: -1.6 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (gmaxwell[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1WdFu0-0005sq-Vv +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage + Finney attacks +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Thu, 24 Apr 2014 09:25:10 -0000 + +On Thu, Apr 24, 2014 at 1:39 AM, Mike Hearn <mike@plan99.net> wrote: +> It absolutely is! +> https://bitcointalk.org/index.php?topic=3D60937.0 + +May I direct your attention to the third post in that thread? + +Luke attempting to ret-con the enforcement flag into a vote didn't +make it one, and certantly wouldn't make it a fair, just, or sane +method of one. And so much for the effectiveness=E2=80=94 you didn't implem= +ent +it for years even after it was deployed. + +And yes, you can take any decision system and draw comparisons to +voting and call it a vote but that doesn't mean is serves the same +role or was intended for that purpose. + +> No, coinbases are deletable. If some miners fork the chain and build a +> longer one, the others will all switch to it and the coinbases blocks the= +y + +Yes, you can reorg out the blocks and actually remove them, but I +understood that you were _not_ proposing that quite specifically. But +instead proposed without reorging taking txouts that were previously +assigned to one party and simply assigning them to others. + +> I think the root of this disagreement is whether the block chain algorith= +m +> left by Satoshi is somehow immutable and itself the end, or whether it's = +(as +> I see it) just a means to an end and therefore an algorithm that can be +> tweaked and improved, to get us closer to the goal. + +I don't think thats the root of the the disagreement at all. I think +all sorts of changes are interesting, especially ones that increase +flexibility or fix bugs but less so ones that would impose significant +changes on parties without their consent especially things that look +like taking someone's coins and assigning them to someone else. + +I think the root is that you believe that the miners are, should be, +or even could be trustworthy in ways that I do not, and as a result +you expect to be able to extract the performance of a trusted +centralized system out of them that I do not. Bitcoin is a system +where the incentives are well enough aligned that you appear to only +need a small amount of altruism to make it reliable. ... and even +summoning that altruism is a challenge=E2=80=94 as miners hand over control= + of +their hash-power to centralized pools (some known to have behaved +poorly in the past), etc. + +I would like that performance if it came at no cost: But proposals +that miners conspiring to blacklist transactions/blocks produced by +other people is something with a risk of a worse violation of the +system's promises than some disagreement of the ordering of +unconfirmed transactions. Pretty much immediately after your post +Peter Todd=E2=80=94 in his trouble making manner=E2=80=94 went and posted o= +n reddit +proposing the mechanism be used to claw back mining income from a +hardware vendor accused of violating its agreements on the amount of +self mining / mining on customers hardware. While Peter's suggestion +was no doubt intentionally trouble making=E2=80=94 I'm not clear on where t= +he +line is here: Harm from reordering pretty much non-existent currently +and is highly speculative, while the harm to miners by hardware +vendors who've promised to not compete with their own customers or use +their equipment is not at all speculative and very salient to miners. + +This especially in light of the fact that the system already has an +equitable method to decide what order transactions should be in... but +instead you propose an additional complex heuristic system where based +on some unspecified collusion some majority of miners take a +minorities coins and assign them to themselves. + +Unlike reorginization this form of wealth transferal has no collateral +damage meaning that a majority cabal can use it to deprive a minority +outsider of some or all income without risking disrupting the network, +it would also lay the groundwork for additional forms of censorship +which I believe would be at odds with the purpose and architecture of +the system... and, as I noted above, it wouldn't actually prevent +theft, it would just mean that no single block could make its theft +services available to all comers (or even any of the public at all). +The simple mechenism of allowing only only a small number of paid +reordering transactions per block would prevent forming a quorum on +the decision to revoke the coinbase, and you'd even get additional +income from the probe transactions without even helping any real +double spends at all. The incentives seem very hard to analyze. + + |