public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Daniel Stadulis <dstadulis@gmail.com>
To: Bryan Bishop <kanzure@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Lightning Network's effect on miner fees
Date: Wed, 14 Oct 2015 20:35:59 -0700	[thread overview]
Message-ID: <CAHpxFbG2AKsg=SAx_CL2mcJYzOXsZN4iodROLWBEjrXQ8zxFpg@mail.gmail.com> (raw)
In-Reply-To: <CABaSBazTE5r5Xvw8M3DRF+d-Qd6KXbdW8W1E0DPmw5KzfY1j6w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4458 bytes --]

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.
“It's tough to make predictions, especially about the future.”
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 <= 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 cannot
> 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
>

[-- Attachment #2: Type: text/html, Size: 7216 bytes --]

  reply	other threads:[~2015-10-15  3:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-14 10:14 [bitcoin-dev] Lightning Network's effect on miner fees s7r
2015-10-14 15:19 ` Paul Sztorc
2015-10-14 15:37   ` Bryan Bishop
2015-10-15  3:35     ` Daniel Stadulis [this message]
2015-10-14 22:37   ` s7r
2015-10-14 23:42     ` Daniel Newton
2015-10-14 23:55     ` Paul Sztorc

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='CAHpxFbG2AKsg=SAx_CL2mcJYzOXsZN4iodROLWBEjrXQ8zxFpg@mail.gmail.com' \
    --to=dstadulis@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=kanzure@gmail.com \
    /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