* [Bitcoin-development] Incorporating block validation rule modifications into the block chain
@ 2013-02-12 13:49 Raph Frank
2013-02-12 15:49 ` Gregory Maxwell
0 siblings, 1 reply; 16+ messages in thread
From: Raph Frank @ 2013-02-12 13:49 UTC (permalink / raw)
To: bitcoin-development
Has this been considered?
If made sufficiently general, older clients could support any
extension of the rules.
Various "hard" parameters within the protocol are defined in main.h of
the official client.
In BIP-34, there is a suggested way to make changes, based on consensus.
https://en.bitcoin.it/wiki/BIP_0034
These could be made into a rule for changing the parameters directly.
The process for updating could be handled by adding a new field to the
coinbase transaction, in the same way the height was added in BIP-34.
Something like
- miner proposed a change by by including proposal in a block (name of
parameter and new value)
- seconded by at least 6 of the next 10 blocks (proposal dies otherwise)
- active if 750 of the last 1000 blocks voted yes, or 950 of any
successive 1000 previous blocks voted yes (with reduced thresholds on
testnet)
- dies if more than 500 of the previous 1000 voted No
- blocks which don't reference the proposal are considered to abstain
This could also be used to update NOPs. Complex signing algorithms
could be incorporated. However, that would require a more complex
scripting language for defining opcode functions. The proposal would
have opcode number + script description of algorithm. This would also
allow methods <method name> + <script code>. Once of the NOPs could
be "call method".
The rule would require that the script is valid under the current
rules (NOPs as nops) and under the latest rules. This prevents
needing to try all possible permutations. However, it reduces
security.
An compromise would be to have each new opcode change could as a
version and scripts must be valid under all versions in the chain, so
far.
Once an op-code is accepted, new clients implementations would
probably create dedicated functions for performing the calculation.
Older clients would have to perform the calculations using the
scripting language.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
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
0 siblings, 1 reply; 16+ messages in thread
From: Gregory Maxwell @ 2013-02-12 15:49 UTC (permalink / raw)
To: Raph Frank; +Cc: bitcoin-development
On Tue, Feb 12, 2013 at 5:49 AM, Raph Frank <raphfrk@gmail•com> wrote:
> Has this been considered?
>
> If made sufficiently general, older clients could support any
> extension of the rules.
>
> Various "hard" parameters within the protocol are defined in main.h of
> the official client.
>
> In BIP-34, there is a suggested way to make changes, based on consensus.
> https://en.bitcoin.it/wiki/BIP_0034
You misunderstand what BIP_0034 is doing— it's not gauging consensus,
it's making sure that the change is safe to enforce. This is a subtle
but important difference. The mechanism happens to be the same, but
we're not asking for anyone's approval there— the change is needed to
make Bitcoin as secure as people previously believed it to be, there
have been no serious alternatives tendered. As far as I can tell the
proposal has always had universal agreement from anyone who's thought
about it. The only open question was if it was safe to deploy, and
thats what that process solves.
Bitcoin is not a democracy— it quite intentionally uses the consensus
mechanism _only_ the one thing that nodes can not autonomously and
interdependently validate (the ordering of transactions). This
protects the users of Bitcoin by making most of the system largely
nonvolatile "constitutional" rules instead of being controlled by
popular whim where 'two wolves may vote to have the one sheep for
dinner'. If it were possible to run the whole thing autonomously it
would be, but alas...
Even if you accept the premise that voting is a just way of making
decisions (it isn't; it's just often the least unjust when something
must be done), mining is not a particularly just way of voting:
'Hashpower isn't people', and currently the authority to control the
majority of the hashpower is vested in a only a half dozen people.
Moreover, the incentives to abuse hashpower are sharply curtailed by
its limited authority (all one can do with it is reorder
transactions... which is powerful but still finite) and allowing
arbitrary rule changes would vastly increase that power.
There are some more subtle issues— if the acceptance of chain B
depends on if you've seen orthogonal chains A or A' first then there
can be a carefully timed announcement of A and A' which forever
prevents global convergence (thanks to a finite speed of light an
attacker can make sure some nodes see A first, some A'). If a rule
change can be reorged out, then it's not really a rule— any actual
rule prohibits otherwise valid blocks that violate it (and without
this distinction you might as well implement the 'rule' as miner
preferences). Additionally there is the very hard software engineering
QA problem for a sufficiently complex rule language— script isn't
turing complete and look at all the issues it has had.
In summary— this sort of thing, which has come up before, is
technically interesting and fun to think about but it would make for
substantial engineering challenges and would not be obviously
compatible with the economic motivations which make Bitcoin secure nor
would it be morally compatible with the social contract embedded in
the system today.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
2013-02-12 15:49 ` Gregory Maxwell
@ 2013-02-13 14:58 ` Raph Frank
2013-02-13 15:42 ` Gregory Maxwell
0 siblings, 1 reply; 16+ messages in thread
From: Raph Frank @ 2013-02-13 14:58 UTC (permalink / raw)
To: bitcoin-development
On Tue, Feb 12, 2013 at 3:49 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> You misunderstand what BIP_0034 is doing— it's not gauging consensus,
> it's making sure that the change is safe to enforce. This is a subtle
> but important difference.
Sounds reasonable.
The change in BIP-34 doesn't cause old client to reject the main chain.
The increase to the maximum block size would be rejected by old
clients, so is different.
Adding new opcodes (as long as they act like a NOP on success) also
doesn't cause a disagreement about what is the longest chain, in the
end. Miners might end up mining chains which are guaranteed to be
orphaned at worst.
> Bitcoin is not a democracy— it quite intentionally uses the consensus
> mechanism _only_ the one thing that nodes can not autonomously and
> interdependently validate (the ordering of transactions).
So, how is max block size to be decided then?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
2013-02-13 14:58 ` Raph Frank
@ 2013-02-13 15:42 ` Gregory Maxwell
2013-02-13 21:02 ` Gavin Andresen
2013-02-14 1:02 ` Gregory Maxwell
0 siblings, 2 replies; 16+ messages in thread
From: Gregory Maxwell @ 2013-02-13 15:42 UTC (permalink / raw)
To: Raph Frank; +Cc: bitcoin-development
On Wed, Feb 13, 2013 at 6:58 AM, Raph Frank <raphfrk@gmail•com> wrote:
>> Bitcoin is not a democracy— it quite intentionally uses the consensus
>> mechanism _only_ the one thing that nodes can not autonomously and
>> interdependently validate (the ordering of transactions).
> So, how is max block size to be decided then?
In one sense it already is decided— there is a protocol rule
implementing a hard maximum, and soft rules for lower targets. If
it's to be changed it would only be by it being obvious to almost
everyone that it should _and_ must be. 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 hope that should it become necessary to do so that correct path will
be obvious to everyone, otherwise there is a grave risk of undermining
the justification for the confidence in the immutability of any of the
rules of the system.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
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 1:02 ` Gregory Maxwell
1 sibling, 2 replies; 16+ messages in thread
From: Gavin Andresen @ 2013-02-13 21:02 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
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.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1095 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
2013-02-13 21:02 ` Gavin Andresen
@ 2013-02-13 21:05 ` Gregory Maxwell
2013-02-13 23:10 ` Stephen Pair
1 sibling, 0 replies; 16+ messages in thread
From: Gregory Maxwell @ 2013-02-13 21:05 UTC (permalink / raw)
To: Gavin Andresen; +Cc: bitcoin-development
On Wed, Feb 13, 2013 at 1: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.
That would be fantastic.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
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
1 sibling, 1 reply; 16+ messages in thread
From: Stephen Pair @ 2013-02-13 23:10 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
2013-02-13 23:10 ` Stephen Pair
@ 2013-02-14 0:28 ` Gregory Maxwell
2013-02-14 2:44 ` Stephen Pair
0 siblings, 1 reply; 16+ messages in thread
From: Gregory Maxwell @ 2013-02-14 0:28 UTC (permalink / raw)
To: Stephen Pair; +Cc: Bitcoin Dev
On Wed, Feb 13, 2013 at 3:10 PM, Stephen Pair <stephen@bitpay•com> wrote:
> 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.
The cost to whom? This is important because the cost of validating
blocks is borne by all the participants in Bitcoin— or at least all
the participants who haven't given up on the decenteralized trustless
stuff and are simply trusting someone else. Even a small cost
becomes large when hundreds of thousands.
And perhaps you don't lament people delegating their trust to large
entities— but keep in mind: Bitcoin was created for the express
purpose of creating a money system which didn't require trust because
it was based on cryptographic proof— mathematical law— instead of
politics and human law. Take that away and you have a really poorly
understood inefficient system operated by entities which are less
trustworthy and rightfully entitled to authority than the ones
operating the established major currencies.
> When I think about issues like this, I like to remind myself that the mesh network isn't really an essential part of Bitcoin.
Thats absolutely true— but I don't know that it's relevant in this case.
> Nodes can at some point start to charge fees to collect and distribute transactions and blocks.
They can— but doing so would radically undermine Bitcoin.
A refresher:
If you combine digital signatures with simple transaction rules you
can have a purely autonomous monetary system based entirely on math.
It would be perfect, anonymous, scalable ... except for the problem
of double spending. To solve double spending the participants must
agree on which of a set of duplicated payments is one the
authoritative one. Coming to this agreement is fundamentally hard just
at the basics of physics— a result of relativity is that observers
will perceive events in different orders depending on the observer's
and the events relative locations. If no observer is privileged (a
decenteralized system) you have to have a way of reaching a consensus.
This kind of efficient consensus we need— which which participants can
join or enter at any time, which doesn't require exponential
communication, and which is robust against sock-puppet participants—
was long believed to be practically impossible. Bitcoin solved the
problem by using hashcash to vote— because real resources were forever
expended in the process the sock-puppet problem is solved. But the
vote only works if everyone can see the results of it: We assume that
the majority of hashpower isn't a dishonest party, and that honest
nodes can't be prevented from hearing the honest history. Nodes choose
then rules-valid history that has the most work (votes) expended on
it... but they can only choose among what they know of. As Satoshi,
wrote: "[Bitcoin] takes advantage of the nature of information being
easy to spread but hard to stifle".
The requirement for everyone to hear the history doesn't get talked
about much— at least with reasonably sized blocks and today's
technical and common political climates the assumption that
information is easy to spread but hard to stifle is a very sound one.
It's a good thing, because this assumption is even more important than
the hash-power honesty assumption (a malicious party with a simple
majority of hashpower is much weaker than one who can partition the
network). ... but that all goes out the window if communicating
blocks is costly enough that the only way to sustain it is to
jealously guard and charge for access/forwarding.
The consequence of such a change is that the Bitcoin consensus
algorithm would be handicapped. How long must you wait before you know
that the history you have won't get replaced by a more authoritative
one? Today an hour or two seems relatively solid. In a world with
non-uniform block forwarding perhaps it takes days— if ever— before
any participant is confident that there isn't a better history
lurking.
All doubly so if the bookkeeping required for this payment ends up
necessitating additional transactions and adds to the load.
[This is also the flaw in the 'Red Balloons' paper, making
transactions a dozen times longer just to attach credit for forwarding
doesn't seem wise compared to keep transactions so cheap to transmit
that even a small number of altruists make the equilibrium state be
liberally-forwarding]
> They would also charge for the propagation of blocks based on the work required to validate them.
Large miners would obviously locate and connect to each other. Even
enormous blocks are no problems for big industrial players.
Don't want to pay the cost to get their big blocks from them? Your
loss: If you don't take their blocks and they constitute the longest
history, you'll be believing the wrong history until such a time as
you wise up and pay the piper. Your transactions will be reversed and
you'll lose money.
You can hypothesize some cartel behavior external to the rules of the
system— where by some consensus mechanism (????) some super large mass
of participants agree to reject blocks according 'extrajudicial
rules', some rule existing outside of Bitcoin itself— but there must
be a consensus because rejecting blocks by yourself only gets you
ripped off.
I don't see how this works— it basically embeds another hard consensus
problem (what is the criteria for blocks to be valid?) inside our
solution to a hard consensus problem (which are the best valid
blocks?), but doesn't benefit from the same incentive structure—
locally-greedy miners obviously want to produce the largest blocks
possible— and in hashpower consensus non-miners don't have a voice.
That might be acceptable for ordering, but now you're deciding on the
rules of the system which all non-trusting participants must validate.
You could instead solve that consensus problem with politically
stipulated regulation or industry cartels, or good old-fashion kneecap
busting or whathave you. But then Bitcoin loses the transparency and
determinism that make it worthwhile.
I sure hope to hear something better than that.
This is basically the gap: Right now I could afford hardware that
could process multiple gigabyte blocks— maybe it only costs as much as
a small house which is not an insane cost for a large business. But
the cost would be decidedly non-negligible and it would be rational
for me to let someone else take it. Applied to everyone, you end up
with a small number of the most vested parties doing all the
validation, and so they have full ability to manipulate like today's
central banks.
For a great many to perform validation— keeping the system honest and
decentralized as it was envisioned— without worrying about the cost
requires that the cost be almost unnoticeable. A tiny fraction of what
some industrial player— who profit from consolidation and
manipulation— could easily handle. I'm skeptical about the system
internally self-regulating the size because of what gets called
"evaporative cooling" in social sciences— the cost goes up, some
people cross their "hey, I'm better off if I externalize the cost of
keeping Bitcoin secure by not participating" boundary and lose their
voice.
There is probably some equilibrium where Bitcoin is compromised
frequently enough that more validators spin up (and ignore past rule
violations which can't be undone without economic Armageddon), and eat
the costs even though there is an insane amount of freeloading going
on. The trustworthiness of today's monetary systems suggests to me
that if there is an equilibrium point here it isn't a very trustworthy
one. There is an even stronger equilibrium state available too: don't
use Bitcoin at at all. If you want a system which is dominated by
political whim and expedience and large industrial players and is, as
a result, only somewhat trustworthy you can just use government issued
currencies— they're well established and have a lot less overhead than
this decentralized stuff.
(And generally— Security makes for a terrible market, security is
naturally a lemon market. The need is only clear in hindsight. In our
case it would be one with an enormous freeloading problem)
> P.S. such a fee structure would address the spam issue with economics rather than rules about spammy transactions
Our current anti-spam one is primarily an economic one— transactions
prioritized based on fee per KB in scarce blocks or priority (another
scarce commodity), the only really non-very-economic part is the
very-small-output heuristic. I would argue that our economic
anti-spam mechanisms are currently failing at their job: Various
parties are engaging in transaction patterns with near pessimal
efficiency— using a dozen (— sometimes thousands) of transactions
where one or two would be adequate. This isn't limited to just one or
two sites— many parties are using inefficient transaction patterns—
creating externalized costs on all future Bitcoin users—, simply
because there is hardly any incentive not to.
Though much discussion among technical people, no one has come up with
any reparametrizations that seem likely to achieve the desired
incentive alignment in the near term. Of all the elements of the
anti-spam policy, it seems to me that the least economic— the minimum
output size— is actually the most effective (most spam suppression
relative to efficient usage suppression), especially as we move to
focusing on the UTXO set size. (The minimum output value requirement
discourages the creation of UTXOs which will never be economically
rational to redeem).
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
2013-02-13 15:42 ` Gregory Maxwell
2013-02-13 21:02 ` Gavin Andresen
@ 2013-02-14 1:02 ` Gregory Maxwell
2013-02-14 6:39 ` Peter Todd
1 sibling, 1 reply; 16+ messages in thread
From: Gregory Maxwell @ 2013-02-14 1:02 UTC (permalink / raw)
To: Raph Frank; +Cc: bitcoin-development
On Wed, Feb 13, 2013 at 7:42 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> I hope that should it become necessary to do so that correct path will
> be obvious to everyone, otherwise there is a grave risk of undermining
> the justification for the confidence in the immutability of any of the
> rules of the system.
With all I wrote on the gloom side— I thought I should elaborate how I
think that would work, assuming that my gloom isn't convincingly
disproven.
It's the year 2043— the Y2038 problem is behind us and everyone is
beginning to forget how terrible it turned out to be— By some amazing
chance Bitcoin still exists and is widely used. Off-chain system like
fidelity bonded banks are vibrant and widely used providing scalable
instant and completely private transactions to millions of people.
Someone posts to the infrequently used IETF Bitcoin working group with
a new draft— It points out that the transaction load is high enough
that even with a 100x increase in block size completion for fees would
hardly be impacted and that— because computers are 2^20 times faster
per unit cost than they were in 2013— and networks had made similar
gains, so even a common wristwatch (the personal computer embedded in
everyone's wrist at birth) could easily keep up with 100 megabyte
blocks.... so the size should be increased as of block 2,047,500.
The only objections are filed by some bearded hippy at the museum of
internet trolling (their authentic reconstruction of Diablo-D3's
desktop exhibit couldn't keep up), and by some dictatorship who again
insists that their communist PeoplesCoin should be used instead— the
usual suspects. And so, after a couple years of upgrades, it is so.
Or perhaps more likely— it would get revised along side a hardforking
cryptosystem upgrade (e.g. replacing sha256 in the hash trees with
SHA-4-512), thus amortizing out all the migration costs...
The trickiness and risk of changing it— of economic problems, of the
risk of undermining trust in the immutability of the system's rules—
only exists if there is genuine, considered, and honest controversy
about the parameters. At the moment any increase would be sure to be
controversial: common hardware and networks would not obviously keep
up with our current maximum size, and our current transaction load
doesn't produce a usable fees market. This cannot remain true
forever.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
2013-02-14 0:28 ` Gregory Maxwell
@ 2013-02-14 2:44 ` Stephen Pair
2013-02-14 3:38 ` Gregory Maxwell
2013-02-14 6:07 ` Peter Todd
0 siblings, 2 replies; 16+ messages in thread
From: Stephen Pair @ 2013-02-14 2:44 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]
On Wed, Feb 13, 2013 at 7:28 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> <bunch of stuff>
>
I understand your arguments, but don't agree with many of your conclusions.
The requirement for everyone to hear the history doesn't get talked
> about much
One of the beauties of bitcoin is that the miners have a very strong
incentive to distribute as widely and as quickly as possible the blocks
they find...they also have a very strong incentive to hear about the blocks
that others find. There will not be an issue with blocks being "jealously
guarded"...what miners will want is a good feed of transactions that they
want to mine. They will be willing to pay for those feeds (either by
sharing the proceeds with highly connected "relay" nodes or by operating
highly connected nodes themselves). Because miners will only want to pay
to get a feed of profitable transactions, they will not pay to receive
transactions whose miner fee does not cover the "relay" fee (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).
These are relatively easy businesses to operate...which means there will be
a lot of them and they'll compete on fees (with wallets automatically
discovering the cheapest of the services). If the businesses of relaying
and mining ever became too centralized, other businesses with a vested
interest in the success of bitcoin would take the necessary steps to ensure
there remained adequate decentralization.
It's important to remember that the centralization that currently exists in
the fiat currency world benefits one set of businesses to the detriment of
many others. Having a functioning and trustworthy payment system benefits
far more people and businesses than a centralized system would.
It is good to be wary of these potential issues, but I don't see how the
economics are likely to yield the outcome you fear. And, really, there's
not a lot that can be done to prevent economics from dictating the ultimate
outcome. In fact, what I write above is not so much about what I think
*should* be built, it's more about what I *predict* will be built.
[-- Attachment #2: Type: text/html, Size: 3781 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
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
1 sibling, 1 reply; 16+ messages in thread
From: Gregory Maxwell @ 2013-02-14 3:38 UTC (permalink / raw)
To: Stephen Pair; +Cc: Bitcoin Dev
On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair <stephen@bitpay•com> wrote:
> One of the beauties of bitcoin is that the miners have a very strong incentive to distribute as widely and as quickly as possible the blocks they find...they also have a very strong incentive to hear about the blocks that others find. There will not be an issue with blocks being "jealously guarded"
Then perhaps I totally misunderstood what you were suggesting. I
believed you were saying blocksize would be controlled by people
having to pay to receive and pay to have blocks forwarded.
>(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. And even if they are all
miners for some reason, if these fees are paying the ever growing
validation/storage costs what expenditure is left for the proof of
work that makes Bitcoin resistant to reversal?
If the cost is soaked up by validation/forwarding then the capacity to
run a validating node ends up being the barrier to entry and
difficulty would be very low... which sounds fine until you realize
that an attacker doesn't have validation costs, and that selfish
("optimally rational") miners could just eschew validation (who cares
if you lose some blocks to invalidity if you're producing them so much
cheaper than the honest players?).
> It is good to be wary of these potential issues, but I don't see how the economics are likely to yield the outcome you fear. And, really, there's not a lot that can be done to prevent economics from dictating the ultimate outcome. In fact, what I write above is not so much about what I think *should* be built, it's more about what I *predict* will be built.
What I want is for economics to dictate a positive outcome. They can
do this how the system is currently constructed where the economics of
using the system are clearly aligned with securing it.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
2013-02-14 3:38 ` Gregory Maxwell
@ 2013-02-14 5:36 ` Stephen Pair
0 siblings, 0 replies; 16+ messages in thread
From: Stephen Pair @ 2013-02-14 5:36 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
2013-02-14 2:44 ` Stephen Pair
2013-02-14 3:38 ` Gregory Maxwell
@ 2013-02-14 6:07 ` Peter Todd
2013-02-14 12:59 ` Stephen Pair
1 sibling, 1 reply; 16+ messages in thread
From: Peter Todd @ 2013-02-14 6:07 UTC (permalink / raw)
To: Stephen Pair; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5334 bytes --]
On Wed, Feb 13, 2013 at 09:44:11PM -0500, Stephen Pair wrote:
> One of the beauties of bitcoin is that the miners have a very strong
> incentive to distribute as widely and as quickly as possible the blocks
> they find...they also have a very strong incentive to hear about the blocks
> that others find. There will not be an issue with blocks being "jealously
The idea that miners have a strong incentive to distribute blocks as
widely and as quickly as possible is a serious misconception. The
optimal situation for a miner is if they can guarantee their blocks
would reach just over 50% of the overall hashing power, but no more. The
reason is orphans.
Here's an example that makes this clear: suppose Alice, Bob, Charlie and
David are the only Bitcoin miners, and each of them has exactly the same
amount of hashing power. We will also assume that every block they mine
is exactly the same size, 1MiB. However, Alice and Bob both have pretty
fast internet connections, 2MiB/s and 1MiB/s respectively. Charlie isn't
so lucky, he's on an average internet connection for the US,
0.25MiB/second. Finally David lives in country with a failing currency,
and his local government is trying to ban Bitcoin, so he has to mine
behind Tor and can only reliably transfer 50KiB/second.
Now the transactions themselves aren't a problem, 1MiB/10minutes is just
1.8KiB/second average. However, what happens when someone finds a block?
So Alice finds one, and with her 1MiB/second connection she
simultaneously transfers her new found block to her three peers. She has
enough bandwidth that she can do all three at once, so Bob has it in 1
second, Charlie 4 seconds, and finally David in 20 seconds. The thing
is, David has effectively spent that 20 seconds doing nothing. Even if
he found a new block in that time he wouldn't be able to upload it to
his other peers fast enough to beat Alices block. In addition, there was
also a probabalistic time window *before* Alice found her block, where
even if David found a block, he couldn't get it to the majority of
hashing power fast enough to matter. Basically we can say David spent
about 30 seconds doing nothing, and thus his effective hash power is now
down by 5%
However, it gets worse. Lets say a rolling average mechanism to
determine maximum block sizes has been implemented, and since demand is
high enough that every block is at the maximum, the rolling average lets
the blocks get bigger. Lets say we're now at 10MiB blocks. Average
transaction volume is now 18KiB/second, so David just has 32KiB/second
left, and a 1MiB block takes 5.3 minutes to download. Including the time
window when David finds a new block but can't upload it he's down to
doing useful mining a bit over 3 minutes/block on average.
Alice on the other hand now has 15% less competition, so she's actually
clearly benefited from the fact that her blocks can't propegate quickly
to 100% of the installed hashing power.
Now I know you are going to complain that this is BS because obviously
we don't need to actually transmit the full block; everyone already has
the transactions so you just need to transfer the tx hashes, roughly a
10x reduction in bandwidth. But it doesn't change the fundemental
principle: instead of David being pushed off-line at 10MiB blocks, he'll
be pushed off-line at 100MiB blocks. Either way, the incentives are to
create blocks so large that they only reliably propegate to a bit over
50% of the hashing power, *not* 100%
Of course, who's to say Alice and Bob are mining blocks full of
transactions known to the network anyway? Right now the block reward is
still high, and tx fees low. If there isn't actually 10MiB/second of
transactions on the network it still makes sense for them to pad their
blocks to that size anyway to force David out of the mining business.
They would gain from the reduced hashing power, and get the tx fees he
would have collected. Finally since there are now just three miners, for
Alice and Bob whether or not their blocks ever get to Charlie is now
totally irrelevant; they have every reason to make their blocks even
bigger.
Would this happen in the real world? With pools chances are people would
quit mining solo or via P2Pool and switch to central pools. Then as the
block sizes get large enough they would quit pools with higher stale
rates in preference for pools with lower ones, and eventually the pools
with lower stale rates would probably wind up clustering geographically
so that the cost of the high-bandwidth internet connections between them
would be cheaper. Already miners are very sensitive to orphan rates, and
will switch pools because of small differences in that rate.
Ultimately the reality is miners have very, very perverse incentives
when it comes to block size. If you assume malice, these perverse
incentives lead to nasty outcomes, and even if you don't assume malice,
for pool operators the natural effects of the cycle of slightly reduced
profitability leading to less ability invest in and maintain fast
network connections, leading to more orphans, less miners, and finally
further reduced profitability due to higher overhead will inevitably
lead to centralization of mining capacity.
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
2013-02-14 1:02 ` Gregory Maxwell
@ 2013-02-14 6:39 ` Peter Todd
0 siblings, 0 replies; 16+ messages in thread
From: Peter Todd @ 2013-02-14 6:39 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]
On Wed, Feb 13, 2013 at 05:02:39PM -0800, Gregory Maxwell wrote:
> It's the year 2043— the Y2038 problem is behind us and everyone is
> beginning to forget how terrible it turned out to be— By some amazing
> chance Bitcoin still exists and is widely used. Off-chain system like
> fidelity bonded banks are vibrant and widely used providing scalable
> instant and completely private transactions to millions of people.
Speaking of fidelity bonded banks I think it needs to be made clear that
really trustworthy bonded banks require the maximum block size to be
kept limited. The problem is that even if you don't create any
transactions on the chain yourself, you still need to be able to keep
watch the chain to keep track of what the bank is doing. For instance if
you are trying to decide if you can trust the bank with a 1BTC deposit,
and they've purchased a 1000BTC fidelity bond, you still need to be able
to determine if all the unspent transaction outputs in the blockchain
that the bank could spend, in addition to all the unspen transactions in
the mempool, are less than the value of their fidelity bond. With 1MiB
blocks that will be practical on smartphones with wireless internet
connectivity without having to trust anyone else. With 1GiB blocks that
just won't be true and you'll be forced to trust the relatively few
nodes out there with the hardware to deal with the blockchain. You'll
pay for it too.
Potentially the various UTXO proposals will help, but they will need to
be quite sophisticated; we'll need sums of all txout values by
scriptPubKey and a fraud notice system for instance. All of this stuff
is at best many months away from even beginning to be deployed on the
network, and probably years away from getting to the point where it is
truely trustworthy. Maybe it'll never become trustworthy, either because
miners just don't bother, the code doesn't get written, or a flaw in the
whole idea is found. We're just not going to know until these
technologies are implemented and tested, and without them, large blocks
force us into trusting miners blindly and make many valuable
applications impossible.
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
2013-02-14 6:07 ` Peter Todd
@ 2013-02-14 12:59 ` Stephen Pair
2013-02-18 16:22 ` Peter Todd
0 siblings, 1 reply; 16+ messages in thread
From: Stephen Pair @ 2013-02-14 12:59 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
On Thu, Feb 14, 2013 at 1:07 AM, Peter Todd <pete@petertodd•org> wrote:
> On Wed, Feb 13, 2013 at 09:44:11PM -0500, Stephen Pair wrote:
> > One of the beauties of bitcoin is that the miners have a very strong
> > incentive to distribute as widely and as quickly as possible the blocks
> > they find...they also have a very strong incentive to hear about the
> blocks
> > that others find. There will not be an issue with blocks being
> "jealously
>
> The idea that miners have a strong incentive to distribute blocks as
> widely and as quickly as possible is a serious misconception. The
> optimal situation for a miner is if they can guarantee their blocks
> would reach just over 50% of the overall hashing power, but no more. The
> reason is orphans.
>
Perhaps, but a miner trying to target just over 50% of the network will run
the very real risk that they'll only reach 49%.
What about the case for centralization if the block size remains capped? I
see a far greater risk of centralization in that scenario than if the cap
were to be removed. The reason is very simple, bitcoin would ultimately
become useful only for very high value, settlement transactions. Only the
mega corporations and banks would be using it directly, everyone else would
be doing daily transacting in centrally issued currencies of one form or
another. As the banks and mega corps learned about the utility of bitcoin
and began to use it en masse, they would start to take the whole network
off the public internet and put it on a higher speed and more reliable
backbone. Those corporations would establish mining agreements among
themselves to ensure none of the participants could take over the system
and compromise it, while at the same time keeping the operational costs to
a minimum. Bitcoin is now a great alternative to the wire transfer system,
but has no value to the average person wanted to have cheap and private
transactions over the Internet. Maybe Litecoin starts to fill that niche.
[-- Attachment #2: Type: text/html, Size: 3080 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
2013-02-14 12:59 ` Stephen Pair
@ 2013-02-18 16:22 ` Peter Todd
0 siblings, 0 replies; 16+ messages in thread
From: Peter Todd @ 2013-02-18 16:22 UTC (permalink / raw)
To: Stephen Pair; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5253 bytes --]
On Thu, Feb 14, 2013 at 07:59:04AM -0500, Stephen Pair wrote:
> > The idea that miners have a strong incentive to distribute blocks as
> > widely and as quickly as possible is a serious misconception. The
> > optimal situation for a miner is if they can guarantee their blocks
> > would reach just over 50% of the overall hashing power, but no more. The
> > reason is orphans.
> >
>
> Perhaps, but a miner trying to target just over 50% of the network will run
> the very real risk that they'll only reach 49%.
Then don't be so agressive; target 90% as I suggested and the miner
still comes out ahead by having 10% less hashing power to compete with.
50% is only a maximum because when more than 50% of the network does not
see your blocks the majority will inevitably create a longer chain than
you, but less than 50% and your part of the network will inevitably
create a longer chain than them.
> What about the case for centralization if the block size remains capped? I
> see a far greater risk of centralization in that scenario than if the cap
> were to be removed. The reason is very simple, bitcoin would ultimately
> become useful only for very high value, settlement transactions. Only the
> mega corporations and banks would be using it directly, everyone else would
> be doing daily transacting in centrally issued currencies of one form or
> another. As the banks and mega corps learned about the utility of bitcoin
> and began to use it en masse, they would start to take the whole network
> off the public internet and put it on a higher speed and more reliable
> backbone. Those corporations would establish mining agreements among
> themselves to ensure none of the participants could take over the system
> and compromise it, while at the same time keeping the operational costs to
> a minimum. Bitcoin is now a great alternative to the wire transfer system,
> but has no value to the average person wanted to have cheap and private
> transactions over the Internet. Maybe Litecoin starts to fill that niche.
What you are describing is either *voluntary* centralization, or won't
happen. Nothing in your scenario will stop people from transacting on
the Bitcoin network directly, it will just make it more expensive. For
instance suppose fees rose to the point where the value of the fees was
10x the value of the block reward today; miners would be taking in
$972,000/day, or $6750/block. At 1MiB/block that implies transaction
fees of $6.75/KiB, or about $2 per transaction. Even if the fees were
$20 per transaction that'd be pretty cheap for direct access to the
worlds bank-to-bank financial network; I can still transfer an unlimited
amount of money across the planet, and no-one can stop me. Importantly
there will be plenty of demand to have transactions mined from people
other than banks and large corporations.
Because there will continue to be demand, and because 1MiB blocks means
running a relay node is trivial enough that people can do it just for
fun, banks won't be able to force people to use their "high-speed
backbone". Not to say they won't create one, but it won't have any real
advantage over something that can be run in your basement.
On the mining side with 1MiB blocks the fixed costs for setting up a
mining operation are just a moderately powered computer with a bunch of
harddrive space and a slow internet connection. The marginal costs are
still there of course, but the cost of power and cooling are lower at
small scale than at larger industrial scales; power is often available
for free in small amounts, and cooling isn't a problem in small setups.
Because small-scale miners will still exist, there will still be a
market for "consumer" mining gear, and trying to regulate mining
equipment will just turn it into a black-market good. Small blocks let
you setup a mining operation anywhere in the world - good luck
controlling that. Mining also will remain a way to import Bitcoins into
places.
Banks can try setting up exclusive mining contracts, but unless they
control more than 50% of the network they'll still have to accept blocks
found by these highly decentralized, small-scale miners. They'd be
better off broadcasting their transactions to those miners as well so
they don't get double-spent. Thus decentralized miners still can profit
from transaction fees, and still have an incentive to mine. Doesn't
sound like centralization to me at all.
On the other land, with large blocks, not only is mining solo
unprofitable due to the huge fixed costs required to process the blocks,
miners on pools can't effectively secure the network because they can't
independently verify that the blocks they are mining are valid. It would
be easy then to co-opt the relatively small number of pools, a number
that is not particularly large even now. Transaction relay nodes would
also be very expensive to run, and again the small number of them makes
them targets for control. Sure transactions will be cheap, but that
doesn't do you any good if the small number of miners out there are all
regulated and ignore your transactions.
Sounds like centralization to me.
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2013-02-18 16:22 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox