From: Stephen Pair <stephen@bitpay•com>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
Date: Wed, 13 Feb 2013 18:10:21 -0500 [thread overview]
Message-ID: <CADb9v0L9RgfK8=FaM-tZm7AcYMhP6+OAyWu4x+3pLrrQ8yoeLw@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T2RWamFxebVJExo_4NT4WPPE=Fd4deG1AFmT=GqjD=vwQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3549 bytes --]
On Wed, Feb 13, 2013 at 4:02 PM, Gavin Andresen <gavinandresen@gmail•com>wrote:
> On Wed, Feb 13, 2013 at 10:42 AM, Gregory Maxwell <gmaxwell@gmail•com>wrote:
>
>> Since, in the long run,
>> Bitcoin can't meet its security and decenteralization promises without
>> blockspace scarcity to drive non-trivial fees and without scaling
>> limits to keep it decenteralized— it's not a change that could be made
>> more lightly than changing the supply of coin.
>>
>
> I disagree with Gregory on this. I believe that Bitcoin CAN meet its
> security and decentralization promises without any hard limit on block
> size.
>
> I had a fruitful discussion about this with an economist friend this
> weekend, and I'll eventually getting around to writing up why I believe
> raising the block size limit will not be a problem.
If you've already validated the majority of transactions in a block, isn't
validating the block not all that compute intensive? Thus, it's really not
blocks that should be used to impose any sort of scarcity, but rather it's
the costs associated with the validation and propagation of the
transactions themselves...which is the way it should be.
When I think about issues like this, I like to remind myself that the mesh
network isn't really an essential part of Bitcoin. It is a way to
disseminate transactions and blocks, but it's by no means the only possible
way and could certainly be improved in various ways. Nodes can at some
point start to charge fees to collect and distribute transactions and
blocks. Collectives of such nodes could pool together fees to ensure
connected nodes can propagate and hear about transactions and blocks.
These nodes would charge based on the bandwidth and the work required to
validate transactions. They would also charge for the propagation of
blocks based on the work required to validate them. Miners would of course
have a lot of incentive to pay for such services since they will want to
get access to as many fee bearing transactions as possible (and filter out
the transactions they don't want to include in blocks). They will also
want the blocks to ensure they're always building on the latest valid
block. That in turn would give these relay nodes a window into the fees
needed to ensure fast inclusion into the block chain (something that
wallets could use to automatically set fees on transactions).
Note, I think the bitcoin protocol might actually be ideally suited for
this type of thing...nodes would broadcast INV messages all day long, but
as soon as one of your peers wants the actual transaction or block, well,
then you have to pay up. Two relay nodes sending transactions between each
other would pay each other when they have to download the transaction
body...if they trade roughly equal amounts of transactions, they wouldn't
end up owing each other anything...for a given transaction they would pull
the data exactly, but would then turn around and provide that transaction
to many connected peers, earning a fee for each delivery.
P.S. such a fee structure would address the spam issue with economics
rather than rules about spammy transactions
P.P.S. micropayment channels could be used as the payment method for nodes
that validate and relay transactions...this would actually be a very good
first use of that technology (people have talked about micropayment
channels for renting bandwidth...why not use them to pay for the bandwidth
and CPU needed to validate and relay transactions)
[-- Attachment #2: Type: text/html, Size: 5150 bytes --]
next prev parent reply other threads:[~2013-02-14 0:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 13:49 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 [this message]
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
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='CADb9v0L9RgfK8=FaM-tZm7AcYMhP6+OAyWu4x+3pLrrQ8yoeLw@mail.gmail.com' \
--to=stephen@bitpay$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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