Stephen Pair [ARCHIVE] on Nostr: đź“… Original date posted:2013-02-13 đź“ť Original message:On Wed, Feb 13, 2013 at ...
đź“… Original date posted:2013-02-13
đź“ť Original message:On Wed, Feb 13, 2013 at 4:02 PM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> On Wed, Feb 13, 2013 at 10:42 AM, Gregory Maxwell <gmaxwell at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130213/a4103e2a/attachment.html>;
đź“ť Original message:On Wed, Feb 13, 2013 at 4:02 PM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> On Wed, Feb 13, 2013 at 10:42 AM, Gregory Maxwell <gmaxwell at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130213/a4103e2a/attachment.html>;