From: Stephen Pair <stephen@bitpay.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
Date: Thu, 14 Feb 2013 00:36:09 -0500 [thread overview]
Message-ID: <CADb9v0JAhJG_KBcuDC2Vr-01wgaQzH5+gXD+LCKr+QqSaKdjPg@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgTNQZkUo3k4Uke7sLrZd1=o2TO1BLtdA6_Q7hUegHRQHQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4253 bytes --]
On Wed, Feb 13, 2013 at 10:38 PM, Gregory Maxwell <gmaxwell@gmail.com>wrote:
> On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair <stephen@bitpay.com> wrote:
> >(by which I mean the fee or cost associated with the bandwidth and
> validation that a transaction requires) with some amount of profit. This
> means that the relay node will not fetch and propagate those transactions
> whose fee is too small (unless there was some other fee structure outside
> the miners fee).
>
> The only fee-or-cost they're worrying about is their own marginal
> costs. This says nothing about the externalized cost of the hundreds
> of thousands of other nodes which also must validate the block they
> produce, many of which are not miners— if we are well distributed— and
> thus don't have any way to monetize fees.
But this is exactly the point I'm making...the thousands of other nodes do
have a way to monetize the work they do in relaying and validating
transactions. Miners will pay them for the prompt delivery of profitable
transactions. So, in effect, the block reward and transactions fees will
be paying not only for the mining work, but also the validation and
relaying work. Such nodes would get paid in micro transactions from the
miners for that service. This would be one way that full nodes could
operate profitably (there may be many other indirect ways). I think
decentralization is pretty much guaranteed because anyone with profitable
transactions would only deliver them to miners or other peers that are
willing to pay for them. This is in effect a rebate of a portion of the
transaction fee to the network for delivering the transaction to the miner.
Wallet software might cut out the middle men and submit directly to
miners...other nodes with access to a large amounts of transactions and
good infrastructure might be able to reduce the infrastructure a miner has
to maintain and deliver a larger volume of fee bearing transactions. And
everyone would have a very good sense of the market price for transaction
fees for a given level of service (speed of block inclusion).
The other side of it is that wallets will need to receive valid, wallet
relevant transactions. They may also need to connect with multiple nodes
for independent verification of the validity of their transactions. But I
think that cost would be more than covered with fees they include in any
transactions they originate (but if they rarely originate fee bearing
transactions, they might need to pay something to keep receiving an
incoming transaction feed...it could be as simple as an artificial
transaction they pay to themselves, but that includes a fee).
A while back everyone was worried that a tragedy of the commons situation
would develop whereby all transactions that carried any fee at all would
get included by miners, thus destroying the mining business as the block
reward diminished...but I think the cost involved in relaying and
validating transactions ensures that situation won't develop...mining nodes
will have to only connect to relaying and validating nodes such that they
can filter down the volume to something that's profitable for them...and
relaying and validating nodes will ignore transactions with fees that are
too low to be profitable.
It will be a few years before we see the kinds of volumes that will force
this infrastructure to evolve...I don't think there is an issue with
lifting or even eliminating the block size limit...there may be a point at
which the volume is sufficient enough that full nodes start dropping
offline...and the nodes that do remain will have to increasingly find ways
to cover their costs...which will be a forcing function for solutions
similar to these. There is no doubt that Bitcoin will be a lot more
valuable if it can handle very large volumes of transactions.
Also, Mike Hearn has done some analysis that suggests that even at Visa
scales, the hardware requirements to do full validation and relay may not
all that substantial (enabling lots of small, but profitable, node
operators and low transactions fees...the key to profitability would be
access to a sufficient number of original transactions bearing fees).
[-- Attachment #2: Type: text/html, Size: 5421 bytes --]
next prev parent reply other threads:[~2013-02-14 5:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 13:49 [Bitcoin-development] Incorporating block validation rule modifications into the block chain Raph Frank
2013-02-12 15:49 ` Gregory Maxwell
2013-02-13 14:58 ` Raph Frank
2013-02-13 15:42 ` Gregory Maxwell
2013-02-13 21:02 ` Gavin Andresen
2013-02-13 21:05 ` Gregory Maxwell
2013-02-13 23:10 ` Stephen Pair
2013-02-14 0:28 ` Gregory Maxwell
2013-02-14 2:44 ` Stephen Pair
2013-02-14 3:38 ` Gregory Maxwell
2013-02-14 5:36 ` Stephen Pair [this message]
2013-02-14 6:07 ` Peter Todd
2013-02-14 12:59 ` Stephen Pair
2013-02-18 16:22 ` Peter Todd
2013-02-14 1:02 ` Gregory Maxwell
2013-02-14 6:39 ` Peter Todd
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=CADb9v0JAhJG_KBcuDC2Vr-01wgaQzH5+gXD+LCKr+QqSaKdjPg@mail.gmail.com \
--to=stephen@bitpay.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=gmaxwell@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