diff options
author | Nick ODell <nickodell@gmail.com> | 2016-07-26 16:03:41 -0600 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2016-07-26 22:03:43 +0000 |
commit | 13e3cae085dccd524f49e5a3056ad58370c0fc59 (patch) | |
tree | c850818892b99e9bbe41fa65a92a7fbc5d1e1ddf | |
parent | c05adfaaed5acaeaa7904ac280e44b965fe53755 (diff) | |
download | pi-bitcoindev-13e3cae085dccd524f49e5a3056ad58370c0fc59.tar.gz pi-bitcoindev-13e3cae085dccd524f49e5a3056ad58370c0fc59.zip |
Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin
-rw-r--r-- | 0e/07761358546fc11414fd05fafb7c5bc0674918 | 263 |
1 files changed, 263 insertions, 0 deletions
diff --git a/0e/07761358546fc11414fd05fafb7c5bc0674918 b/0e/07761358546fc11414fd05fafb7c5bc0674918 new file mode 100644 index 000000000..bd7b1e18d --- /dev/null +++ b/0e/07761358546fc11414fd05fafb7c5bc0674918 @@ -0,0 +1,263 @@ +Return-Path: <nickodell@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id E0A1C94D + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 26 Jul 2016 22:03:43 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-io0-f170.google.com (mail-io0-f170.google.com + [209.85.223.170]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7C465181 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 26 Jul 2016 22:03:42 +0000 (UTC) +Received: by mail-io0-f170.google.com with SMTP id b62so45935610iod.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 26 Jul 2016 15:03:42 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to; + bh=JGVtOIaTFKiMVGL/mCfPlZiQg9JiS170RhunrMDic68=; + b=qNHM3AK+9e7MlCzDckTCQwYZEWCNqC3MqDX81uu20Q0fOp0y16FTKqCEFiDSJ70MN6 + 6OMwzbxWxO3IoOLm9DEcMcrfgaoECXyGgVEzgBt6D/SxHc/ciNafkBAhl6q0xrWwq0FH + WZm0p5AbBX5NKRFWRmeUyxK7AXs8VxdDbiuhZweij87fXET4q2VBv8JxFBzWVjdYJgCK + NZ7Vykqeq+k0PAxi2LXbkgr78AYyT1zO0hOujlxqogVxjcgo9045yl4AcRXl4YWISCBY + /RrAC5PJcTyPKyfNIpet7pyzR0R51trj7WdXvqA9h1wbRMCq1t/8o6mxPEyQC2W4W2m3 + YLXA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:in-reply-to:references:from:date + :message-id:subject:to; + bh=JGVtOIaTFKiMVGL/mCfPlZiQg9JiS170RhunrMDic68=; + b=e6qFV9xUwgyWqN0/qSCXwzS0RxtPy1Rut+1ZafMiQIa/dZ9cNQ1SCRmyPuCnO7N1la + AUOjg/dAPuM3bX8CXCT+MPsccw6+6zqMRJbdfd7ocIMw8USH+Gcq+xw247NrV0sXORWT + WckjHn5MkTU2NvhQwjF2fq4wUdoJilZGjEvBmjUm+uM032VEhyXuUyMloYzZo6yumgIs + SFWMlGYSSgbQG5K8k7QbU7fAnblZZHA8cTILKinht00WjTvdEhzlseGrkwiFv5tK0kTQ + PZsz/ehCdxnn/e9LqOuNkcJPvFy8fiArbnFA2KLQzezWcA69EkJkwy19U97rEK7k/IjA + LvcQ== +X-Gm-Message-State: AEkooutqJDrnayE3zOAxRTJOmCfQvi7cnJyI2Mogqe5s5wRDG00sjd/QL9QfMLQ4V93x4BqSydTyZQ8gyGS2pQ== +X-Received: by 10.157.11.51 with SMTP id a48mr13430315ota.128.1469570621559; + Tue, 26 Jul 2016 15:03:41 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.182.32.231 with HTTP; Tue, 26 Jul 2016 15:03:41 -0700 (PDT) +In-Reply-To: <CACiOHGxpTEOzUBovuJstNEVQOpD+Yv0JivuyeOFsba_jhdyydw@mail.gmail.com> +References: <CACiOHGxpTEOzUBovuJstNEVQOpD+Yv0JivuyeOFsba_jhdyydw@mail.gmail.com> +From: Nick ODell <nickodell@gmail.com> +Date: Tue, 26 Jul 2016 16:03:41 -0600 +Message-ID: <CANN4kmf32ozV=LGbOHrifRiSPX==Mb1uSnjqa2v2c43=HU3OBg@mail.gmail.com> +To: Moral Agent <ethan.scruples@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: text/plain; charset=UTF-8 +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, + RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Subject: Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 26 Jul 2016 22:03:44 -0000 + +Moral, + +Mining the sync flag isn't compatible with the payout structure of non +hot-wallet pools like Eligius or decentralized pools like p2pool. +Those need the ability to split a reward among multiple parties. +Instead of giving an address to send the funds to, you could include +the hash of the transaction allowed to spend the sync flag output. +You'd have to zero the previous outpoint of the transaction before +hashing, since you don't know what the hash of the coinbase ten blocks +from now will be. + + +On Tue, Jul 26, 2016 at 6:47 AM, Moral Agent via bitcoin-dev +<bitcoin-dev@lists.linuxfoundation.org> wrote: +> I posted this to /r/bitcoin yesterday but it got minimal comments. One uses +> suggested I try the mailing list so here it is: +> +> The idea presented here could have the following benefits: +> +> 1. Improve mining decentralization +> 2. Reduce variance in mining profitability +> 3. Reduce or eliminate SPV mined blocks +> 4. Reduce or eliminate empty blocks, smoothing out resource usage +> 5. Reduce or eliminate the latency bottleneck on throughput +> 6. Make transaction stuffing by miners be either obvious or costly +> 7. Gives miners something to do while they wait for attractive transactions +> to appear +> 8. Can be easily done with a soft fork +> +> #Basic idea: +> +> Ideally, all miners would begin hashing the next block at exactly the same +> time. Miners with a head start are more profitable, and the techniques that +> help miners receive and validate blocks quickly create centralization +> pressure. +> +> What if there was something that acted like the starting flag at a race, +> which could suddenly wave and cause all of the miners to simultaneously +> begin hashing the next block? +> +> #Implementation: +> +> Let a sync flag be a message consisting of: +> +> 1. Hash of the previous block. +> 2. Bitcoin address +> 3. Nonce +> +> This tiny message could propagate through the network at maximum speed. If +> miners had to include the hash of this flag in the next block, then all +> miners wait for this flag, and when it suddenly spread through the network, +> all miners could simultaneously begin hashing the next block. +> +> The sync flag should not be produced too quickly. You want to give everyone +> enough time to be ready to hash the next block. Let's say that the hash of +> the sync flag is a proof of work that is targeted for 2 minutes. +> +> To fund this proof of work, the protocol is modified to demand that the +> block produced 10 blocks after the sync flag must allocate 25% of the block +> reward to the address published by the sync flag. In this way, sync flags +> are produced in 2 minutes, and blocks are produced in 8 minutes, with 10 +> minutes total. +> +> +> Illustration 1: https://s32.postimg.org/wzg0hs8lx/sync_flag.png) +> +> Illustration 2: https://s32.postimg.org/vc5y9yz4l/sync_flag2.png +> +> +> #Explanation of reasons: +> +> **Improve mining decentralization** +> +> One factor driving centralization is the imperative miners have to achieve +> low latency in receiving and validating blocks. To achieve low latency, it +> helps a lot if you have expensive low-latency internet connections, curated +> network topologies, and large pools that have a plausible chance of finding +> consecutive blocks. If miners are expected (or forced) to validate a block +> prior to mining on top of it, the rational end game would be to outsource +> the validation step to a trusted third party specialist who can choose +> optimal locations on the globe to serve their (multiple?) mining pool +> clients. These are all less decentralized than the mining situation Satoshi +> and others imagined. +> +> **Reduce variance in mining revenue** +> +> Currently, there are about 144 opportunities per day for a pool or solo +> miner to see any revenue at all. With sync flags, that number doubles to +> 288. Sync flags are only worth 25% of what a block is worth, but this still +> represents a significant reduction in variance. This variance is one factor +> causing solo miners to group into pools, and large pools to be more +> attractive than small pools. +> +> **Reduce or eliminate SPV mined blocks** +> +> One way miners have sought to make +> full-block-transmission-and-validation-latency irrelevant has been through +> "SPV" mining or "Head-first" mining. There is some evidence that these +> techniques may be widely used, and that badgering the miners about it is an +> ineffective strategy to stop them. +> +> In SPV mining, a miner would simply accept any block header that shows the +> correct proof of work. All other validation is entrusted to other miners. +> This practice is quite dangerous as the SPV miners can wander off on some +> invalid chain, taking SPV nodes with them. If this occurs during a soft +> fork, these blind miners can also fool unupgraded fully validating nodes +> into following them. +> +> "Head-first" mining means that miners start hashing as soon as they receive +> the block header with the correct POW, but they simultaneously validate the +> block, and abandon it if is not valid. I consider this to be pretty safe, as +> it strictly limits the length of an invalid chain that can result from +> mining without validating. However, "Head-first" mining can plausibly +> generate 2 or 3 confirmations of an invalid block. It would be nice if such +> confirmations did not happen. +> +> The sync flag technique is similar to head-first mining, but rather than +> hashing the next block while they wait for transmission and validation of +> the prior block, they hash the sync flag. Nodes can differentiate between +> sync flags and blocks, and can ignore sync flags when counting +> confirmations. +> +> **Reduce or eliminate empty blocks, smoothing out resource usage** +> +> Empty blocks are another consequence of SPV or Headfirst mining, because the +> miner cannot safely include any transactions in the block they are hashing +> until they have validated the prior block. By delaying the start of hashing +> the next block until after validation, miners would not have this reason to +> mine empty blocks. +> +> **Reduce or eliminate the latency bottleneck on throughput** +> +> Centralization pressure due to latency issues has been a major preoccupation +> over the last year. If latency mattered much less, it could represent a +> scalability improvement that could enable higher throughput. +> +> **Make transaction stuffing by miners be either obvious or costly** +> +> Currently, the entire block reward goes to the miner who mines it. One +> unfortunate consequence of this is that it does not cost the miner anything +> to covertly stuff the block with transactions. These transactions would pay +> fees and be indistinguishable from ordinary transactions, but the fees are +> paid by the miner and then immediately returned to the miner. +> +> With sync flags, the miner must share these transaction fees with the +> address contained in the sync flag 10 blocks prior. This means that if the +> miner gives the transactions a normal looking fee, they will incur a cost +> that will be paid to the sync flag. If the miner wants to avoid this, they +> must give their stuffing transactions a zero fee, which provides evidence +> that they are stuffing. +> +> Also, when miners stuff with transactions using a zero fee, they cannot +> manipulate the perception of how much fee it takes to get into a block. +> +> Note that miners could still try to covertly stuff blocks that will pay a +> sync flag that they themselves created. if this is a big concern, it can be +> addressed by forcing blocks to pay multiple sync flags. +> +> **Gives miners something to do while they wait for attractive transactions +> to appear** +> +> From the Montreal scaling workshop last year, we have [this +> talk](https://scalingbitcoin.org/montreal2015/presentations/Day1/13-miles-carlsten-Mind-the-Gap.pdf) +> which worried that as the block subsidy reduced and transactions became a +> more important fraction of miner revenue, it would be rational for miners to +> turn off their mining equipment for a "gap" phase after a block is found, to +> allow time to pass as more lucrative transactions entered the mempool. +> +> I don't know whether this will actually happen. The presence of a suitable +> backlog of transactions would help prevent this dynamic from emerging. But +> if such idling behavior was the optima mining strategy, it could create a +> serious vulnerability. Idle hands are the devil's workshop as the saying +> goes, and idle miners represent a pool of inert hashpower that is available +> to rent for all kinds of destabilizing purposes. It would be better to put +> those miners to profitable work mining a sync flag while they wait. +> +> Also, this creates a more efficient price discovery mechanism for +> transactions, because you allow transactions paying high fees time to arrive +> to the marketplace, rather than take whatever anyone is offering because all +> the "good" transactions got gobbled up in the prior block. +> +> **Can be easily done with a soft fork** +> +> Although a hard fork would be more efficient, sync flags could be easily +> implemented using a soft fork by introducing the following rule: +> +> Every block must include a transaction which pays 25% of the block reward to +> the address given by the 10th previous sync flag, and commits to the hash of +> the 1st previous sync flag. +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + |