diff options
| author | Daniel Stadulis <dstadulis@gmail.com> | 2015-10-14 20:35:59 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-15 03:36:20 +0000 |
| commit | 7d8553e6b59df33b1b55fcef426ce486631ad020 (patch) | |
| tree | b3e9cad68df01b418a1a9ac96c10afd57b99c2c5 | |
| parent | cc0d553b9ecd5795207e9971fe42bed48de64a11 (diff) | |
| download | pi-bitcoindev-7d8553e6b59df33b1b55fcef426ce486631ad020.tar.gz pi-bitcoindev-7d8553e6b59df33b1b55fcef426ce486631ad020.zip | |
Re: [bitcoin-dev] Lightning Network's effect on miner fees
| -rw-r--r-- | 6e/e04c59aa493f5b32f5fed839712b08835961b3 | 274 |
1 files changed, 274 insertions, 0 deletions
diff --git a/6e/e04c59aa493f5b32f5fed839712b08835961b3 b/6e/e04c59aa493f5b32f5fed839712b08835961b3 new file mode 100644 index 000000000..950fc4f83 --- /dev/null +++ b/6e/e04c59aa493f5b32f5fed839712b08835961b3 @@ -0,0 +1,274 @@ +Return-Path: <dstadulis@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id CFBF2258 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 15 Oct 2015 03:36:20 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-io0-f169.google.com (mail-io0-f169.google.com + [209.85.223.169]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C58AF79 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 15 Oct 2015 03:36:19 +0000 (UTC) +Received: by iow1 with SMTP id 1so77332363iow.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 14 Oct 2015 20:36:19 -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 + :cc:content-type; + bh=Vrup2elBMeasoF/VLxXWSLc1aaYZ5yjiL3MizMSLMuA=; + b=LqEdyirX4a6AeQqeARfysO6wySTF/xHGilZk/5EarD+Br2LzStnV327oc2dkbOY7gP + SCw3WMnFwGw1yfWHszqpi4WC0YjFKLC+YzWX8B+uYjCixEH2/xRWp7/NsAYGKcFNDLmc + 506SqtLr6WPoUlA8N8oeRp2PMIFUSIj6Ki5OKcACON328TIYoq9/mWVBdv3Fv7G6wmgv + vLepnyUC0ljDPKhUmvw2YlZ5ooXa19PSrGlHpqc3ebofJC3vs01Pc9N6qPz78dnuseO5 + Eu8yE6KNBYxjRFUAh1EVUOcq0/+/gcJtYBpFEhnsiNOl72CfP+FrjltnkR+YdeQBzKIO + iovA== +X-Received: by 10.107.157.80 with SMTP id g77mr7227395ioe.118.1444880179224; + Wed, 14 Oct 2015 20:36:19 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.107.30.210 with HTTP; Wed, 14 Oct 2015 20:35:59 -0700 (PDT) +In-Reply-To: <CABaSBazTE5r5Xvw8M3DRF+d-Qd6KXbdW8W1E0DPmw5KzfY1j6w@mail.gmail.com> +References: <561E2B09.3090509@sky-ip.org> <561E7283.2080507@gmail.com> + <CABaSBazTE5r5Xvw8M3DRF+d-Qd6KXbdW8W1E0DPmw5KzfY1j6w@mail.gmail.com> +From: Daniel Stadulis <dstadulis@gmail.com> +Date: Wed, 14 Oct 2015 20:35:59 -0700 +Message-ID: <CAHpxFbG2AKsg=SAx_CL2mcJYzOXsZN4iodROLWBEjrXQ8zxFpg@mail.gmail.com> +To: Bryan Bishop <kanzure@gmail.com> +Content-Type: multipart/alternative; boundary=001a11407d66d364d605221c616f +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Lightning Network's effect on miner fees +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development 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: Thu, 15 Oct 2015 03:36:20 -0000 + +--001a11407d66d364d605221c616f +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +It makes economic sense to include a transaction on the Lightning Network, +iff the the fee to include the transaction on the blockchain is more than +than the Time Value of Money of the encumbered funds on the Lightening +Nodes amortized across the number of users pushing funds through a LN node. + +Large-value transactions are going to hit the blockchain while smaller, +predictable, closer-to-median transaction-rates transactions will go into +the Lightning Network + +Blockchain: Car Purchase, House Purchase, Unexpected Medical Expense +Lightning Network: Utility Bill, Groceries, Rent, Mortgage. + +> If transactions happen in a big percent offchain, and they are only +> broadcasted on the mainchain where funds are moved in or out of the +> lightning network, this means there will be less transactions on the +> mainchain + +This is optimal because the network has minimized the set of +costs/externalities to the minimum necessary to conduct a series of +transactions +> -> less fees collected by the miners. +=E2=80=9CIt's tough to make predictions, especially about the future.=E2=80= +=9D +The effect on fees is going to be hard to predict. +1.) One part depends on user behavior around the dynamics of bid-side +demand of fees. I.e. If there is a health ratio of +-users who want 1-block- times but are unwilling/unable to bid up the fee +of their transactions to push out other 1-block-confirmation transactions (= +AKA +how firm is that fee support presently and under dynamic conditions) +to +-users who take their transactions off the blockchain to LN + +2.) New classes of transactions will be possible that aren't possible today= +. + +3.) What market effect will the financial/technical potential of 'instant' +transaction (after a network-joining-intro period) have on Bitcoin's +utility/price/adoption? + +It would be elucidating if any blockchain data scientists could study the +effect of the fee market when high-volume exchanges unexpectedly halted +trading. + + +> What will happen when the block reward will go away? +I believe a more specific question to ask is: What will happen when there +isn't a convincing economic reason for a large majority of hashing power to +be bolstering PoW defense on the main blockchain? Right now we have a +pretty good handle on the amount of hashing power that's pointed at +extending/defending the 'main' chain but don't have as good intel on how +much idle hashing power there is. Idle hashing power becomes more of a +threat in market scenarios where chain-extending PoW is scarce (late-game +Bitcoin). + +My humble prediction is that the necessary number of block confirmation +will go up and there were be non negligible mining power idle ready to +defend actors' preferred chain. If this is the scenario that plays out, I +don't think it'll be very concerning; large-value transaction that will be +on the blockchain have more flexible time-settlement tolerance (no one +needs their home-buying escrow to settle in <=3D 1 day) and lower-value +transaction that users want/need to be confirmed quickly will be confirmed +'instantly' over Lightning Network or another Bitcoin-anchored protocol. + +P.S. I see lots of concern with respect to fee reduction directed at LN +while today there are already off-chain databases that remove fee +pressure. Like the LN / off-chain databases or not, they will exists. + +Daniel Stadulis + + +On Wed, Oct 14, 2015 at 8:37 AM, Bryan Bishop via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> On Wed, Oct 14, 2015 at 10:19 AM, Paul Sztorc via bitcoin-dev +> <bitcoin-dev@lists.linuxfoundation.org> wrote: +> > However, the two are also perfect compliments, as LN transactions canno= +t +> take place at all without periodic on-chain transactions. +> +> Additionally, lightning network hot wallets are not an ideal place to +> store large quantities of BTC and users that don't expect to be +> actively using LN should in general prefer confirmed UTXOs for +> long-term cold storage. So far the guess that I have seen floating +> around is that LN usage will at first be restricted to very tiny +> amounts of BTC in tiny hot wallets, since nobody is particularly +> interested in running large hot wallets. +> +> - Bryan +> http://heybryan.org/ +> 1 512 203 0507 +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--001a11407d66d364d605221c616f +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>It makes economic sense to include a transaction on t= +he Lightning Network, iff the the fee to include the transaction on the blo= +ckchain is more than than the Time Value of Money of the encumbered funds o= +n the Lightening Nodes amortized across the number of users pushing funds t= +hrough a LN node.</div><div><br></div><div>Large-value transactions are goi= +ng to hit the blockchain while smaller, predictable, closer-to-median trans= +action-rates transactions will go into the Lightning Network</div><div><br>= +</div><div>Blockchain: Car Purchase, House Purchase, Unexpected Medical Exp= +ense</div><div>Lightning Network: Utility Bill, Groceries, Rent, Mortgage.<= +/div><div><br></div><div><span style=3D"font-size:12.8px">> If transacti= +ons happen in a big percent offchain, and they are only</span><br style=3D"= +font-size:12.8px"><span style=3D"font-size:12.8px">>=C2=A0</span><span s= +tyle=3D"font-size:12.8px">broadcasted on the mainchain where funds are move= +d in or out of the</span><br style=3D"font-size:12.8px"><span style=3D"font= +-size:12.8px">>=C2=A0</span><span style=3D"font-size:12.8px">lightning n= +etwork, this means there will be less transactions on the</span><br style= +=3D"font-size:12.8px"><span style=3D"font-size:12.8px">>=C2=A0</span><sp= +an style=3D"font-size:12.8px">mainchain</span></div><div><span style=3D"fon= +t-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">This = +is=C2=A0optimal=C2=A0because the network has minimized the set of costs/ext= +ernalities to the minimum necessary to conduct a series of transactions</sp= +an></div><div><span style=3D"font-size:12.8px">></span><span style=3D"fo= +nt-size:12.8px">=C2=A0</span><span style=3D"font-size:12.8px">=C2=A0-> l= +ess fees collected by the miners.</span></div><div><span style=3D"font-size= +:12.8px">=E2=80=9CIt's tough to make predictions, especially about the = +future.=E2=80=9D</span><br></div><div><span style=3D"font-size:12.8px">The = +effect on fees is going to be hard to predict. =C2=A0</span></div><div><spa= +n style=3D"font-size:12.8px">1.) One part depends on user behavior around t= +he dynamics of bid-side demand of fees. I.e. If there is a health ratio of= +=C2=A0</span></div><div><span style=3D"font-size:12.8px">-</span><span styl= +e=3D"font-size:12.8px">users=C2=A0</span><span style=3D"font-size:12.8px">w= +ho want 1-block- times but are unwilling/unable to bid up the fee of their = +transactions to push out other 1-block-confirmation transactions (</span><s= +pan style=3D"font-size:12.8px">AKA how firm is that fee support presently a= +nd under dynamic conditions)</span></div><div><span style=3D"font-size:12.8= +px">to</span></div><div><span style=3D"font-size:12.8px">-users who take th= +eir transactions off the blockchain to LN</span></div><div><span style=3D"f= +ont-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">2.)= + New classes of transactions will be possible that aren't possible toda= +y.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div>= +<span style=3D"font-size:12.8px">3.) What market effect will the financial/= +technical potential of 'instant' transaction (after a network-joini= +ng-intro period) have on Bitcoin's utility/price/adoption?</span></div>= +<div><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"= +font-size:12.8px">It would be=C2=A0elucidating=C2=A0if any blockchain data = +scientists could study the effect of the fee market when high-volume exchan= +ges=C2=A0unexpectedly halted trading.</span></div><div><span style=3D"font-= +size:12.8px"><br></span></div><div><br></div><div><span style=3D"font-size:= +12.8px">></span><span style=3D"font-size:12.8px">=C2=A0What will happen = +when=C2=A0</span><span style=3D"font-size:12.8px">the block reward will go = +away?=C2=A0</span></div><div><span style=3D"font-size:12.8px">I believe a m= +ore specific question to ask is: What will happen when there isn't a co= +nvincing economic reason for a large majority of hashing power to be bolste= +ring PoW defense on the main blockchain?=C2=A0 Right now we have a pretty g= +ood handle on the amount of hashing power that's pointed at extending/d= +efending the 'main' chain but don't have as good intel on how m= +uch idle hashing power there is.=C2=A0 Idle hashing power becomes more of a= + threat in market scenarios where chain-extending=C2=A0PoW is=C2=A0scarce (= +late-game Bitcoin).</span></div><div><span style=3D"font-size:12.8px"><br><= +/span></div><div><span style=3D"font-size:12.8px">My humble prediction is t= +hat the necessary number of block confirmation will go up and there were be= + non negligible=C2=A0mining power=C2=A0idle ready to defend actors' pre= +ferred chain.=C2=A0 If this is the scenario that plays out, I don't thi= +nk it'll be very concerning; =C2=A0large-value transaction that will be= + on the blockchain have more flexible time-settlement tolerance (no one nee= +ds their home-buying escrow to settle in <=3D 1 day) and lower-value tra= +nsaction that users want/need to be confirmed quickly will be confirmed = +9;instantly' over Lightning Network or another Bitcoin-anchored protoco= +l.</span></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext= +ra">P.S. I see lots of concern with respect to fee reduction directed at LN= + while today there are already off-chain databases that remove fee pressure= +.=C2=A0 Like the LN / off-chain databases or not, they will exists.<br></di= +v><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Daniel St= +adulis</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"= +><br><div class=3D"gmail_quote">On Wed, Oct 14, 2015 at 8:37 AM, Bryan Bish= +op via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@list= +s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.= +org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar= +gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2= +04);border-left-style:solid;padding-left:1ex"><span class=3D"">On Wed, Oct = +14, 2015 at 10:19 AM, Paul Sztorc via bitcoin-dev<br> +<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li= +sts.linuxfoundation.org</a>> wrote:<br> +> However, the two are also perfect compliments, as LN transactions cann= +ot take place at all without periodic on-chain transactions.<br> +<br> +</span>Additionally, lightning network hot wallets are not an ideal place t= +o<br> +store large quantities of BTC and users that don't expect to be<br> +actively using LN should in general prefer confirmed UTXOs for<br> +long-term cold storage. So far the guess that I have seen floating<br> +around is that LN usage will at first be restricted to very tiny<br> +amounts of BTC in tiny hot wallets, since nobody is particularly<br> +interested in running large hot wallets.<br> +<br> +- Bryan<br> +<a href=3D"http://heybryan.org/" rel=3D"noreferrer" target=3D"_blank">http:= +//heybryan.org/</a><br> +<a href=3D"tel:1%20512%20203%200507" value=3D"+15122030507">1 512 203 0507<= +/a><br> +<div class=3D""><div class=3D"h5">_________________________________________= +______<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</div></div></blockquote></div><br></div></div> + +--001a11407d66d364d605221c616f-- + |