[bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary

[Eric Lombrozo via bitcoin-dev]

I only got into Bitcoin in 2011, after the block size limit was already in place. After going through some more of the early history of Bitcoin to better understand the origins of this, things are starting to come into better perspective.

Initially there was no block size limit - it was thought that the fee market would naturally develop and would impose economic constraints on growth. But this hypothesis failed after a sudden influx of new uses. It was still too easy to attack the network. This idea had to wait until the network was more mature to handle things.

Enter a “temporary” anti-spam measure - a one megabyte block size limit. Let’s test this out, then increase it once we see how things work. So far so good


Except
well:

1) We never really got to test things out
a fee market never really got created, we never got to see how fees would really work in practice.

2) Turns out the vast majority of validation nodes have little if anything to do with mining - validators do not get compensated
validation cost is externalized to the entire network.

3) Miners don’t even properly validate blocks. And the bigger the blocks get, the greater the propensity to skip this step. Oops!

4) A satisfactory mechanism for thin clients to be able to securely obtain reasonably secure, short proofs for their transactions never materialized.

[Jean-Paul Kogelman via bitcoin-dev]

Enter a “temporary” anti-spam measure - a one megabyte block size limit. Let’s test this out, then increase it once we see how things work. So far so good…

The block size limit was put in place as an anti-DoS measure (monster blocks), not "anti-spam". It was never intended to have any economic effect, not on spam and not on any future fee market.


jp

[Eric Lombrozo via bitcoin-dev]

Post by Jean-Paul Kogelman via bitcoin-dev

Post by Eric Lombrozo via bitcoin-dev
Enter a “temporary” anti-spam measure - a one megabyte block size limit. Let’s test this out, then increase it once we see how things work. So far so good


The block size limit was put in place as an anti-DoS measure (monster blocks), not "anti-spam". It was never intended to have any economic effect, not on spam and not on any future fee market.
jp

I’m using spam and DoS somewhat synonymously here, although you’re correct - DoS is a more accurate term.

[Mark Friedenbach via bitcoin-dev]

Does it matter even in the slightest why the block size limit was put in
place? It does not. Bitcoin is a decentralized payment network, and the
relationship between utility (block size) and decentralization is
empirical. Why the 1MB limit was put in place at the time might be a
historically interesting question, but it bears little relevance to the
present engineering issues.

On Tue, Jul 28, 2015 at 5:43 PM, Jean-Paul Kogelman via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev

Post by Eric Lombrozo via bitcoin-dev
Enter a “temporary” anti-spam measure - a one megabyte block size limit.

Let’s test this out, then increase it once we see how things work. So far
so good

The block size limit was put in place as an anti-DoS measure (monster
blocks), not "anti-spam". It was never intended to have any economic
effect, not on spam and not on any future fee market.
jp
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Eric Lombrozo via bitcoin-dev]

I agree that the historical reasons are irrelevant from an engineering perspective. But they still set a context for the discussion
and might help shed some insight into the motivations behind some of the participants. It’s also good to know these things to counter arguments that start with “But Satoshi said that
”

What’s critically important to note is that several of the assumptions that were being made at the time this limit was decided have turned out wrong
and that these other issues should probably be of greater concern and more highly prioritized in any discussion considering the merits of deploying potentially incompatible consensus rule changes. It seems if these other issues were fixed perhaps no block size limit would be required at all (as was originally hoped).

- Eric

Does it matter even in the slightest why the block size limit was put in place? It does not. Bitcoin is a decentralized payment network, and the relationship between utility (block size) and decentralization is empirical. Why the 1MB limit was put in place at the time might be a historically interesting question, but it bears little relevance to the present engineering issues.

Post by Eric Lombrozo via bitcoin-dev
Enter a “temporary” anti-spam measure - a one megabyte block size limit. Let’s test this out, then increase it once we see how things work. So far so good


The block size limit was put in place as an anti-DoS measure (monster blocks), not "anti-spam". It was never intended to have any economic effect, not on spam and not on any future fee market.
jp
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

[Eric Lombrozo via bitcoin-dev]

In the interest of promoting some constructive discussion on this, let me start by making a few proposals to correct the listed issues.

Note: many of these ideas are neither my own nor really all that new, but it seems in the past we’ve given up too easily on actually moving forward on them despite their critical importance.


——

1) A fee market never really got created, we don’t really know how transaction fees would work in practice.

The only way to see how fees would work in practice is to have scarcity. If the network is still not sufficiently mature to be able to handle actual resource limits securely, the safest way to do this is to artificially impose limits. Some economists might bicker about the problems with production quotas and what not
but how else are we to solve the real, non-trivial engineering problems without risking system collapse? The eventual goal would be to remove these artificial limits once we’re confident that the economic incentives are properly aligned to maintain security. We’re still quite far from this goal, though, and it would be irresponsible, IMHO, to insist on letting the system hit its real limits.


2) Turns out the vast majority of validation nodes have little if anything to do with mining - validators do not get compensated
validation cost is externalized to the entire network.
3) Miners don’t even properly validate blocks. And the bigger the blocks get, the greater the propensity to skip this step. Oops!

Issues (2) and (3) are inextricably related so I’ll cover both together.

The obvious problem here is that as long as the cost of checking validators is the same as the cost of validating itself, there’s really little we can do to properly have any sort of division of labor. Requiring, at the very least, random checks might be a start. Perhaps some clever use of SNARKs might eventually be secure and practical.

It might also be possible to directly pay validators for satisfying random checks or providing SNARKs. If only we could trustlessly and securely outsource this work we’d make tremendous progress.

Of all the issues I’ve listed, these are perhaps the ones for which practical solutions seem most tentative at present.


4) A satisfactory mechanism for thin clients to be able to securely obtain reasonably secure, short proofs for their transactions never materialized.

The first part of the solution to this issue is the use of better data structures. Satoshi’s SPV can prove that transactions are included in blocks
and that outputs are spent. But it has no mechanism for proving that a given transaction is *not* included in any block
or that some particular output remains unspent. The structures to which we’re committing extremely inefficient for querying some of the most important things required for validation
i.e. whether an output exists and whether it is spent.

The second part is shifting the responsibility for constructing proofs to the parties who already have the greatest incentives to store the necessary data to construct these proofs to allow efficient prunability. Outsourceability of proofs would also be highly desirable.

——

If we want to be able to raise the block size limit
or perhaps get rid of it altogether, I would suggest we start by addressing these specific issues and work to find practical solutions. Since raising the block size limit is already a hard forking consensus rule change, at least the need for hard forks isn’t what’s stopping us.

- Eric

Post by Eric Lombrozo via bitcoin-dev
I agree that the historical reasons are irrelevant from an engineering perspective. But they still set a context for the discussion
and might help shed some insight into the motivations behind some of the participants. It’s also good to know these things to counter arguments that start with “But Satoshi said that
”
What’s critically important to note is that several of the assumptions that were being made at the time this limit was decided have turned out wrong
and that these other issues should probably be of greater concern and more highly prioritized in any discussion considering the merits of deploying potentially incompatible consensus rule changes. It seems if these other issues were fixed perhaps no block size limit would be required at all (as was originally hoped).
- Eric

Does it matter even in the slightest why the block size limit was put in place? It does not. Bitcoin is a decentralized payment network, and the relationship between utility (block size) and decentralization is empirical. Why the 1MB limit was put in place at the time might be a historically interesting question, but it bears little relevance to the present engineering issues.

Post by Eric Lombrozo via bitcoin-dev
Enter a “temporary” anti-spam measure - a one megabyte block size limit. Let’s test this out, then increase it once we see how things work. So far so good


The block size limit was put in place as an anti-DoS measure (monster blocks), not "anti-spam". It was never intended to have any economic effect, not on spam and not on any future fee market.
jp
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

[Eric Lombrozo via bitcoin-dev]

Post by Eric Lombrozo via bitcoin-dev
Note: many of these ideas are neither my own nor really all that new, but it seems in the past we’ve given up too easily on actually moving forward on them despite their critical importance.

In retrospect I regret not having made this note more emphatic:

GUYS, WE’VE KNOWN ABOUT THESE PROBLEMS AND HAVE TALKED ABOUT THEM FOR YEARS ALREADY
AND IT SEEMS PRACTICALLY NOTHING HAS HAPPENED
WTF?!?!?!?

[Milly Bitcoin via bitcoin-dev]

GUYS, WE’VE KNOWN ABOUT THESE PROBLEMS AND HAVE TALKED ABOUT THEM FOR
YEARS ALREADY…AND IT SEEMS PRACTICALLY NOTHING HAS HAPPENED…

What is the incentive for someone with high level technical skills to
spend all their time developing and testing code? Especially since the
code is generally the boring task of "fixing the plumbing" and won't
benefit the developer directly ... except they will be blamed if
something goes wrong.

Russ

[Eric Lombrozo via bitcoin-dev]

GUYS, WE’VE KNOWN ABOUT THESE PROBLEMS AND HAVE TALKED ABOUT THEM FOR
YEARS ALREADY…AND IT SEEMS PRACTICALLY NOTHING HAS HAPPENED…

What is the incentive for someone with high level technical skills to spend all their time developing and testing code? Especially since the code is generally the boring task of "fixing the plumbing" and won't benefit the developer directly ... except they will be blamed if something goes wrong.
Russ
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Some of the most highly skilled technical people working on Bitcoin Core have been doing exactly that! The main incentive, of course, is that later on you get to work on something that’s actually pleasant to work on rather than a whole bunch of garbled crap that doesn’t work properly.

However, the great irony is that the devs who have long since recognized the importance of fixing these issues have also tended to be loathe to touching any of the consensus code unless it fixes some critical immediately exploitable security hole…while the devs who most clamor for consensus code changes have tended to all but ignore these issues entirely.

I sometimes wish it were the other way around.

- Eric

[Thomas Zander via bitcoin-dev]

1) A fee market never really got created, we don’t really know how
transaction fees would work in practice.
The only way to see how fees would work in practice is to have scarcity.

This skips over the question why you need a fees market. There really is no
reason that for the next 10 to 20 years there is a need for a fees market to
incentive miners to mine. Planning that far ahead is doomed to failure.

[Mike Hearn via bitcoin-dev]

I do love history lessons from people who weren't actually there.

Let me correct your misconceptions.


Initially there was no block size limit - it was thought that the fee

Post by Eric Lombrozo via bitcoin-dev
market would naturally develop and would impose economic constraints on
growth.

The term "fee market" was never used back then, and Satoshi did not ever
postulate economic constraints on growth. Back then the talk was (quite
sensibly) how to grow faster, not how to slow things down!

Post by Eric Lombrozo via bitcoin-dev
But this hypothesis failed after a sudden influx of new uses. It was still
too easy to attack the network. This idea had to wait until the network was
more mature to handle things.

No such event happened, and the hypothesis of which you talk never existed.

Post by Eric Lombrozo via bitcoin-dev
Enter a “temporary” anti-spam measure - a one megabyte block size limit.

The one megabyte limit was nothing to do with anti spam. It was a quick
kludge to try and avoid the user experience degrading significantly in the
event of a "DoS block", back when everyone used Bitcoin-Qt. The fear was
that some malicious miner would generate massive blocks and make the wallet
too painful to use, before there were any alternatives.

The plan was to remove it once SPV wallets were widespread. But Satoshi
left before that happened.


Now on to your claims:

1) We never really got to test things out
a fee market never really got

Post by Eric Lombrozo via bitcoin-dev
created, we never got to see how fees would really work in practice.

The limit had nothing to do with fees. Satoshi explicitly wanted free
transactions to last as long as possible.

Post by Eric Lombrozo via bitcoin-dev
2) Turns out the vast majority of validation nodes have little if anything
to do with mining - validators do not get compensated
validation cost is
externalized to the entire network.

Satoshi explicitly envisioned a future where only miners ran nodes, so it
had nothing to do with this either.

Validators validate for themselves. Calculating a local UTXO set and then
not using it for anything doesn't help anyone. SPV wallets need filtering
and serving capability, but a computer can filter and serve the chain
without validating it.

The only purposes non-mining, non-rpc-serving, non-Qt-wallet-sustaining
full nodes are needed for with today's network are:

1. Filtering the chain for bandwidth constrained SPV wallets (nb: you
can run an SPV wallet that downloads all transactions if you want). But
this could be handled by specialised nodes, just like we always imagined in
future not every node will serve the entire chain but only special
"archival nodes"

2. Relaying validated transactions so SPV wallets can stick a thumb into
the wind and heuristically guess whether a transaction is valid or not.
This is useful for a better user interface.

3. Storing the mempool and filtering/serving it so SPV wallets can find
transactions that were broadcast before they started, but not yet included
in a block. This is useful for a better user interface.

Outside of serving lightweight P2P wallets there's no purpose in running a
P2P node if you aren't mining, or using it as a trusted node for your own
operations.

And if one day there aren't enough network nodes being run by volunteers to
service all the lightweight wallets, then we can easily create an incentive
scheme to fix that.


3) Miners don’t even properly validate blocks. And the bigger the blocks

Post by Eric Lombrozo via bitcoin-dev
get, the greater the propensity to skip this step. Oops!

Miners who don't validate have a habit of bleeding money: that's the
system working as designed.

Post by Eric Lombrozo via bitcoin-dev
4) A satisfactory mechanism for thin clients to be able to securely obtain
reasonably secure, short proofs for their transactions never materialized.

It did. I designed it. The proofs are short and "reasonably secure" in that
it would be a difficult and expensive attack to mount.

But as is so often the case with Bitcoin Core these days, someone who came
along much later has retroactively decided that the work done so far fails
to meet some arbitrary and undefined level of perfection. "Satisfactory"
and "reasonably secure" don't mean anything, especially not coming from
someone who hasn't done the work, so why should anyone care about that
opinion of yours?

[Eric Lombrozo via bitcoin-dev]

Post by Mike Hearn via bitcoin-dev
I do love history lessons from people who weren't actually there.
Let me correct your misconceptions.
Initially there was no block size limit - it was thought that the fee market would naturally develop and would impose economic constraints on growth.
The term "fee market" was never used back then, and Satoshi did not ever postulate economic constraints on growth. Back then the talk was (quite sensibly) how to grow faster, not how to slow things down!

Irrelevant what term was used - and as brilliant as Satoshi might have been at some things, he obviously got this one wrong.

Post by Mike Hearn via bitcoin-dev
But this hypothesis failed after a sudden influx of new uses. It was still too easy to attack the network. This idea had to wait until the network was more mature to handle things.
No such event happened, and the hypothesis of which you talk never existed.

Nobody threatened to start mining huge blocks given how relatively inexpensive it was to mine back then?

Post by Mike Hearn via bitcoin-dev
Enter a “temporary” anti-spam measure - a one megabyte block size limit.
The one megabyte limit was nothing to do with anti spam. It was a quick kludge to try and avoid the user experience degrading significantly in the event of a "DoS block", back when everyone used Bitcoin-Qt. The fear was that some malicious miner would generate massive blocks and make the wallet too painful to use, before there were any alternatives.

I thought I clarified this in an earlier post - I meant DoS. Please don’t digress on such stupid technicalities.

Post by Mike Hearn via bitcoin-dev
The plan was to remove it once SPV wallets were widespread. But Satoshi left before that happened.

Guess what? SPV wallets are still not particularly widespread
and those that are out there are notoriously terrible at detecting network forks and making sure they are on the right one.

Post by Mike Hearn via bitcoin-dev
1) We never really got to test things out
a fee market never really got created, we never got to see how fees would really work in practice.
The limit had nothing to do with fees. Satoshi explicitly wanted free transactions to last as long as possible.

Something has to limit block sizes in practice. Perhaps Satoshi was not constrained by finite computational resources, but the rest of us sure are. The fact that without imposing a hardcoded limit Satoshi couldn’t figure out a way to keep the DoS-block guys away suggests he didn’t have this fully worked out.

I understand that initially it was desirable that transactions be free
but surely even Satoshi understood this couldn’t be perpetually self-sustaining
and that the ability to bid for inclusion in blocks would eventually become a crucial component of the network. Or were fees just added for decoration?

We’re already more than six years into this. When were these mechanisms going to be developed and tested? After 10 years? 20? Perhaps after 1024 years?(https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki <https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki>)

Post by Mike Hearn via bitcoin-dev
2) Turns out the vast majority of validation nodes have little if anything to do with mining - validators do not get compensated
validation cost is externalized to the entire network.
Satoshi explicitly envisioned a future where only miners ran nodes, so it had nothing to do with this either.

And Satoshi was dead wrong. As others have pointed out in this thread, while this is certainly of historical interest, it is irrelevant from an engineering perspective.

Post by Mike Hearn via bitcoin-dev
Validators validate for themselves. Calculating a local UTXO set and then not using it for anything doesn't help anyone. SPV wallets need filtering and serving capability, but a computer can filter and serve the chain without validating it.

Right. Turns out the ledger structure is terrible for constructing the kinds of proofs that are most important to validators - i.e. whether an output exists, what its script and amounts are, whether it’s been spent, etc


Despite Satoshi’s brilliance, software architecture was obviously not his strongest suit. But it didn’t really matter at the beginning since this was really an experiment
and he succeeded in making his point.

Post by Mike Hearn via bitcoin-dev
Filtering the chain for bandwidth constrained SPV wallets (nb: you can run an SPV wallet that downloads all transactions if you want). But this could be handled by specialised nodes, just like we always imagined in future not every node will serve the entire chain but only special "archival nodes"
Relaying validated transactions so SPV wallets can stick a thumb into the wind and heuristically guess whether a transaction is valid or not. This is useful for a better user interface.
Storing the mempool and filtering/serving it so SPV wallets can find transactions that were broadcast before they started, but not yet included in a block. This is useful for a better user interface.
Outside of serving lightweight P2P wallets there's no purpose in running a P2P node if you aren't mining, or using it as a trusted node for your own operations.
And if one day there aren't enough network nodes being run by volunteers to service all the lightweight wallets, then we can easily create an incentive scheme to fix that.

Yes, let’s wait until things are about to break before even beginning to address the issue
because we can “easily create” anything we haven’t invented yet at the last minute.

Post by Mike Hearn via bitcoin-dev
3) Miners don’t even properly validate blocks. And the bigger the blocks get, the greater the propensity to skip this step. Oops!
Miners who don't validate have a habit of bleeding money: that's the system working as designed.

Erm
most miners just trust mining pool operators to validate blocks for them
and some of the biggest pools have been blatantly cutting corners. Yes, a few pools might have temporarily bled a little
but properly validating is probably not the equilibrium strategy
and as time goes on, they are likely to start cutting corners again. Whether they ultimately bleed money isn’t really the point - many believe that cutting corners is actually a rational strategy. If you want to discuss the game theory behind this, fine
but the fact some of the biggest mining pool operators are on record saying they are likely to continue doing this is enough to seriously put to question one of the most fundamental assumptions behind the network security model.

Post by Mike Hearn via bitcoin-dev
4) A satisfactory mechanism for thin clients to be able to securely obtain reasonably secure, short proofs for their transactions never materialized.
It did. I designed it. The proofs are short and "reasonably secure" in that it would be a difficult and expensive attack to mount.

You have my respect for BIP37, Mike. I know you can do amazing work. You actually made SPV semi-useful despite inheriting such crappy data structures. This is indeed to be respected.

Post by Mike Hearn via bitcoin-dev
But as is so often the case with Bitcoin Core these days, someone who came along much later has retroactively decided that the work done so far fails to meet some arbitrary and undefined level of perfection. "Satisfactory" and "reasonably secure" don't mean anything, especially not coming from someone who hasn't done the work, so why should anyone care about that opinion of yours?

Not done the work?

I’m one of the very few developers in this space that has actually tried *hard* to make your BIP37 work. Amongst the desktop wallets listed on bitcoin.org <http://bitcoin.org/>, there are only two that have always supported SPV (or at least I think MultiBit has always supported it, perhaps I’m wrong). One is MultiBit, the other one is mine. I give you credit for your work
perhaps you could be generous enough to extend me some credit too?

[Mike Hearn via bitcoin-dev]

Post by Eric Lombrozo via bitcoin-dev
Irrelevant what term was used - and as brilliant as Satoshi might have
been at some things, he obviously got this one wrong.

I don't think it's obvious. You may disagree, but don't pretend any of this
stuff is obvious.

Consider this: the highest Bitcoin tx fees can possibly go is perhaps a
little higher than what our competition charges. Too much higher than that,
and people will just say, you know what .... I'll make a bank transfer.
It's cheaper and not much slower, sometimes no slower at all.

And now consider that in many parts of the world bank transfers are free.

They aren't actually free, of course, but they *appear* to be free because
the infrastructure for doing them is cross subsidised by the fees on other
products and services, or hidden in the prices of goods sold.

So that's a market reality Bitcoin has to handle. It's already more
expensive than the competition sometimes, but luckily not much more, and
anyway Bitcoin has some features those other systems lack (and vice versa).
So it can still be competitive.

But your extremely vague notion of a "fee market" neglects to consider that
it already exists, and it's not a market of "Bitcoin users buying space in
Bitcoin blocks". It's "users paying to move money".

You can argue with this sort of economic logic if you like, but don't claim
this stuff is obvious.

Nobody threatened to start mining huge blocks given how relatively

Post by Eric Lombrozo via bitcoin-dev
inexpensive it was to mine back then?

Not that I recall. It wasn't a response to any actual event, I think, but
rather a growing realisation that the code was full of DoS attacks.

Post by Eric Lombrozo via bitcoin-dev
Guess what? SPV wallets are still not particularly widespread
and those
that are out there are notoriously terrible at detecting network forks and
making sure they are on the right one.

The most popular mobile wallet (measured by installs) on Android is SPV. It
has between 500,000 and 1 million installs, whilst Coinbase has not yet
crossed the 500,000 mark. One of the most popular wallets on iOS is SPV. If
we had SPV wallets with better user interfaces on desktops, they'd be more
popular there too (perhaps MultiBit HD can recapture some lost ground).

So I would argue that they are in fact very widespread.

Likewise, they are not "notoriously terrible" at detecting chain forks.
That's a spurious idea that you and Patrick have been pushing lately, but
they detect them and follow reorgs across them according to the SPV
algorithm, which is based on most work done. This is exactly what they are
designed to do.

Contrast this with other lightweight wallets which either don't examine the
block chain or implement the algorithm incorrectly, and I fail to see how
this can be described as "notoriously terrible".

Post by Eric Lombrozo via bitcoin-dev
I understand that initially it was desirable that transactions be free
but
surely even Satoshi understood this couldn’t be perpetually
self-sustaining
and that the ability to bid for inclusion in blocks would
eventually become a crucial component of the network. Or were fees just
added for decoration?

Fees were added as a way to get money to miners in a fair and decentralised
way.

Attaching fees directly to all transactions is certainly one way to use
that, but it's not the only way. As noted above, our competitors prefer a
combination of price-hiding and cross subsidisation. Both of these can be
implemented with tx fees, but not necessarily by trying to artificially
limit supply, which is economically nonsensical.

Post by Eric Lombrozo via bitcoin-dev
We’re already more than six years into this. When were these mechanisms
going to be developed and tested? After 10 years? 20? Perhaps after 1024
years?(https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki)

Maybe when there is a need? I already discussed this topic of need here:

https://medium.com/@octskyward/hashing-7d04a887acc8

Right. Turns out the ledger structure is terrible for constructing the

Post by Eric Lombrozo via bitcoin-dev
kinds of proofs that are most important to validators - i.e. whether an
output exists, what its script and amounts are, whether it’s been spent,
etc


Validators don't require proofs. That's why they are validators.

I think you're trying to say the block chain doesn't provide the kinds of
proofs that are most important to lightweight wallets. But I would
disagree. Even with UTXO commitments, there can still be double spends out
there in the networks memory pools you are unaware of. Merely being
presented with a correctly signed transaction doesn't tell you a whole lot
..... if you wait for a block, you get the same level of proof regardless
of whether there are UTXO commitments or not. If you don't then you still
have to have some trust in your peers that you are seeing an accurate and
full view of network traffic.

So whilst there are ways to make the protocol incrementally better, when
you work through the use cases for these sorts of data structures and ask
"how will this impact the user experience", the primary candidates so far
don't seem to make much difference.

Remote attestation from secure hardware would make a big difference though.
Then you could get rid of the waiting times entirely because you know the
sending wallet won't double spend.


Yes, let’s wait until things are about to break before even beginning to

Post by Eric Lombrozo via bitcoin-dev
address the issue
because we can “easily create” anything we haven’t
invented yet at the last minute.

bitcoinj already has a micropayment channel implementation in it. There's a
bit of work required to glue everything together, but it's not a massive
project to start using this to pay nodes for their services.

But it's not needed right now: serving these clients is so darn cheap. And
there is plenty of room for optimising things still further!

Post by Eric Lombrozo via bitcoin-dev
I’m one of the very few developers in this space that has actually tried
*hard* to make your BIP37 work. Amongst the desktop wallets listed on
bitcoin.org, there are only two that have always supported SPV (or at
least I think MultiBit has always supported it, perhaps I’m wrong). One is
MultiBit, the other one is mine. I give you credit for your work
perhaps
you could be generous enough to extend me some credit too?

MultiBit has always supported it. I apologise for implying you have not
built a wallet. I think yours is mSIGNA, right? Did it used to be called
something else? I recognise the website design but must admit, I have not
heard of mSIGNA before.

Regardless, as a fellow implementor, I would appreciate it more if you
designed and implemented upgrades, rather than just trashing the work done
so far as "notoriously terrible", Satoshi as "not a systems architect" and
so on.

[Eric Lombrozo via bitcoin-dev]

Post by Eric Lombrozo via bitcoin-dev
Irrelevant what term was used - and as brilliant as Satoshi might have been at some things, he obviously got this one wrong.
I don't think it's obvious. You may disagree, but don't pretend any of this stuff is obvious.
Consider this: the highest Bitcoin tx fees can possibly go is perhaps a little higher than what our competition charges. Too much higher than that, and people will just say, you know what .... I'll make a bank transfer. It's cheaper and not much slower, sometimes no slower at all.
And now consider that in many parts of the world bank transfers are free.
They aren't actually free, of course, but they appear to be free because the infrastructure for doing them is cross subsidised by the fees on other products and services, or hidden in the prices of goods sold.
So that's a market reality Bitcoin has to handle. It's already more expensive than the competition sometimes, but luckily not much more, and anyway Bitcoin has some features those other systems lack (and vice versa). So it can still be competitive.
But your extremely vague notion of a "fee market" neglects to consider that it already exists, and it's not a market of "Bitcoin users buying space in Bitcoin blocks". It's "users paying to move money".
You can argue with this sort of economic logic if you like, but don't claim this stuff is obvious.

100% granted - it was not obvious
and we speak today with the benefit of hindsight.

I’ll clarify my argument, for the sake of anyone who thinks I’m looking to play word games rather than trying to figure out a good way forward.

Point is
processing blocks requires computational resources that someone needs to put up. Unless the people who are putting up these resources are properly incentivized to continue doing it, the network will fail.

Unfortunately, it was unforeseen that most nodes on the network would turn out to not be miners
and that most miners wouldn’t even run full nodes. Yes, I speak with the benefit of hindsight, had I been discussing this in 2008 I very well could have made the same mistake or worse. But it isn’t 2008, it’s 2015
and we’ve learned a thing or two since.

Given that things are what they are, it is clear that larger blocks externalize costs onto the rest of the network.

Waiting until we can no longer count on the altruistic goodwill of volunteers because they suddenly decide that they have better uses for their computers is probably not such a wonderful idea. But even worse is further burdening the network with externalized costs before we’ve solved these important issues
especially given the evidence that larger blocks tend to lead to network forks. No, I’m not talking about regular run-of-the-mill reorgs
I’m talking consensus forks - a network partition that cannot be reconciled without manual intervention, so please don’t distract the issue. Yes, each incident occurred for a very different reason
but you’d have to be blind to miss the correlation between bigger blocks and the propensity for forks.

What Satoshi might have thought in 2008-2009 is fascinating from a historical perspective, but his early pioneering insights don’t appear to be of much help in addressing these particular issues.

Post by Eric Lombrozo via bitcoin-dev
Nobody threatened to start mining huge blocks given how relatively inexpensive it was to mine back then?
Not that I recall. It wasn't a response to any actual event, I think, but rather a growing realisation that the code was full of DoS attacks.
Guess what? SPV wallets are still not particularly widespread
and those that are out there are notoriously terrible at detecting network forks and making sure they are on the right one.
The most popular mobile wallet (measured by installs) on Android is SPV. It has between 500,000 and 1 million installs, whilst Coinbase has not yet crossed the 500,000 mark. One of the most popular wallets on iOS is SPV. If we had SPV wallets with better user interfaces on desktops, they'd be more popular there too (perhaps MultiBit HD can recapture some lost ground).
So I would argue that they are in fact very widespread.
Likewise, they are not "notoriously terrible" at detecting chain forks. That's a spurious idea that you and Patrick have been pushing lately, but they detect them and follow reorgs across them according to the SPV algorithm, which is based on most work done. This is exactly what they are designed to do.
Contrast this with other lightweight wallets which either don't examine the block chain or implement the algorithm incorrectly, and I fail to see how this can be described as "notoriously terrible".
I understand that initially it was desirable that transactions be free
but surely even Satoshi understood this couldn’t be perpetually self-sustaining
and that the ability to bid for inclusion in blocks would eventually become a crucial component of the network. Or were fees just added for decoration?
Fees were added as a way to get money to miners in a fair and decentralised way.
Attaching fees directly to all transactions is certainly one way to use that, but it's not the only way. As noted above, our competitors prefer a combination of price-hiding and cross subsidisation. Both of these can be implemented with tx fees, but not necessarily by trying to artificially limit supply, which is economically nonsensical.
We’re already more than six years into this. When were these mechanisms going to be developed and tested? After 10 years? 20? Perhaps after 1024 years?(https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki <https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki>)
Right. Turns out the ledger structure is terrible for constructing the kinds of proofs that are most important to validators - i.e. whether an output exists, what its script and amounts are, whether it’s been spent, etc

Validators don't require proofs. That's why they are validators.
I think you're trying to say the block chain doesn't provide the kinds of proofs that are most important to lightweight wallets. But I would disagree. Even with UTXO commitments, there can still be double spends out there in the networks memory pools you are unaware of. Merely being presented with a correctly signed transaction doesn't tell you a whole lot ..... if you wait for a block, you get the same level of proof regardless of whether there are UTXO commitments or not. If you don't then you still have to have some trust in your peers that you are seeing an accurate and full view of network traffic.
So whilst there are ways to make the protocol incrementally better, when you work through the use cases for these sorts of data structures and ask "how will this impact the user experience", the primary candidates so far don't seem to make much difference.
Remote attestation from secure hardware would make a big difference though. Then you could get rid of the waiting times entirely because you know the sending wallet won't double spend.
Yes, let’s wait until things are about to break before even beginning to address the issue
because we can “easily create” anything we haven’t invented yet at the last minute.
bitcoinj already has a micropayment channel implementation in it. There's a bit of work required to glue everything together, but it's not a massive project to start using this to pay nodes for their services.
But it's not needed right now: serving these clients is so darn cheap. And there is plenty of room for optimising things still further!
I’m one of the very few developers in this space that has actually tried *hard* to make your BIP37 work. Amongst the desktop wallets listed on bitcoin.org <http://bitcoin.org/>, there are only two that have always supported SPV (or at least I think MultiBit has always supported it, perhaps I’m wrong). One is MultiBit, the other one is mine. I give you credit for your work
perhaps you could be generous enough to extend me some credit too?
MultiBit has always supported it. I apologise for implying you have not built a wallet. I think yours is mSIGNA, right? Did it used to be called something else? I recognise the website design but must admit, I have not heard of mSIGNA before.
Regardless, as a fellow implementor, I would appreciate it more if you designed and implemented upgrades, rather than just trashing the work done so far as "notoriously terrible", Satoshi as "not a systems architect" and so on.

[Thomas Zander via bitcoin-dev]

Point is…processing blocks requires computational resources that someone
needs to put up. Unless the people who are putting up these resources are
properly incentivized to continue doing it, the network will fail.

This assumption is proven wrong by history.
Take a look at the RC5 challance, and its related cousins like the folding-at-
home or seti-at-home.

Next to that, there is incentive for running a node. It is that you don't have
to trust someone else. This incentive has in business always been a very
strong motivator. See how many companies run Outlook on their own intranet
instead of using Outlook.com or similarly in the cloud.

In my own opinion, its waaay to early to call failure on running nodes. Maybe
you want to actually help merchants/chains/individuals run them by making
bitcoin-core more useful for them.

What is the reason people don't run it? Well, reddit says its because of the
upstream bandwidth not being able to be throttled. What about you try working
on that instead of giving up on it?

[Raystonn . via bitcoin-dev]

Eric, any plans to correct your article at https://bitcoinmagazine.com/21377/settling-block-size-debate/?


From: Mike Hearn via bitcoin-dev
Sent: Wednesday, July 29, 2015 4:15 AM
To: Eric Lombrozo
Cc: Bitcoin Dev
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary

Irrelevant what term was used - and as brilliant as Satoshi might have been at some things, he obviously got this one wrong.

I don't think it's obvious. You may disagree, but don't pretend any of this stuff is obvious.

Consider this: the highest Bitcoin tx fees can possibly go is perhaps a little higher than what our competition charges. Too much higher than that, and people will just say, you know what .... I'll make a bank transfer. It's cheaper and not much slower, sometimes no slower at all.

And now consider that in many parts of the world bank transfers are free.

They aren't actually free, of course, but they appear to be free because the infrastructure for doing them is cross subsidised by the fees on other products and services, or hidden in the prices of goods sold.

So that's a market reality Bitcoin has to handle. It's already more expensive than the competition sometimes, but luckily not much more, and anyway Bitcoin has some features those other systems lack (and vice versa). So it can still be competitive.

But your extremely vague notion of a "fee market" neglects to consider that it already exists, and it's not a market of "Bitcoin users buying space in Bitcoin blocks". It's "users paying to move money".

You can argue with this sort of economic logic if you like, but don't claim this stuff is obvious.

Nobody threatened to start mining huge blocks given how relatively inexpensive it was to mine back then?


Not that I recall. It wasn't a response to any actual event, I think, but rather a growing realisation that the code was full of DoS attacks.


Guess what? SPV wallets are still not particularly widespread
and those that are out there are notoriously terrible at detecting network forks and making sure they are on the right one.

The most popular mobile wallet (measured by installs) on Android is SPV. It has between 500,000 and 1 million installs, whilst Coinbase has not yet crossed the 500,000 mark. One of the most popular wallets on iOS is SPV. If we had SPV wallets with better user interfaces on desktops, they'd be more popular there too (perhaps MultiBit HD can recapture some lost ground).

So I would argue that they are in fact very widespread.

Likewise, they are not "notoriously terrible" at detecting chain forks. That's a spurious idea that you and Patrick have been pushing lately, but they detect them and follow reorgs across them according to the SPV algorithm, which is based on most work done. This is exactly what they are designed to do.

Contrast this with other lightweight wallets which either don't examine the block chain or implement the algorithm incorrectly, and I fail to see how this can be described as "notoriously terrible".



I understand that initially it was desirable that transactions be free
but surely even Satoshi understood this couldn’t be perpetually self-sustaining
and that the ability to bid for inclusion in blocks would eventually become a crucial component of the network. Or were fees just added for decoration?


Fees were added as a way to get money to miners in a fair and decentralised way.

Attaching fees directly to all transactions is certainly one way to use that, but it's not the only way. As noted above, our competitors prefer a combination of price-hiding and cross subsidisation. Both of these can be implemented with tx fees, but not necessarily by trying to artificially limit supply, which is economically nonsensical.


We’re already more than six years into this. When were these mechanisms going to be developed and tested? After 10 years? 20? Perhaps after 1024 years?(https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki)


Maybe when there is a need? I already discussed this topic of need here:

https://medium.com/@octskyward/hashing-7d04a887acc8


Right. Turns out the ledger structure is terrible for constructing the kinds of proofs that are most important to validators - i.e. whether an output exists, what its script and amounts are, whether it’s been spent, etc



Validators don't require proofs. That's why they are validators.

I think you're trying to say the block chain doesn't provide the kinds of proofs that are most important to lightweight wallets. But I would disagree. Even with UTXO commitments, there can still be double spends out there in the networks memory pools you are unaware of. Merely being presented with a correctly signed transaction doesn't tell you a whole lot ..... if you wait for a block, you get the same level of proof regardless of whether there are UTXO commitments or not. If you don't then you still have to have some trust in your peers that you are seeing an accurate and full view of network traffic.

So whilst there are ways to make the protocol incrementally better, when you work through the use cases for these sorts of data structures and ask "how will this impact the user experience", the primary candidates so far don't seem to make much difference.

Remote attestation from secure hardware would make a big difference though. Then you could get rid of the waiting times entirely because you know the sending wallet won't double spend.


Yes, let’s wait until things are about to break before even beginning to address the issue
because we can “easily create” anything we haven’t invented yet at the last minute.


bitcoinj already has a micropayment channel implementation in it. There's a bit of work required to glue everything together, but it's not a massive project to start using this to pay nodes for their services.

But it's not needed right now: serving these clients is so darn cheap. And there is plenty of room for optimising things still further!


I’m one of the very few developers in this space that has actually tried *hard* to make your BIP37 work. Amongst the desktop wallets listed on bitcoin.org, there are only two that have always supported SPV (or at least I think MultiBit has always supported it, perhaps I’m wrong). One is MultiBit, the other one is mine. I give you credit for your work
perhaps you could be generous enough to extend me some credit too?

MultiBit has always supported it. I apologise for implying you have not built a wallet. I think yours is mSIGNA, right? Did it used to be called something else? I recognise the website design but must admit, I have not heard of mSIGNA before.

Regardless, as a fellow implementor, I would appreciate it more if you designed and implemented upgrades, rather than just trashing the work done so far as "notoriously terrible", Satoshi as "not a systems architect" and so on.



--------------------------------------------------------------------------------

[Owen via bitcoin-dev]

Post by Mike Hearn via bitcoin-dev
Consider this: the highest Bitcoin tx fees can possibly go is perhaps a
little higher than what our competition charges. Too much higher than that,
and people will just say, you know what .... I'll make a bank transfer.
It's cheaper and not much slower, sometimes no slower at all.

I respectfully disagree with this analysis. The implication is that bitcoin is merely one of a number of payment technologies. It's much more than that. It's sound money, censorship resistance, personal control over money, programmable money, and more. Without these attributes it's merely a really inefficient way to do payments.

Given these advantages, there is no reason to believe the marginal cost of a transaction can't far surpass that of a PayPal or bank transfer. I personally would pay several multiples of the competitors' fees to continue using bitcoin.

Sure, some marginal use cases will drop off with greater fees, but that's normal and expected. These will be use cases where the user doesn't care about bitcoin's advantages. We must be willing to let these use cases go anyway, because we unfortunately don't have room on chain for everything anyone might want to do.

Therefore, bitcoin tx fees can go much higher than the competition.

Remember how Satoshi referenced the banking crisis in his early work? The 2008 banking crisis was about a lot of things, but high credit card and paypal fees wasnt one of them. There's more going on here than just payments. Any speculative economic analysis would do better to include this fact.

[Gregory Maxwell via bitcoin-dev]

On Wed, Jul 29, 2015 at 7:56 PM, Owen via bitcoin-dev

Post by Owen via bitcoin-dev

Post by Mike Hearn via bitcoin-dev
Consider this: the highest Bitcoin tx fees can possibly go is perhaps a
little higher than what our competition charges. Too much higher than that,
and people will just say, you know what .... I'll make a bank transfer.
It's cheaper and not much slower, sometimes no slower at all.

I respectfully disagree with this analysis. The implication is that bitcoin is merely one of a number of payment technologies. It's much more than that. It's sound money, censorship resistance, personal control over money, programmable money, and more. Without these attributes it's merely a really inefficient way to do payments.
Given these advantages, there is no reason to believe the marginal cost of a transaction can't far surpass that of a PayPal or bank transfer. I personally would pay several multiples of the competitors' fees to continue using bitcoin.
Sure, some marginal use cases will drop off with greater fees, but that's normal and expected. These will be use cases where the user doesn't care about bitcoin's advantages. We must be willing to let these use cases go anyway, because we unfortunately don't have room on chain for everything anyone might want to do.
Therefore, bitcoin tx fees can go much higher than the competition.
Remember how Satoshi referenced the banking crisis in his early work? The 2008 banking crisis was about a lot of things, but high credit card and paypal fees wasnt one of them. There's more going on here than just payments. Any speculative economic analysis would do better to include this fact.

Precisely. And as "just a payment system" Bitcoin is not an
especially great one: The design requirements for decenteralization
impose considerable costs. To the extent that the technology in
Bitcoin is useful at all for building "just another payment system"
this technology in in the process of being agressively copied by
parties with deep fiat relationships (including in partnership with
centeral banks). If the focus for Bitcoin's competative advantage
becomes exclusively "better" payments then it will almost certinatly
fail in the market-place against competing systems which avoid the
Bitcoin currency adoption related obsticles (but also gain none of
Bitcoin's important social/political promise).

Also, critically, if Bitcoin's security properties are manintained and
enhanced then Bitcoin can be used to build secure systems which _also_
accomidate those applications and we can have both. But if Bitcoin's
security properties are not strong then then advanced tools cannot be
built for it. E.g. atomic swaps make trustless trades with external
systems possible; but they are especially sensitive to long
reorginizations by miners... so they can only be securely used where
those reorgs are infeasable. So while I agree that we must be willing
to tolerate not catching every conceivable use case; most of the time
all that means is addressing them via a less direct but more focused
solution rather than ignoring them completely.

[Raystonn . via bitcoin-dev]

Gregory, can you please speak to the following points. I would like a
better understanding of your positions.

1) Do you believe that Bitcoin's future is as a high-value settlement
network?

2) Do you believe we need an artificial limit to transaction rate, perhaps
implemented as a maximum block size limit? If so, why?

3) Transaction fees will fluctuate with global economic conditions and
technology. Those free-market fluctuations should equally affect any
blockchain. However, if transaction fees on the Bitcoin network are pushed
artificially high, such as with an artificial limit to transaction rate only
applicable to Bitcoin, this will create a condition where some other
blockchains will have lower fees. How do you plan to address the bleeding
of value from Bitcoin to alternative lower-fee blockchains created by the
artificially-high bitcoin transaction fees when users begin looking for the
cheapest way to send value? Modern economic study has shown that liquidity
moves to the location of least friction.

4) If you believe it's not a problem to allow alternative blockchains to
leech some of Bitcoin's value, then:
a) How much value is it acceptable to lose?
b) How do you think this will affect Bitcoin miners, whose large
investments in hardware do not transfer to other blockchains?
c) How do you think this will affect the investors and holders of
bitcoin in general?


-----Original Message-----
From: Gregory Maxwell via bitcoin-dev
Sent: Wednesday, July 29, 2015 1:09 PM
To: Owen
Cc: Bitcoin Dev
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
isn'ttemporary

On Wed, Jul 29, 2015 at 7:56 PM, Owen via bitcoin-dev

Post by Owen via bitcoin-dev

Post by Mike Hearn via bitcoin-dev
Consider this: the highest Bitcoin tx fees can possibly go is perhaps a
little higher than what our competition charges. Too much higher than that,
and people will just say, you know what .... I'll make a bank transfer.
It's cheaper and not much slower, sometimes no slower at all.

I respectfully disagree with this analysis. The implication is that
bitcoin is merely one of a number of payment technologies. It's much more
than that. It's sound money, censorship resistance, personal control over
money, programmable money, and more. Without these attributes it's merely
a really inefficient way to do payments.
Given these advantages, there is no reason to believe the marginal cost of
a transaction can't far surpass that of a PayPal or bank transfer. I
personally would pay several multiples of the competitors' fees to
continue using bitcoin.
Sure, some marginal use cases will drop off with greater fees, but that's
normal and expected. These will be use cases where the user doesn't care
about bitcoin's advantages. We must be willing to let these use cases go
anyway, because we unfortunately don't have room on chain for everything
anyone might want to do.
Therefore, bitcoin tx fees can go much higher than the competition.
Remember how Satoshi referenced the banking crisis in his early work? The
2008 banking crisis was about a lot of things, but high credit card and
paypal fees wasnt one of them. There's more going on here than just
payments. Any speculative economic analysis would do better to include
this fact.

Precisely. And as "just a payment system" Bitcoin is not an
especially great one: The design requirements for decenteralization
impose considerable costs. To the extent that the technology in
Bitcoin is useful at all for building "just another payment system"
this technology in in the process of being agressively copied by
parties with deep fiat relationships (including in partnership with
centeral banks). If the focus for Bitcoin's competative advantage
becomes exclusively "better" payments then it will almost certinatly
fail in the market-place against competing systems which avoid the
Bitcoin currency adoption related obsticles (but also gain none of
Bitcoin's important social/political promise).

Also, critically, if Bitcoin's security properties are manintained and
enhanced then Bitcoin can be used to build secure systems which _also_
accomidate those applications and we can have both. But if Bitcoin's
security properties are not strong then then advanced tools cannot be
built for it. E.g. atomic swaps make trustless trades with external
systems possible; but they are especially sensitive to long
reorginizations by miners... so they can only be securely used where
those reorgs are infeasable. So while I agree that we must be willing
to tolerate not catching every conceivable use case; most of the time
all that means is addressing them via a less direct but more focused
solution rather than ignoring them completely.

[Venzen Khaosan via bitcoin-dev]

Raystonn, I'm aware that you're addressing your question to Greg
Maxwell, however a point you keep stating as fact calls for reference:

On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote:
[snip]

How do you plan to address the bleeding of value from Bitcoin to
alternative lower-fee blockchains created by the artificially-high
bitcoin transaction fees when users begin looking for the cheapest
way to send value?

Cheapest way to send value? Is this what Bitcoin is trying to do? So
all of the smart contract, programmable money, consensus coding and
tremendous developer effort is bent to the consumer demand for cheaper
fees. Surely thou jests!

Modern economic study has shown that liquidity moves to the
location of least friction.

Modern economic study? Can you please provide a link or reference to
the study you are referring to.

"liquidity moves to the location of least friction"

This sounds like "econo-speak" and makes no sense. The definition of
Liquidity is the degree to which an asset/security can be bought or
sold in the market without affecting the price.

That is why bitcoin is said to have low liquidity: buying or selling
only 100 BTC visibly affects the exchange price. You probably mean
"people like cheap fees", which is true, but as others have said,
because of Bitcoin's powerful features, they are willing to pay higher
fees and wait longer for transactions to execute.

As for your public cross-examination of Greg Maxwell, your case seems
to be made on the assumption that limiting the size of the blockchain
is an attempt to artificially raise tx fees, but it is not the case
(as you and others repeatedly argue) that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately, as a
means of protecting its degree of decentralization.

Surely, this is an obvious concern even for those who are campaigning
for the hare-brained ideal of making Bitcoin a "faster, cheaper
alternative" to visa or paypal? If we lose decentralization, we lose
the whole thing, right? Incorrect or correct?

[Raystonn . via bitcoin-dev]

Post by Venzen Khaosan via bitcoin-dev
Cheapest way to send value? Is this what Bitcoin is trying to do? So
all of the smart contract, programmable money, consensus coding and
tremendous developer effort is bent to the consumer demand for cheaper
fees. Surely thou jests!

These other features can be replicated into any alternative blockchain,
including those with lower fees. In the open-source world of
cryptocurrency, no feature will remain a value-add for very long after it
has been identified to be such. Anything adding value will quickly be
absorbed into competing alternative blockchains. That will leave economic
policy as the distinguishing factor.

Post by Venzen Khaosan via bitcoin-dev
... it is not the case ... that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately, as a
means of protecting its degree of decentralization.

A slow or lack of increase to maximum transaction rate will cause pressure
on fees. Whether this is the desired goal is not relevant. Everyone has
agreed this will be the outcome. As to a smaller block size being needed
for additional decentralization, one must simply ask how much we are all
willing to pay for that additional decentralization. It is likely that the
benefit thereto will have to be demonstrated by some power attacking and
destroying a less decentralized currency before the benefit of this feature
is given monetary value by the market. Until then, value will bleed to the
network with the least friction, because it will have the greatest ability
to grow its network effect. That means the blockchain with adequate
features and cheapest fees will eventually have the largest market share.


-----Original Message-----
From: Venzen Khaosan
Sent: Wednesday, July 29, 2015 3:11 PM
To: Raystonn .
Cc: bitcoin-***@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
isn'ttemporary

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Raystonn, I'm aware that you're addressing your question to Greg
Maxwell, however a point you keep stating as fact calls for reference:

On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote:
[snip]

Post by Venzen Khaosan via bitcoin-dev
How do you plan to address the bleeding of value from Bitcoin to
alternative lower-fee blockchains created by the artificially-high
bitcoin transaction fees when users begin looking for the cheapest
way to send value?

Cheapest way to send value? Is this what Bitcoin is trying to do? So
all of the smart contract, programmable money, consensus coding and
tremendous developer effort is bent to the consumer demand for cheaper
fees. Surely thou jests!

Post by Venzen Khaosan via bitcoin-dev
Modern economic study has shown that liquidity moves to the
location of least friction.

Modern economic study? Can you please provide a link or reference to
the study you are referring to.

"liquidity moves to the location of least friction"

This sounds like "econo-speak" and makes no sense. The definition of
Liquidity is the degree to which an asset/security can be bought or
sold in the market without affecting the price.

That is why bitcoin is said to have low liquidity: buying or selling
only 100 BTC visibly affects the exchange price. You probably mean
"people like cheap fees", which is true, but as others have said,
because of Bitcoin's powerful features, they are willing to pay higher
fees and wait longer for transactions to execute.

As for your public cross-examination of Greg Maxwell, your case seems
to be made on the assumption that limiting the size of the blockchain
is an attempt to artificially raise tx fees, but it is not the case
(as you and others repeatedly argue) that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately, as a
means of protecting its degree of decentralization.

Surely, this is an obvious concern even for those who are campaigning
for the hare-brained ideal of making Bitcoin a "faster, cheaper
alternative" to visa or paypal? If we lose decentralization, we lose
the whole thing, right? Incorrect or correct?

[Adam Back via bitcoin-dev]

I dont think people consider other blockchains as a competitive
threat. A PoW-blockchain is a largely singleton data structure for
security reasons (single highest hashrate), it is hard for an
alternative chain to bootstrap or provide meaningful security.
Secondly the world largely lacks expertise to maintain a blockchain to
bitcoin's security level, perhaps you can see a hint of this in the
recently disclosed security vulnerability by Pieter Wuille and Gregory
Maxwell. Calls to this as an argument are not resonating and probably
not helping your argument. Bitcoin has security properties, and a
competing system cant achieve better properties by bypassing security,
any blockchain faces the same fundamental security / decentralisation
limitations.

Secondly Bitcoin can obviously compete with itself with different
parameters and defacto *does* today. I think it is a safe estimate
that > 99% of Bitcoin transactions right now are happening in Bitcoin
related systems with various degrees of audit, reconciliation,
provable reserves etc. I think we can expect this to continue and
become more secure via more reconciliation, and longer term via
lightning or Bitcoin sidechains with different parameters. It is a
different story to have a single central system (Bitcoin with
parameters changed to the point of centralisation failure) vs having
multiple choices, because some transactions can more easily use
relatively centralised systems (eg micropayments), and more
interestingly the combination of a secure and decentralised layer 1
plus choices of less decentralised layer 2 options, can be interesting
because the layer 2 is provided cover from attack. There is less to
be gained by attacking relatively centralised layer 2 because any
payments at risk of policy abuse (which is typically a small subset)
can easily switch to layer 1. That in itself makes layer 2
transactions also less susceptible to policy abuse. Further lightning
it appears from work so far should add significant scale while
retaining trustlessness and a good degree of decentralisation.

Finally you seem to be focusing on "artificial" limits where that is
not the issue under consideration. The limits are technical and
relating to decentralisation and security. I wont go over them again
as this topic has been covered many times in recent months. Any chain
that tried to go to extreme parameters (very low block intervals, or
very large blocksizes) would have the same decentralisation problems
as Bitcoin would if it did the same thing. There are a number of alt
coins that have failed as a result of poor parameter choices, there
are inherent security limits.

Adam

ps Etiquette note for yourself and others: please dont be repetitive
or attempt to be forceful. Many people have spent many years
understanding this very complex system, from my own experience it is
rare indeed to think of an entirely new concept or analysis, that
hasnt' been long considered and put to bed 3 or 4 years ago.
Thoughtful polite and constructive comments are welcome but I
recommend to not start from an assumption that you have a clear and
better insight than the entire technical community, because I have to
say from my own experience that is very rarely the case. It can be
useful to test theories on #bitcoin IRC channel to find out what has
been already concluded, find the references and avoid having to have
that hashed out on this list which is trying to be focussed on
technical solutions.


On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev

Post by Raystonn . via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev
Cheapest way to send value? Is this what Bitcoin is trying to do? So
all of the smart contract, programmable money, consensus coding and
tremendous developer effort is bent to the consumer demand for cheaper
fees. Surely thou jests!

These other features can be replicated into any alternative blockchain,
including those with lower fees. In the open-source world of
cryptocurrency, no feature will remain a value-add for very long after it
has been identified to be such. Anything adding value will quickly be
absorbed into competing alternative blockchains. That will leave economic
policy as the distinguishing factor.

Post by Venzen Khaosan via bitcoin-dev
... it is not the case ... that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately, as a
means of protecting its degree of decentralization.

A slow or lack of increase to maximum transaction rate will cause pressure
on fees. Whether this is the desired goal is not relevant. Everyone has
agreed this will be the outcome. As to a smaller block size being needed
for additional decentralization, one must simply ask how much we are all
willing to pay for that additional decentralization. It is likely that the
benefit thereto will have to be demonstrated by some power attacking and
destroying a less decentralized currency before the benefit of this feature
is given monetary value by the market. Until then, value will bleed to the
network with the least friction, because it will have the greatest ability
to grow its network effect. That means the blockchain with adequate
features and cheapest fees will eventually have the largest market share.
-----Original Message----- From: Venzen Khaosan
Sent: Wednesday, July 29, 2015 3:11 PM
To: Raystonn .
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
isn'ttemporary
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Raystonn, I'm aware that you're addressing your question to Greg
[snip]

Post by Venzen Khaosan via bitcoin-dev
How do you plan to address the bleeding of value from Bitcoin to
alternative lower-fee blockchains created by the artificially-high
bitcoin transaction fees when users begin looking for the cheapest
way to send value?

Cheapest way to send value? Is this what Bitcoin is trying to do? So
all of the smart contract, programmable money, consensus coding and
tremendous developer effort is bent to the consumer demand for cheaper
fees. Surely thou jests!

Post by Venzen Khaosan via bitcoin-dev
Modern economic study has shown that liquidity moves to the
location of least friction.

Modern economic study? Can you please provide a link or reference to
the study you are referring to.
"liquidity moves to the location of least friction"
This sounds like "econo-speak" and makes no sense. The definition of
Liquidity is the degree to which an asset/security can be bought or
sold in the market without affecting the price.
That is why bitcoin is said to have low liquidity: buying or selling
only 100 BTC visibly affects the exchange price. You probably mean
"people like cheap fees", which is true, but as others have said,
because of Bitcoin's powerful features, they are willing to pay higher
fees and wait longer for transactions to execute.
As for your public cross-examination of Greg Maxwell, your case seems
to be made on the assumption that limiting the size of the blockchain
is an attempt to artificially raise tx fees, but it is not the case
(as you and others repeatedly argue) that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately, as a
means of protecting its degree of decentralization.
Surely, this is an obvious concern even for those who are campaigning
for the hare-brained ideal of making Bitcoin a "faster, cheaper
alternative" to visa or paypal? If we lose decentralization, we lose
the whole thing, right? Incorrect or correct?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB
RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp
h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz
Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS
YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx
BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=
=lQvy
-----END PGP SIGNATURE-----
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Andrew LeCody via bitcoin-dev]

tl;dr
$100 worth of hardware and $1/mo of expenses, should be able to run a full
Bitcoin node until 2020 with BIP101-size blocks.

----

I got into Bitcoin in the summer of 2010. I'm not a cryptographer, up until
recently my profession has been as a server administrator or systems
engineer.

I'd like to take a second to address the concern that larger blocks would
make it harder to run a full node on limited hardware and would therefore
hurt decentralization. I run two nodes today, one on server-grade hardware
at a datacenter and another on a mini-ITX Atom (dual core) system at my
home.

I detailed the operational costs of my home node today on reddit:
https://www.reddit.com/r/Bitcoin/comments/3f0h8e/mike_h_shuts_down_eric_ls_attempt_to_rewrite/ctkigpr

If I was a new user, wanting to run a full node. The most cost effective
way would likely be with a Raspberry Pi 2 and a 2TB external HDD. Total
cost about $100, including charger, microSD card, etc. That is less than
the cost of a TREZOR hardware wallet. As far as home projects go, not
terribly expensive.

Next, it will need power. According to the Wikipedia article, the rpi 2
model B uses 3.5 watts of power max. The 2TB external drive will draw about
5 watts at max. That's a total of 8.5 watts or 6.205 Kwh per month. In my
area (North Texas) power is about $0.10/Kwh, which means my little node
costs $0.62 per month in power.

Last, lets look at bandwidth. It's difficult to quantify bandwidth cost in
the same way because this is a home connection, mainly because I don't know
how to price in the loss of enjoyment if the system impacts my Internet
usage to a noticeable degree. Luckily, I have some real world data from my
existing home node. Here is the last month:
http://imgur.com/YmJwQpN

This system averages 120 Kbps in and 544 Kbps out. Note, this data is
somewhat skewed, because the system is also used for seeding torrents of
various open source projects. The Bitcoin node itself is typically
connected to about 20 peers at any given time (maxconnections=20).

Subjectively, my wife and I have never noticed any degradation of
performance due to my home server using too much bandwidth. I think it's
safe to say that I can treat the bandwidth is uses as effectively free,
since it's piggybacking on a connection I would be paying for even if I was
not running a Bitcoin node. The bandwidth usage of this Bitcoin node could
increase significantly, without any noticeable impact. If it did, I could
always lower maxconnections back to 8.

The only real constraint seems to be hard drive space, as the full
blockchain and indexes take up about 50GB of space currently. If BIP101 is
implemented, 2TB of storage should be enough for me to continue running my
hypothetical $100 node until about 2020.

It seems to me that at least for the next 5 years, the "small devices" of
today can easily run Bitcoin nodes with BIP101-size blocks, with very
little operational cost.

If anyone would like more detailed data on my existing nodes, please let me
know and I'll attempt to provide it (so long as it doesn't impact my
privacy of course).

On Wed, Jul 29, 2015 at 10:49 PM Adam Back via bitcoin-dev <

Post by Adam Back via bitcoin-dev
I dont think people consider other blockchains as a competitive
threat. A PoW-blockchain is a largely singleton data structure for
security reasons (single highest hashrate), it is hard for an
alternative chain to bootstrap or provide meaningful security.
Secondly the world largely lacks expertise to maintain a blockchain to
bitcoin's security level, perhaps you can see a hint of this in the
recently disclosed security vulnerability by Pieter Wuille and Gregory
Maxwell. Calls to this as an argument are not resonating and probably
not helping your argument. Bitcoin has security properties, and a
competing system cant achieve better properties by bypassing security,
any blockchain faces the same fundamental security / decentralisation
limitations.
Secondly Bitcoin can obviously compete with itself with different
parameters and defacto *does* today. I think it is a safe estimate
that > 99% of Bitcoin transactions right now are happening in Bitcoin
related systems with various degrees of audit, reconciliation,
provable reserves etc. I think we can expect this to continue and
become more secure via more reconciliation, and longer term via
lightning or Bitcoin sidechains with different parameters. It is a
different story to have a single central system (Bitcoin with
parameters changed to the point of centralisation failure) vs having
multiple choices, because some transactions can more easily use
relatively centralised systems (eg micropayments), and more
interestingly the combination of a secure and decentralised layer 1
plus choices of less decentralised layer 2 options, can be interesting
because the layer 2 is provided cover from attack. There is less to
be gained by attacking relatively centralised layer 2 because any
payments at risk of policy abuse (which is typically a small subset)
can easily switch to layer 1. That in itself makes layer 2
transactions also less susceptible to policy abuse. Further lightning
it appears from work so far should add significant scale while
retaining trustlessness and a good degree of decentralisation.
Finally you seem to be focusing on "artificial" limits where that is
not the issue under consideration. The limits are technical and
relating to decentralisation and security. I wont go over them again
as this topic has been covered many times in recent months. Any chain
that tried to go to extreme parameters (very low block intervals, or
very large blocksizes) would have the same decentralisation problems
as Bitcoin would if it did the same thing. There are a number of alt
coins that have failed as a result of poor parameter choices, there
are inherent security limits.
Adam
ps Etiquette note for yourself and others: please dont be repetitive
or attempt to be forceful. Many people have spent many years
understanding this very complex system, from my own experience it is
rare indeed to think of an entirely new concept or analysis, that
hasnt' been long considered and put to bed 3 or 4 years ago.
Thoughtful polite and constructive comments are welcome but I
recommend to not start from an assumption that you have a clear and
better insight than the entire technical community, because I have to
say from my own experience that is very rarely the case. It can be
useful to test theories on #bitcoin IRC channel to find out what has
been already concluded, find the references and avoid having to have
that hashed out on this list which is trying to be focussed on
technical solutions.
On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev

Post by Raystonn . via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev
Cheapest way to send value? Is this what Bitcoin is trying to do? So
all of the smart contract, programmable money, consensus coding and
tremendous developer effort is bent to the consumer demand for cheaper
fees. Surely thou jests!

These other features can be replicated into any alternative blockchain,
including those with lower fees. In the open-source world of
cryptocurrency, no feature will remain a value-add for very long after it
has been identified to be such. Anything adding value will quickly be
absorbed into competing alternative blockchains. That will leave

economic

Post by Raystonn . via bitcoin-dev
policy as the distinguishing factor.

Post by Venzen Khaosan via bitcoin-dev
... it is not the case ... that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately, as a
means of protecting its degree of decentralization.

A slow or lack of increase to maximum transaction rate will cause

pressure

Post by Raystonn . via bitcoin-dev
on fees. Whether this is the desired goal is not relevant. Everyone has
agreed this will be the outcome. As to a smaller block size being needed
for additional decentralization, one must simply ask how much we are all
willing to pay for that additional decentralization. It is likely that

the

Post by Raystonn . via bitcoin-dev
benefit thereto will have to be demonstrated by some power attacking and
destroying a less decentralized currency before the benefit of this

feature

Post by Raystonn . via bitcoin-dev
is given monetary value by the market. Until then, value will bleed to

the

Post by Raystonn . via bitcoin-dev
network with the least friction, because it will have the greatest

ability

Post by Raystonn . via bitcoin-dev
to grow its network effect. That means the blockchain with adequate
features and cheapest fees will eventually have the largest market share.
-----Original Message----- From: Venzen Khaosan
Sent: Wednesday, July 29, 2015 3:11 PM
To: Raystonn .
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
isn'ttemporary
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Raystonn, I'm aware that you're addressing your question to Greg
[snip]

Post by Venzen Khaosan via bitcoin-dev
How do you plan to address the bleeding of value from Bitcoin to
alternative lower-fee blockchains created by the artificially-high
bitcoin transaction fees when users begin looking for the cheapest
way to send value?

Cheapest way to send value? Is this what Bitcoin is trying to do? So
all of the smart contract, programmable money, consensus coding and
tremendous developer effort is bent to the consumer demand for cheaper
fees. Surely thou jests!

Post by Venzen Khaosan via bitcoin-dev
Modern economic study has shown that liquidity moves to the
location of least friction.

Modern economic study? Can you please provide a link or reference to
the study you are referring to.
"liquidity moves to the location of least friction"
This sounds like "econo-speak" and makes no sense. The definition of
Liquidity is the degree to which an asset/security can be bought or
sold in the market without affecting the price.
That is why bitcoin is said to have low liquidity: buying or selling
only 100 BTC visibly affects the exchange price. You probably mean
"people like cheap fees", which is true, but as others have said,
because of Bitcoin's powerful features, they are willing to pay higher
fees and wait longer for transactions to execute.
As for your public cross-examination of Greg Maxwell, your case seems
to be made on the assumption that limiting the size of the blockchain
is an attempt to artificially raise tx fees, but it is not the case
(as you and others repeatedly argue) that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately, as a
means of protecting its degree of decentralization.
Surely, this is an obvious concern even for those who are campaigning
for the hare-brained ideal of making Bitcoin a "faster, cheaper
alternative" to visa or paypal? If we lose decentralization, we lose
the whole thing, right? Incorrect or correct?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB
RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp
h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz
Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS
YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx
BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=
=lQvy
-----END PGP SIGNATURE-----
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Eric Lombrozo via bitcoin-dev]

I usually avoid troll-infested Dunning-Kruger-gone-wild fests like reddit, so I’ll leave that to others.

But I do want to clarify a couple things here, though, Andrew.

First of all, the issue is not about whether it is affordable for a highly motivated, technically skilled person to continue running a node even if we increase block size by a factor of X. This misses the point for at least a couple reasons:

- Regardless of what that X is, it isn’t really going to be what makes this technology accessible to the masses. We would likely need the X to be in the thousands before we start to really take on players like Visa. Despite what people might have thought in 2009, it turns out Bitcoin is probably pretty ill-suited as a database in which to store the entire transaction history of the entire world. It’s looking to be more of a censorship-resistant dispute resolution mechanism that provides very well-defined settlement guarantees with the potential for encoding complex rules. It’s possible to build higher level tiers on top of it that DO support high volume transaction processing WITHOUT costing thousands of times more, and these approaches are looking quite promising. However, it doesn’t seem very many people in this space quite grasp this paradigm shift yet.

- What matters is not how a relatively small number of well-intentioned people in the network behave. What matters is how the network behaves as a whole
and a number of the people most intimately familiar with the inner workings of the system (some of whom are in this thread) think that given what we now today about the Bitcoin network, increasing block size externalizes costs in dangerous ways. Remember that total cost includes not just equipment costs but also things like block propagation latency and specifically identified security risks. Some of these security risks were only appreciated relatively recently and were completely unknown in 2009.

Post by Andrew LeCody via bitcoin-dev
tl;dr
$100 worth of hardware and $1/mo of expenses, should be able to run a full
Bitcoin node until 2020 with BIP101-size blocks.
----
I got into Bitcoin in the summer of 2010. I'm not a cryptographer, up until
recently my profession has been as a server administrator or systems
engineer.
I'd like to take a second to address the concern that larger blocks would
make it harder to run a full node on limited hardware and would therefore
hurt decentralization. I run two nodes today, one on server-grade hardware
at a datacenter and another on a mini-ITX Atom (dual core) system at my
home.
https://www.reddit.com/r/Bitcoin/comments/3f0h8e/mike_h_shuts_down_eric_ls_attempt_to_rewrite/ctkigpr
If I was a new user, wanting to run a full node. The most cost effective
way would likely be with a Raspberry Pi 2 and a 2TB external HDD. Total
cost about $100, including charger, microSD card, etc. That is less than
the cost of a TREZOR hardware wallet. As far as home projects go, not
terribly expensive.
Next, it will need power. According to the Wikipedia article, the rpi 2
model B uses 3.5 watts of power max. The 2TB external drive will draw about
5 watts at max. That's a total of 8.5 watts or 6.205 Kwh per month. In my
area (North Texas) power is about $0.10/Kwh, which means my little node
costs $0.62 per month in power.
Last, lets look at bandwidth. It's difficult to quantify bandwidth cost in
the same way because this is a home connection, mainly because I don't know
how to price in the loss of enjoyment if the system impacts my Internet
usage to a noticeable degree. Luckily, I have some real world data from my
http://imgur.com/YmJwQpN
This system averages 120 Kbps in and 544 Kbps out. Note, this data is
somewhat skewed, because the system is also used for seeding torrents of
various open source projects. The Bitcoin node itself is typically
connected to about 20 peers at any given time (maxconnections=20).
Subjectively, my wife and I have never noticed any degradation of
performance due to my home server using too much bandwidth. I think it's
safe to say that I can treat the bandwidth is uses as effectively free,
since it's piggybacking on a connection I would be paying for even if I was
not running a Bitcoin node. The bandwidth usage of this Bitcoin node could
increase significantly, without any noticeable impact. If it did, I could
always lower maxconnections back to 8.
The only real constraint seems to be hard drive space, as the full
blockchain and indexes take up about 50GB of space currently. If BIP101 is
implemented, 2TB of storage should be enough for me to continue running my
hypothetical $100 node until about 2020.
It seems to me that at least for the next 5 years, the "small devices" of
today can easily run Bitcoin nodes with BIP101-size blocks, with very
little operational cost.
If anyone would like more detailed data on my existing nodes, please let me
know and I'll attempt to provide it (so long as it doesn't impact my
privacy of course).
On Wed, Jul 29, 2015 at 10:49 PM Adam Back via bitcoin-dev <

Post by Adam Back via bitcoin-dev
I dont think people consider other blockchains as a competitive
threat. A PoW-blockchain is a largely singleton data structure for
security reasons (single highest hashrate), it is hard for an
alternative chain to bootstrap or provide meaningful security.
Secondly the world largely lacks expertise to maintain a blockchain to
bitcoin's security level, perhaps you can see a hint of this in the
recently disclosed security vulnerability by Pieter Wuille and Gregory
Maxwell. Calls to this as an argument are not resonating and probably
not helping your argument. Bitcoin has security properties, and a
competing system cant achieve better properties by bypassing security,
any blockchain faces the same fundamental security / decentralisation
limitations.
Secondly Bitcoin can obviously compete with itself with different
parameters and defacto *does* today. I think it is a safe estimate
that > 99% of Bitcoin transactions right now are happening in Bitcoin
related systems with various degrees of audit, reconciliation,
provable reserves etc. I think we can expect this to continue and
become more secure via more reconciliation, and longer term via
lightning or Bitcoin sidechains with different parameters. It is a
different story to have a single central system (Bitcoin with
parameters changed to the point of centralisation failure) vs having
multiple choices, because some transactions can more easily use
relatively centralised systems (eg micropayments), and more
interestingly the combination of a secure and decentralised layer 1
plus choices of less decentralised layer 2 options, can be interesting
because the layer 2 is provided cover from attack. There is less to
be gained by attacking relatively centralised layer 2 because any
payments at risk of policy abuse (which is typically a small subset)
can easily switch to layer 1. That in itself makes layer 2
transactions also less susceptible to policy abuse. Further lightning
it appears from work so far should add significant scale while
retaining trustlessness and a good degree of decentralisation.
Finally you seem to be focusing on "artificial" limits where that is
not the issue under consideration. The limits are technical and
relating to decentralisation and security. I wont go over them again
as this topic has been covered many times in recent months. Any chain
that tried to go to extreme parameters (very low block intervals, or
very large blocksizes) would have the same decentralisation problems
as Bitcoin would if it did the same thing. There are a number of alt
coins that have failed as a result of poor parameter choices, there
are inherent security limits.
Adam
ps Etiquette note for yourself and others: please dont be repetitive
or attempt to be forceful. Many people have spent many years
understanding this very complex system, from my own experience it is
rare indeed to think of an entirely new concept or analysis, that
hasnt' been long considered and put to bed 3 or 4 years ago.
Thoughtful polite and constructive comments are welcome but I
recommend to not start from an assumption that you have a clear and
better insight than the entire technical community, because I have to
say from my own experience that is very rarely the case. It can be
useful to test theories on #bitcoin IRC channel to find out what has
been already concluded, find the references and avoid having to have
that hashed out on this list which is trying to be focussed on
technical solutions.
On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev

Post by Raystonn . via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev
Cheapest way to send value? Is this what Bitcoin is trying to do? So
all of the smart contract, programmable money, consensus coding and
tremendous developer effort is bent to the consumer demand for cheaper
fees. Surely thou jests!

These other features can be replicated into any alternative blockchain,
including those with lower fees. In the open-source world of
cryptocurrency, no feature will remain a value-add for very long after it
has been identified to be such. Anything adding value will quickly be
absorbed into competing alternative blockchains. That will leave

economic

Post by Raystonn . via bitcoin-dev
policy as the distinguishing factor.

Post by Venzen Khaosan via bitcoin-dev
... it is not the case ... that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately, as a
means of protecting its degree of decentralization.

A slow or lack of increase to maximum transaction rate will cause

pressure

Post by Raystonn . via bitcoin-dev
on fees. Whether this is the desired goal is not relevant. Everyone has
agreed this will be the outcome. As to a smaller block size being needed
for additional decentralization, one must simply ask how much we are all
willing to pay for that additional decentralization. It is likely that

the

Post by Raystonn . via bitcoin-dev
benefit thereto will have to be demonstrated by some power attacking and
destroying a less decentralized currency before the benefit of this

feature

Post by Raystonn . via bitcoin-dev
is given monetary value by the market. Until then, value will bleed to

the

Post by Raystonn . via bitcoin-dev
network with the least friction, because it will have the greatest

ability

Post by Raystonn . via bitcoin-dev
to grow its network effect. That means the blockchain with adequate
features and cheapest fees will eventually have the largest market share.
-----Original Message----- From: Venzen Khaosan
Sent: Wednesday, July 29, 2015 3:11 PM
To: Raystonn .
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
isn'ttemporary
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Raystonn, I'm aware that you're addressing your question to Greg
[snip]

Post by Venzen Khaosan via bitcoin-dev
How do you plan to address the bleeding of value from Bitcoin to
alternative lower-fee blockchains created by the artificially-high
bitcoin transaction fees when users begin looking for the cheapest
way to send value?

Cheapest way to send value? Is this what Bitcoin is trying to do? So
all of the smart contract, programmable money, consensus coding and
tremendous developer effort is bent to the consumer demand for cheaper
fees. Surely thou jests!

Post by Venzen Khaosan via bitcoin-dev
Modern economic study has shown that liquidity moves to the
location of least friction.

Modern economic study? Can you please provide a link or reference to
the study you are referring to.
"liquidity moves to the location of least friction"
This sounds like "econo-speak" and makes no sense. The definition of
Liquidity is the degree to which an asset/security can be bought or
sold in the market without affecting the price.
That is why bitcoin is said to have low liquidity: buying or selling
only 100 BTC visibly affects the exchange price. You probably mean
"people like cheap fees", which is true, but as others have said,
because of Bitcoin's powerful features, they are willing to pay higher
fees and wait longer for transactions to execute.
As for your public cross-examination of Greg Maxwell, your case seems
to be made on the assumption that limiting the size of the blockchain
is an attempt to artificially raise tx fees, but it is not the case
(as you and others repeatedly argue) that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately, as a
means of protecting its degree of decentralization.
Surely, this is an obvious concern even for those who are campaigning
for the hare-brained ideal of making Bitcoin a "faster, cheaper
alternative" to visa or paypal? If we lose decentralization, we lose
the whole thing, right? Incorrect or correct?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB
RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp
h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz
Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS
YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx
BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=
=lQvy
-----END PGP SIGNATURE-----
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Eric Lombrozo via bitcoin-dev]

Post by Eric Lombrozo via bitcoin-dev
I usually avoid troll-infested Dunning-Kruger-gone-wild fests like reddit, so I’ll leave that to others.
But I do want to clarify a couple things here, though, Andrew.
- Regardless of what that X is, it isn’t really going to be what makes this technology accessible to the masses. We would likely need the X to be in the thousands before we start to really take on players like Visa. Despite what people might have thought in 2009, it turns out Bitcoin is probably pretty ill-suited as a database in which to store the entire transaction history of the entire world. It’s looking to be more of a censorship-resistant dispute resolution mechanism that provides very well-defined settlement guarantees with the potential for encoding complex rules. It’s possible to build higher level tiers on top of it that DO support high volume transaction processing WITHOUT costing thousands of times more, and these approaches are looking quite promising. However, it doesn’t seem very many people in this space quite grasp this paradigm shift yet.
- What matters is not how a relatively small number of well-intentioned people in the network behave. What matters is how the network behaves as a whole
and a number of the people most intimately familiar with the inner workings of the system (some of whom are in this thread) think that given what we now today about the Bitcoin network, increasing block size externalizes costs in dangerous ways. Remember that total cost includes not just equipment costs but also things like block propagation latency and specifically identified security risks. Some of these security risks were only appreciated relatively recently and were completely unknown in 2009.

Secondly, there are a few well-identified problems with the protocol design that might be possible to fix that would perhaps allow us to remove the block size limit entirely without sacrificing security. I listed the ones that come to my mind at the beginning of this thread. I EMPHATICALLY state that in no way am I fundamentally opposed to raising or even getting rid of the block size limit. But I believe these problems should be addressed first. And it’s easier to address them and tackle them if we don’t have to worry about potential security risks and higher costs that come from insisting on bigger blocks right now.

- Eric

Post by Eric Lombrozo via bitcoin-dev

Post by Andrew LeCody via bitcoin-dev
tl;dr
$100 worth of hardware and $1/mo of expenses, should be able to run a full
Bitcoin node until 2020 with BIP101-size blocks.
----
I got into Bitcoin in the summer of 2010. I'm not a cryptographer, up until
recently my profession has been as a server administrator or systems
engineer.
I'd like to take a second to address the concern that larger blocks would
make it harder to run a full node on limited hardware and would therefore
hurt decentralization. I run two nodes today, one on server-grade hardware
at a datacenter and another on a mini-ITX Atom (dual core) system at my
home.
https://www.reddit.com/r/Bitcoin/comments/3f0h8e/mike_h_shuts_down_eric_ls_attempt_to_rewrite/ctkigpr
If I was a new user, wanting to run a full node. The most cost effective
way would likely be with a Raspberry Pi 2 and a 2TB external HDD. Total
cost about $100, including charger, microSD card, etc. That is less than
the cost of a TREZOR hardware wallet. As far as home projects go, not
terribly expensive.
Next, it will need power. According to the Wikipedia article, the rpi 2
model B uses 3.5 watts of power max. The 2TB external drive will draw about
5 watts at max. That's a total of 8.5 watts or 6.205 Kwh per month. In my
area (North Texas) power is about $0.10/Kwh, which means my little node
costs $0.62 per month in power.
Last, lets look at bandwidth. It's difficult to quantify bandwidth cost in
the same way because this is a home connection, mainly because I don't know
how to price in the loss of enjoyment if the system impacts my Internet
usage to a noticeable degree. Luckily, I have some real world data from my
http://imgur.com/YmJwQpN
This system averages 120 Kbps in and 544 Kbps out. Note, this data is
somewhat skewed, because the system is also used for seeding torrents of
various open source projects. The Bitcoin node itself is typically
connected to about 20 peers at any given time (maxconnections=20).
Subjectively, my wife and I have never noticed any degradation of
performance due to my home server using too much bandwidth. I think it's
safe to say that I can treat the bandwidth is uses as effectively free,
since it's piggybacking on a connection I would be paying for even if I was
not running a Bitcoin node. The bandwidth usage of this Bitcoin node could
increase significantly, without any noticeable impact. If it did, I could
always lower maxconnections back to 8.
The only real constraint seems to be hard drive space, as the full
blockchain and indexes take up about 50GB of space currently. If BIP101 is
implemented, 2TB of storage should be enough for me to continue running my
hypothetical $100 node until about 2020.
It seems to me that at least for the next 5 years, the "small devices" of
today can easily run Bitcoin nodes with BIP101-size blocks, with very
little operational cost.
If anyone would like more detailed data on my existing nodes, please let me
know and I'll attempt to provide it (so long as it doesn't impact my
privacy of course).
On Wed, Jul 29, 2015 at 10:49 PM Adam Back via bitcoin-dev <

Post by Adam Back via bitcoin-dev
I dont think people consider other blockchains as a competitive
threat. A PoW-blockchain is a largely singleton data structure for
security reasons (single highest hashrate), it is hard for an
alternative chain to bootstrap or provide meaningful security.
Secondly the world largely lacks expertise to maintain a blockchain to
bitcoin's security level, perhaps you can see a hint of this in the
recently disclosed security vulnerability by Pieter Wuille and Gregory
Maxwell. Calls to this as an argument are not resonating and probably
not helping your argument. Bitcoin has security properties, and a
competing system cant achieve better properties by bypassing security,
any blockchain faces the same fundamental security / decentralisation
limitations.
Secondly Bitcoin can obviously compete with itself with different
parameters and defacto *does* today. I think it is a safe estimate
that > 99% of Bitcoin transactions right now are happening in Bitcoin
related systems with various degrees of audit, reconciliation,
provable reserves etc. I think we can expect this to continue and
become more secure via more reconciliation, and longer term via
lightning or Bitcoin sidechains with different parameters. It is a
different story to have a single central system (Bitcoin with
parameters changed to the point of centralisation failure) vs having
multiple choices, because some transactions can more easily use
relatively centralised systems (eg micropayments), and more
interestingly the combination of a secure and decentralised layer 1
plus choices of less decentralised layer 2 options, can be interesting
because the layer 2 is provided cover from attack. There is less to
be gained by attacking relatively centralised layer 2 because any
payments at risk of policy abuse (which is typically a small subset)
can easily switch to layer 1. That in itself makes layer 2
transactions also less susceptible to policy abuse. Further lightning
it appears from work so far should add significant scale while
retaining trustlessness and a good degree of decentralisation.
Finally you seem to be focusing on "artificial" limits where that is
not the issue under consideration. The limits are technical and
relating to decentralisation and security. I wont go over them again
as this topic has been covered many times in recent months. Any chain
that tried to go to extreme parameters (very low block intervals, or
very large blocksizes) would have the same decentralisation problems
as Bitcoin would if it did the same thing. There are a number of alt
coins that have failed as a result of poor parameter choices, there
are inherent security limits.
Adam
ps Etiquette note for yourself and others: please dont be repetitive
or attempt to be forceful. Many people have spent many years
understanding this very complex system, from my own experience it is
rare indeed to think of an entirely new concept or analysis, that
hasnt' been long considered and put to bed 3 or 4 years ago.
Thoughtful polite and constructive comments are welcome but I
recommend to not start from an assumption that you have a clear and
better insight than the entire technical community, because I have to
say from my own experience that is very rarely the case. It can be
useful to test theories on #bitcoin IRC channel to find out what has
been already concluded, find the references and avoid having to have
that hashed out on this list which is trying to be focussed on
technical solutions.
On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev

Post by Raystonn . via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev
Cheapest way to send value? Is this what Bitcoin is trying to do? So
all of the smart contract, programmable money, consensus coding and
tremendous developer effort is bent to the consumer demand for cheaper
fees. Surely thou jests!

These other features can be replicated into any alternative blockchain,
including those with lower fees. In the open-source world of
cryptocurrency, no feature will remain a value-add for very long after it
has been identified to be such. Anything adding value will quickly be
absorbed into competing alternative blockchains. That will leave

economic

Post by Raystonn . via bitcoin-dev
policy as the distinguishing factor.

Post by Venzen Khaosan via bitcoin-dev
... it is not the case ... that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately, as a
means of protecting its degree of decentralization.

A slow or lack of increase to maximum transaction rate will cause

pressure

Post by Raystonn . via bitcoin-dev
on fees. Whether this is the desired goal is not relevant. Everyone has
agreed this will be the outcome. As to a smaller block size being needed
for additional decentralization, one must simply ask how much we are all
willing to pay for that additional decentralization. It is likely that

the

Post by Raystonn . via bitcoin-dev
benefit thereto will have to be demonstrated by some power attacking and
destroying a less decentralized currency before the benefit of this

feature

Post by Raystonn . via bitcoin-dev
is given monetary value by the market. Until then, value will bleed to

the

Post by Raystonn . via bitcoin-dev
network with the least friction, because it will have the greatest

ability

Post by Raystonn . via bitcoin-dev
to grow its network effect. That means the blockchain with adequate
features and cheapest fees will eventually have the largest market share.
-----Original Message----- From: Venzen Khaosan
Sent: Wednesday, July 29, 2015 3:11 PM
To: Raystonn .
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
isn'ttemporary
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Raystonn, I'm aware that you're addressing your question to Greg
[snip]

Post by Venzen Khaosan via bitcoin-dev
How do you plan to address the bleeding of value from Bitcoin to
alternative lower-fee blockchains created by the artificially-high
bitcoin transaction fees when users begin looking for the cheapest
way to send value?

Cheapest way to send value? Is this what Bitcoin is trying to do? So
all of the smart contract, programmable money, consensus coding and
tremendous developer effort is bent to the consumer demand for cheaper
fees. Surely thou jests!

Post by Venzen Khaosan via bitcoin-dev
Modern economic study has shown that liquidity moves to the
location of least friction.

Modern economic study? Can you please provide a link or reference to
the study you are referring to.
"liquidity moves to the location of least friction"
This sounds like "econo-speak" and makes no sense. The definition of
Liquidity is the degree to which an asset/security can be bought or
sold in the market without affecting the price.
That is why bitcoin is said to have low liquidity: buying or selling
only 100 BTC visibly affects the exchange price. You probably mean
"people like cheap fees", which is true, but as others have said,
because of Bitcoin's powerful features, they are willing to pay higher
fees and wait longer for transactions to execute.
As for your public cross-examination of Greg Maxwell, your case seems
to be made on the assumption that limiting the size of the blockchain
is an attempt to artificially raise tx fees, but it is not the case
(as you and others repeatedly argue) that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately, as a
means of protecting its degree of decentralization.
Surely, this is an obvious concern even for those who are campaigning
for the hare-brained ideal of making Bitcoin a "faster, cheaper
alternative" to visa or paypal? If we lose decentralization, we lose
the whole thing, right? Incorrect or correct?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB
RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp
h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz
Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS
YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx
BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=
=lQvy
-----END PGP SIGNATURE-----
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Gavin via bitcoin-dev]

Post by Eric Lombrozo via bitcoin-dev
and a number of the people most intimately familiar with the inner workings of the system (some of whom are in this thread) think that given what we now today about the Bitcoin network, increasing block size externalizes costs in dangerous ways. Remember that total cost includes not just equipment costs but also things like block propagation latency and specifically identified security risks. Some of these security risks were only appreciated relatively recently and were completely unknown in 2009.

I would like (and have been asking) those people to take the time to quantify those costs and write up those risks in a careful way.

I believe the costs and risks of 8MB blocks are minimal, and that the benefits of supporting more transaction FAR outweigh those costs and risks, but it is hard to have a rational conversation about that when even simple questions like 'what is s reasonable cost to run a full node' are met with silence.

[Pieter Wuille via bitcoin-dev]

On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev

Post by Eric Lombrozo via bitcoin-dev
and a number of the people most intimately familiar with the inner

workings of the system (some of whom are in this thread) think that given
what we now today about the Bitcoin network, increasing block size
externalizes costs in dangerous ways. Remember that total cost includes not
just equipment costs but also things like block propagation latency and
specifically identified security risks. Some of these security risks were
only appreciated relatively recently and were completely unknown in 2009.
I would like (and have been asking) those people to take the time to
quantify those costs and write up those risks in a careful way.
I believe the costs and risks of 8MB blocks are minimal, and that the
benefits of supporting more transaction FAR outweigh those costs and risks,
but it is hard to have a rational conversation about that when even simple
questions like 'what is s reasonable cost to run a full node' are met with
silence.

I think the benefit of an 8 MB over a 1 MB in terms of utility is marginal
(even assuming miners actually produce 8 MB blocks). There are very few use
cases that Bitcoin on-chain can support with a small extra factor. I think
the market will grow to adapt to whatever is offered anyway.

Bitcoin's advantage over other systems does not lie in scalability.
Well-designed centralized systems can trivially compete with Bitcoin's
on-chain transactions in terms of cost, speed, reliability, convenience,
and scale. Its power lies in transparency, lack of need for trust in
network peers, miners, and those who influence or control the system.
Wanting to increase the scale of the system is in conflict with all of
those. Attempting to buy time with a fast increase is not wanting to face
that reality, and treating the system as something whose scale trumps all
other concerns. A long term scalability plan should aim on decreasing the
need for trust required in off-chain systems, rather than increasing the
need for trust in Bitcoin.

Making controversial changes to the network, and not wanting to face the
reality that block chain space is a finite resource - whether enforced by a
consensus rule or by miner's capacity to process transactions - is a huge
treat to Bitcoin's usefulness in the long term.

I think the risks of trying to make a controversial change to the network
FAR outweighs the benefits of a small constant factor that "kicks the can
down the road".

Let's scale the block size gradually over time, according to technological
growth.

[Thomas Zander via bitcoin-dev]

Post by Pieter Wuille via bitcoin-dev

Post by Gavin via bitcoin-dev
I believe the costs and risks of 8MB blocks are minimal, and that the
benefits of supporting more transaction FAR outweigh those costs and risks,
but it is hard to have a rational conversation about that when even simple
questions like 'what is s reasonable cost to run a full node' are met with
silence.

I think the benefit of an 8 MB over a 1 MB in terms of utility is marginal

Like 640kb should be enough for everyone... Unfortunately the world doesn't
like things that can be bigger not getting bigger. ;)

Post by Pieter Wuille via bitcoin-dev
Bitcoin's advantage over other systems does not lie in scalability.
Well-designed centralized systems can trivially compete with Bitcoin's
on-chain transactions in terms of cost, speed, reliability, convenience,
and scale. Its power lies in transparency, lack of need for trust in
network peers, miners, and those who influence or control the system.

The real advantage of Bitcoin is simpler; its the first system that is not
owned and possible to subvert that actually works.
All existing attempts before Bitcoin are companies that try to benefit from
being in the middle, to the exclusion of everyone else and to the exclusion of
innovation.

Post by Pieter Wuille via bitcoin-dev
Wanting to increase the scale of the system is in conflict with all of
those.

Thats circular arguing. This didn't actually add anything to the
conversation.

The insight you skip over is that that Bitcoin's advantage, and the concept of
distributed computing in general, has is one of ownership and control.

If you want to keep Bitcoin small at 1Mb, do you still reach your goal of
being free from ownership and control? With our excellent growth trends;
transactions have to go somewhere, they will not use Bitcoin if we don't have
space. And that means we loose decentralization, we lose avoidance of
ownership of the network and we introduce control.

All your rhetoric is missing this basic point; is holding Bitcoin at 1Mb
advancing it, or hurting that basic goal of avoiding ownership?

[Gavin Andresen via bitcoin-dev]

Post by Pieter Wuille via bitcoin-dev
Let's scale the block size gradually over time, according to technological
growth.

Yes, lets do that-- that is EXACTLY what BIP101 intends to do.

With the added belt&suspenders reality check of miners, who won't produce
blocks too big for whatever technology they're using.

-------

So what do you think the scalability road map should look like? Should we
wait to hard fork until Blockstream Elements is ready for deploying on the
main network, and then have One Grand Hardfork that introduces all the
scalability work you guys have been working on (like Segregated Witness and
Lightning)?

Or is the plan to avoid controversy by people voluntarily moving their
bitcoin to a sidechain where all this scaling-up innovation happens?

No plan for how to scale up is the worst of all possible worlds, and the
lack of a direction or plan(s) is my main objection to the current status
quo.

And any plan that requires inventing brand-new technology is going to be
riskier than scaling up what we already have and understand, which is why I
think it is worthwhile to scale up what we have IN ADDITION TO working on
great projects like Segregated Witness and Lightning.

[Pieter Wuille via bitcoin-dev]

Post by Gavin Andresen via bitcoin-dev

Post by Pieter Wuille via bitcoin-dev
Let's scale the block size gradually over time, according to
technological growth.

Yes, lets do that-- that is EXACTLY what BIP101 intends to do.

Oh come on. Immediately increasing to 8 MB while miners currently don't
even seem to bother validating blocks?

With the added belt&suspenders reality check of miners, who won't produce

Post by Gavin Andresen via bitcoin-dev
blocks too big for whatever technology they're using.

Or a future where miners are even more centralized than now, which avoids
all problems relay and propagation speed has?

Post by Gavin Andresen via bitcoin-dev
So what do you think the scalability road map should look like? Should we
wait to hard fork until Blockstream Elements is ready for deploying on the
main network, and then have One Grand Hardfork that introduces all the
scalability work you guys have been working on (like Segregated Witness and
Lightning)?

Lightning does not require a hard fork, except that larger blocks would be
very useful for its bulk settlements.

Or is the plan to avoid controversy by people voluntarily moving their

Post by Gavin Andresen via bitcoin-dev
bitcoin to a sidechain where all this scaling-up innovation happens?

As I have said a dozen times now: sidechains are a mechanism for
experimentation. Maybe through them we will discover technology that allows
better on-chain and/or off-chain scalability, but people moving their coins
to a sidechain has far worse security tradeoffs than just increasing the
Bitcoin blockchain.

No plan for how to scale up is the worst of all possible worlds, and the

Post by Gavin Andresen via bitcoin-dev
lack of a direction or plan(s) is my main objection to the current status
quo.

Ok, here is a proposal I was working on. I'd like to have had more time,
but I agree a direction/plan are needed to align expectations for the
future: https://gist.github.com/sipa/c65665fc360ca7a176a6.

Post by Gavin Andresen via bitcoin-dev
And any plan that requires inventing brand-new technology is going to be
riskier than scaling up what we already have and understand, which is why I
think it is worthwhile to scale up what we have IN ADDITION TO working on
great projects like Segregated Witness and Lightning.

And I think that the reason that so many people care about this suddenly is
because of a fear that somehow the current block size "won't be enough".
Bitcoin has utility at any block size, and perhaps more at some values for
it than others. Talking about "not enough" is acknowledging that we really
believe the block size should scale to demand, while it is the other way
around.

[Jorge Timón via bitcoin-dev]

On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen via bitcoin-dev

Post by Gavin Andresen via bitcoin-dev
So what do you think the scalability road map should look like? Should we
wait to hard fork until Blockstream Elements is ready for deploying on the
main network, and then have One Grand Hardfork that introduces all the
scalability work you guys have been working on (like Segregated Witness and
Lightning)?

Apparently lightning doesn't require Segregated Witnesses: cltv and
rcltv may be enough (although I'm not up to date to the latest
designs). I definitely don't think we should wait to have SW ready to
be deployable in Bitcoin to have other hardforks. I think we should
have an uncontroversial hardfork as soon as possible, if anything, to
set a precedent and show the world that hardforks are possible in
Bitcoin, see https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#code

Post by Gavin Andresen via bitcoin-dev
Or is the plan to avoid controversy by people voluntarily moving their
bitcoin to a sidechain where all this scaling-up innovation happens?

Any scaling up innovation that happens in sidechains can be adopted by
Bitcoin too.
In fact, some of those changes (like op_maturity/rcltv/scv) are needed
in Bitcoin for a fully p2p Bitcoin sidechain to be even possible.
I really think lightning should be possible in Bitcoin main (and not
just sidechains) as soon as possible.

Post by Gavin Andresen via bitcoin-dev
And any plan that requires inventing brand-new technology is going to be
riskier than scaling up what we already have and understand, which is why I
think it is worthwhile to scale up what we have IN ADDITION TO working on
great projects like Segregated Witness and Lightning.

Not necessarily. How are older payment channels designs (different
from lightning) that don't even require cltv riskier than a hardfork?
In any case, yes, both things are kind of orthogonal and we can work
on both (and more) at the same time.

[Eric Lombrozo via bitcoin-dev]

Post by Gavin via bitcoin-dev
it is hard to have a rational conversation about that when even simple questions like 'what is s reasonable cost to run a full node' are met with silence.

Some of the risks are pretty hard to quantify. But I think this misses the bigger point - it very well *might* be possible to safely raise this limit or even get rid of it by first fixing some serious issues with the protocol. But over six years into the project and these issues continue to be all-but-ignored by most of the community (including at least a few core developers). I don’t think it’s really a matter of whether we agree on whether it’s good to raise the block size limit, Gavin. I think it’s a matter of a difference in priorities.

- Eric

[Milly Bitcoin via bitcoin-dev]

These are the types of things I have been discussing in relation to a
process:

-A list of metrics
-A Risk analysis of the baseline system. Bitcoin as it is now.
-Mitigation strategies for each risk.
-A set of goals.
-A Road map for each goal that lists the changes or possible avenues to
achieve that goal.

Proposed changes would be measured against the same metrics and a risk
analysis done so it can be compared with the baseline.

For example, the block size debate would be discussed in the context of
a road map related to a goal of increase scaling. One of the metrics
would be a decentralization metric. (A framework for a decentralization
metric is at
http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf).
Cost would be one aspect of the decentralization metric.

Russ

Post by Eric Lombrozo via bitcoin-dev

Post by Gavin via bitcoin-dev
it is hard to have a rational conversation about that when even simple
questions like 'what is s reasonable cost to run a full node' are met
with silence.

Some of the risks are pretty hard to quantify. But I think this misses
the bigger point - it very well *might* be possible to safely raise this
limit or even get rid of it by first fixing some serious issues with the
protocol. But over six years into the project and these issues continue
to be all-but-ignored by most of the community (including at least a few
core developers). I don’t think it’s really a matter of whether we agree
on whether it’s good to raise the block size limit, Gavin. I think it’s
a matter of a difference in priorities.
- Eric
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Jorge Timón via bitcoin-dev]

On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev

Post by Milly Bitcoin via bitcoin-dev
These are the types of things I have been discussing in relation to a
-A list of metrics
-A Risk analysis of the baseline system. Bitcoin as it is now.
-Mitigation strategies for each risk.
-A set of goals.
-A Road map for each goal that lists the changes or possible avenues to
achieve that goal.
Proposed changes would be measured against the same metrics and a risk
analysis done so it can be compared with the baseline.
For example, the block size debate would be discussed in the context of a
road map related to a goal of increase scaling. One of the metrics would be
a decentralization metric. (A framework for a decentralization metric is at
http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf).
Cost would be one aspect of the decentralization metric.

All this sounds very reasonable and useful.
And if a formal organization owns this "process", that's fine as well.
I still think hardforks need to be uncontroversial (using the vague "I
will know it when I see it" defintion) and no individual or
organization can be an "ultimate decider" or otherwise Bitcoin losses
all it's p2p nature (and this seems the point where you, Milly, and I
disagree).
But metrics and data tend to help when it comes to "I will know it
when I see it" and "evidences".
So, yes, by all means, let's have an imperfect decentralization metric
rather than not having anything to compare proposals. Competing
decentralization metrics can appear later: we need a first one first.
I would add that we should have sets of simulations being used to
calculate some of those metrics, but maybe I'm just going too deep
into details.

[Eric Lombrozo via bitcoin-dev]

I generally agree with this as well. I think it is crucial we avoid
controversial hardforks. The risks greatly outweigh the benefits.

This is a good start to making it less controversial.

- Eric
On Jul 31, 2015 2:31 PM, "Jorge Timón" <

Post by Jorge Timón via bitcoin-dev
On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev

Post by Milly Bitcoin via bitcoin-dev
These are the types of things I have been discussing in relation to a
-A list of metrics
-A Risk analysis of the baseline system. Bitcoin as it is now.
-Mitigation strategies for each risk.
-A set of goals.
-A Road map for each goal that lists the changes or possible avenues to
achieve that goal.
Proposed changes would be measured against the same metrics and a risk
analysis done so it can be compared with the baseline.
For example, the block size debate would be discussed in the context of a
road map related to a goal of increase scaling. One of the metrics

would be

Post by Milly Bitcoin via bitcoin-dev
a decentralization metric. (A framework for a decentralization metric

is at
http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf
).

Post by Milly Bitcoin via bitcoin-dev
Cost would be one aspect of the decentralization metric.

All this sounds very reasonable and useful.
And if a formal organization owns this "process", that's fine as well.
I still think hardforks need to be uncontroversial (using the vague "I
will know it when I see it" defintion) and no individual or
organization can be an "ultimate decider" or otherwise Bitcoin losses
all it's p2p nature (and this seems the point where you, Milly, and I
disagree).
But metrics and data tend to help when it comes to "I will know it
when I see it" and "evidences".
So, yes, by all means, let's have an imperfect decentralization metric
rather than not having anything to compare proposals. Competing
decentralization metrics can appear later: we need a first one first.
I would add that we should have sets of simulations being used to
calculate some of those metrics, but maybe I'm just going too deep
into details.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Thomas Zander via bitcoin-dev]

I don’t think it’s really a matter of whether we agree on whether it’s good
to raise the block size limit, Gavin. I think it’s a matter of a difference
in priorities.

Having different priorities is fine, using your time to block peoples attempts
to increase block size is not showing different priorities, it shows conflicting
priorities.
Different priorities means you can trust someone else to do things they care
about while you do things you care about.

[Eric Lombrozo via bitcoin-dev]

I would love to be able to increase block size. But I have serious doubts
about being able to do this safely at this time given what we presently
know about the Bitcoin network. And I'm pretty sure I'm not alone in this
sentiment.

Had we been working on fixing the known issues that most complicate bigger
blocks in the last six years, or even in the last three years after many
issues had already been well-identified, perhaps we'd be ready to increase
the limit. But other things have seemed more important, like specifying the
use of X.509 overlay protocols or adding complex filtering mechanisms to
the p2p protocol to make it practical to use tx merkle trees...and as a
result we're not ready for safely allowing larger blocks.

- Eric
On Jul 30, 2015 11:43 PM, "Thomas Zander via bitcoin-dev" <

Post by Mike Hearn via bitcoin-dev

Post by Eric Lombrozo via bitcoin-dev
I don’t think it’s really a matter of whether we agree on whether it’s

good

Post by Eric Lombrozo via bitcoin-dev
to raise the block size limit, Gavin. I think it’s a matter of a

difference

Post by Eric Lombrozo via bitcoin-dev
in priorities.

Having different priorities is fine, using your time to block peoples attempts
to increase block size is not showing different priorities, it shows conflicting
priorities.
Different priorities means you can trust someone else to do things they care
about while you do things you care about.
--
Thomas Zander
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Eric Lombrozo via bitcoin-dev]

Having said that, I must admit that the complex filtering mechanisms are
pretty clever...they almost make it practical to use SPV...now if only we
were committint to structures that can prove the validity of returned
datasets and miners actually validated stuff, it might also offer some
level of security.

Post by Eric Lombrozo via bitcoin-dev
I would love to be able to increase block size. But I have serious doubts
about being able to do this safely at this time given what we presently
know about the Bitcoin network. And I'm pretty sure I'm not alone in this
sentiment.
Had we been working on fixing the known issues that most complicate bigger
blocks in the last six years, or even in the last three years after many
issues had already been well-identified, perhaps we'd be ready to increase
the limit. But other things have seemed more important, like specifying the
use of X.509 overlay protocols or adding complex filtering mechanisms to
the p2p protocol to make it practical to use tx merkle trees...and as a
result we're not ready for safely allowing larger blocks.
- Eric
On Jul 30, 2015 11:43 PM, "Thomas Zander via bitcoin-dev" <

Post by Mike Hearn via bitcoin-dev

Post by Eric Lombrozo via bitcoin-dev
I don’t think it’s really a matter of whether we agree on whether it’s

good

Post by Eric Lombrozo via bitcoin-dev
to raise the block size limit, Gavin. I think it’s a matter of a

difference

Post by Eric Lombrozo via bitcoin-dev
in priorities.

Having different priorities is fine, using your time to block peoples attempts
to increase block size is not showing different priorities, it shows conflicting
priorities.
Different priorities means you can trust someone else to do things they care
about while you do things you care about.
--
Thomas Zander
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[John T. Winslow via bitcoin-dev]

Regarding the block size increase, at least conceptually it seems to me
there should be an easy solution. If we look at what works well with
bitcoin, for example the block reward halving and difficulty regimes
which due to their step function nature both contribute to the stability
and predictability of the bitcoin universe while still allowing for the
necessary dynamic adjustments. It seems to me there should be a
corresponding and equally simple solution for the maximum block size.

I've never quite understood the supposed rationale behind the proposals
for a new static maximum of 20 MB or 8 MB or 2 MB other than it would be
trivial to implement. Why not come up with an equally simple,
predictable dynamic function consistent with what is already proven to
work in the bitcoin universe that would both preserve the scarcity of
transaction capacity to encourage a fee market but also allow for more
transactions when needed.

For example how about something like once every month at month-end, take
the 6-month average non-zero transaction fee block size and multiply by 1.5?

With the # of transactions increasing then plateauing you arrive at a
constant excess capacity of around 33%:

MO ABS MBS EX CAP
1 750 1000 25.0%
2 775 1000 22.5%
3 800 1000 20.0%
4 825 1000 17.5%
5 850 1000 15.0%
6 875 1219 28.2%
7 900 1256 28.4%
8 925 1294 28.5%
9 950 1331 28.6%
10 975 1369 28.8%
11 1000 1406 28.9%
12 1000 1438 30.4%
13 1000 1463 31.6%
14 1000 1481 32.5%
15 1000 1494 33.1%
16 1000 1500 33.3%
17 1000 1500 33.3%
18 1000 1500 33.3%

Similarly, in a declining then plateauing # of transactions market you
also arrive at a constant excess capacity of about 33%

MO ABS MBS EX CAP
1 750 1000 25.0%
2 725 1000 27.5%
3 700 1000 30.0%
4 675 1000 32.5%
5 650 1000 35.0%
6 625 1031 39.4%
7 600 994 39.6%
8 575 956 39.9%
9 550 919 40.1%
10 525 881 40.4%
11 500 844 40.7%
12 500 813 38.5%
13 500 788 36.5%
14 500 769 35.0%
15 500 756 33.9%
16 500 750 33.3%
17 500 750 33.3%
18 500 750 33.3%

With some simple statistical analysis, one could easily arrive at a
statistically-inferred excess capacity linked the to probability of
transaction volume exceeding the new cap in any forward monthly
interval. In the tables above, I have used my own intuition that people
seem to be generally comfortable with excess capacity of >= 33% and
become less so at < 33%.

A scheme like this would have multiple benefits:

1) Adapts predictably and automatically to both rising and declining
market demand for transactions

2) Preserves the fee market with a constant target excess capacity

3) Monthly adjustment interval and six month lookback allow for
sufficient time to plan for changes in system capacity

In the case where transaction volume spikes such that it exceeds the
monthly limit, the fee market would then take over to ensure high
priority transactions get through fastest. In the case of malicious
activity, such an attack would have to be maintained for well over a
month to significantly adversely affect the maximum block size. As long
as there is a non-zero cost to such attacks, the likelihood of
maintaining one for a period of months decreases significantly.

Thx,

JTW

Post by Eric Lombrozo via bitcoin-dev
I would love to be able to increase block size. But I have serious
doubts about being able to do this safely at this time given what we
presently know about the Bitcoin network. And I'm pretty sure I'm not
alone in this sentiment.
Had we been working on fixing the known issues that most complicate
bigger blocks in the last six years, or even in the last three years
after many issues had already been well-identified, perhaps we'd be
ready to increase the limit. But other things have seemed more
important, like specifying the use of X.509 overlay protocols or
adding complex filtering mechanisms to the p2p protocol to make it
practical to use tx merkle trees...and as a result we're not ready for
safely allowing larger blocks.
- Eric
On Jul 30, 2015 11:43 PM, "Thomas Zander via bitcoin-dev"
On Thursday 30. July 2015 16.33.16 <tel:2015%2016.33.16> Eric

I don’t think it’s really a matter of whether we agree on

whether it’s good

to raise the block size limit, Gavin. I think it’s a matter of a

difference

in priorities.

Having different priorities is fine, using your time to block peoples attempts
to increase block size is not showing different priorities, it shows conflicting
priorities.
Different priorities means you can trust someone else to do things they care
about while you do things you care about.
--
Thomas Zander
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Pieter Wuille via bitcoin-dev]

On Sat, Aug 1, 2015 at 10:22 PM, John T. Winslow via bitcoin-dev <

Post by John T. Winslow via bitcoin-dev
Regarding the block size increase, at least conceptually it seems to me
there should be an easy solution. If we look at what works well with
bitcoin, for example the block reward halving and difficulty regimes which
due to their step function nature both contribute to the stability and
predictability of the bitcoin universe while still allowing for the
necessary dynamic adjustments. It seems to me there should be a
corresponding and equally simple solution for the maximum block size.
I've never quite understood the supposed rationale behind the proposals
for a new static maximum of 20 MB or 8 MB or 2 MB other than it would be
trivial to implement. Why not come up with an equally simple, predictable
dynamic function consistent with what is already proven to work in the
bitcoin universe that would both preserve the scarcity of transaction
capacity to encourage a fee market but also allow for more transactions
when needed.

I disagree with the notion of "needed". The blockchain provides utility at
every size, and perhaps more at some sizes than at other sizes, but any
finite size will permit some use cases and not others. This is already the
case and will remain the case. I think the "demand for payments" should be
considered infinite, and some of them will fit on a block chain and pay a
fee for it, and others will need to rely on more efficient, cheaper, but
higher trust systems. You can't use observed usage as a metric for demand
without fixing the cost.

I think available space should grow with technology, to keep the relative
costs to the ecosystem for maintaining a decentralized system constant.
That may or may not lead to a fee market, but I don't think the fee market
is a goal - only a healthy outcome. The goal is an ecosystem that accepts
that the limit to scalability is set by the requirements of a decentralized
system, and its demand - and certainly not perceived demand at potentially
near-zero fee/cost - can't change that.

Post by John T. Winslow via bitcoin-dev
For example how about something like once every month at month-end, take
the 6-month average non-zero transaction fee block size and multiply by 1.5?

That's trivially gamable by miners, by filling the blocks with their own
transactions.

[Venzen Khaosan via bitcoin-dev]

Adam,

- From your explanation it is evident that fast, cheap bitcoin
transactions are possible. It is encouraging that Bitcoin _can_ indeed
compete with Visa, Paypal, et al. via Layer 2 protocols such as Lightning.

The youtube interview with you and Greg re: Lightning requires some
concentration and I'll have to watch it another couple of times to
better grasp everything that is explained about the protocol and its
interaction with Bitcoin.

Thank you for your considered and informative response, else Raystonn
and I might have gotten in an unnecessary scrap about fees, economics
and what not.

regards,
Venzen Khaosan

Post by Adam Back via bitcoin-dev
I dont think people consider other blockchains as a competitive
threat. A PoW-blockchain is a largely singleton data structure
for security reasons (single highest hashrate), it is hard for an
alternative chain to bootstrap or provide meaningful security.
Secondly the world largely lacks expertise to maintain a blockchain
to bitcoin's security level, perhaps you can see a hint of this in
the recently disclosed security vulnerability by Pieter Wuille and
Gregory Maxwell. Calls to this as an argument are not resonating
and probably not helping your argument. Bitcoin has security
properties, and a competing system cant achieve better properties
by bypassing security, any blockchain faces the same fundamental
security / decentralisation limitations.
Secondly Bitcoin can obviously compete with itself with different
parameters and defacto *does* today. I think it is a safe
estimate that > 99% of Bitcoin transactions right now are happening
in Bitcoin related systems with various degrees of audit,
reconciliation, provable reserves etc. I think we can expect this
to continue and become more secure via more reconciliation, and
longer term via lightning or Bitcoin sidechains with different
parameters. It is a different story to have a single central
system (Bitcoin with parameters changed to the point of
centralisation failure) vs having multiple choices, because some
transactions can more easily use relatively centralised systems (eg
micropayments), and more interestingly the combination of a secure
and decentralised layer 1 plus choices of less decentralised layer
2 options, can be interesting because the layer 2 is provided cover
from attack. There is less to be gained by attacking relatively
centralised layer 2 because any payments at risk of policy abuse
(which is typically a small subset) can easily switch to layer 1.
That in itself makes layer 2 transactions also less susceptible to
policy abuse. Further lightning it appears from work so far should
add significant scale while retaining trustlessness and a good
degree of decentralisation.
Finally you seem to be focusing on "artificial" limits where that
is not the issue under consideration. The limits are technical
and relating to decentralisation and security. I wont go over them
again as this topic has been covered many times in recent months.
Any chain that tried to go to extreme parameters (very low block
intervals, or very large blocksizes) would have the same
decentralisation problems as Bitcoin would if it did the same
thing. There are a number of alt coins that have failed as a
result of poor parameter choices, there are inherent security
limits.
Adam
ps Etiquette note for yourself and others: please dont be
repetitive or attempt to be forceful. Many people have spent many
years understanding this very complex system, from my own
experience it is rare indeed to think of an entirely new concept or
analysis, that hasnt' been long considered and put to bed 3 or 4
years ago. Thoughtful polite and constructive comments are welcome
but I recommend to not start from an assumption that you have a
clear and better insight than the entire technical community,
because I have to say from my own experience that is very rarely
the case. It can be useful to test theories on #bitcoin IRC
channel to find out what has been already concluded, find the
references and avoid having to have that hashed out on this list
which is trying to be focussed on technical solutions.
On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev

Post by Raystonn . via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev
Cheapest way to send value? Is this what Bitcoin is trying to
do? So all of the smart contract, programmable money, consensus
coding and tremendous developer effort is bent to the consumer
demand for cheaper fees. Surely thou jests!

These other features can be replicated into any alternative
blockchain, including those with lower fees. In the open-source
world of cryptocurrency, no feature will remain a value-add for
very long after it has been identified to be such. Anything
adding value will quickly be absorbed into competing alternative
blockchains. That will leave economic policy as the
distinguishing factor.

Post by Venzen Khaosan via bitcoin-dev
... it is not the case ... that reluctance to concede blocksize
is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately,
as a means of protecting its degree of decentralization.

A slow or lack of increase to maximum transaction rate will cause
pressure on fees. Whether this is the desired goal is not
relevant. Everyone has agreed this will be the outcome. As to a
smaller block size being needed for additional decentralization,
one must simply ask how much we are all willing to pay for that
additional decentralization. It is likely that the benefit
thereto will have to be demonstrated by some power attacking and
destroying a less decentralized currency before the benefit of
this feature is given monetary value by the market. Until then,
value will bleed to the network with the least friction, because
it will have the greatest ability to grow its network effect.
That means the blockchain with adequate features and cheapest
fees will eventually have the largest market share.
-----Original Message----- From: Venzen Khaosan Sent: Wednesday,
Why Satoshi's temporary anti-spam measure isn'ttemporary

Raystonn, I'm aware that you're addressing your question to Greg
Maxwell, however a point you keep stating as fact calls for
On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote: [snip]

Post by Raystonn . via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev

How do you plan to address the bleeding of value from Bitcoin
to alternative lower-fee blockchains created by the
artificially-high bitcoin transaction fees when users begin
looking for the cheapest way to send value?

Cheapest way to send value? Is this what Bitcoin is trying to do?
So all of the smart contract, programmable money, consensus coding
and tremendous developer effort is bent to the consumer demand for
cheaper fees. Surely thou jests!

Post by Raystonn . via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev

Modern economic study has shown that liquidity moves to the
location of least friction.

Modern economic study? Can you please provide a link or reference
to the study you are referring to.
"liquidity moves to the location of least friction"
This sounds like "econo-speak" and makes no sense. The definition
of Liquidity is the degree to which an asset/security can be bought
or sold in the market without affecting the price.
That is why bitcoin is said to have low liquidity: buying or
selling only 100 BTC visibly affects the exchange price. You
probably mean "people like cheap fees", which is true, but as
others have said, because of Bitcoin's powerful features, they are
willing to pay higher fees and wait longer for transactions to
execute.
As for your public cross-examination of Greg Maxwell, your case
seems to be made on the assumption that limiting the size of the
blockchain is an attempt to artificially raise tx fees, but it is
not the case (as you and others repeatedly argue) that reluctance
to concede blocksize is an attempt to constrain capacity. Greg
Maxwell thoroughly explained in this thread that the protocol's
current state of development relies on blocksize for security and,
ultimately, as a means of protecting its degree of
decentralization.
Surely, this is an obvious concern even for those who are
campaigning for the hare-brained ideal of making Bitcoin a "faster,
cheaper alternative" to visa or paypal? If we lose
decentralization, we lose the whole thing, right? Incorrect or
correct?

Post by Raystonn . via bitcoin-dev
_______________________________________________ bitcoin-dev
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Jorge Timón via bitcoin-dev]

It is important ro note that even if lightning was never developed, the
block size remains at 1 MB forever and fees rise to 10 usd per transaction,
such "high fees" are still extremely competitive with non-decentralized
payment systems that have proportional fees. For example, 10 usd is still
lower than 1% when you are moving more than 1000 usd. I know, this doesn't
work for micro-transactions, but I don't think Bitcoin can be useful for
micro-transactions in the long term unless something like lightning payment
channels is deployed. Until we accept the second fact, it will be very hard
to discuss any projection of future usage. I think that believing that all
the transactions of the entire world population can be made in-chain while
keeping bitcoin decentralized is incredibly naive. Not even nasdaq has that
capacity (and if full node's require nasdaq's capacity, I don't think we
can talk about a decentralized system anymore).
On Jul 30, 2015 11:16 AM, "Venzen Khaosan via bitcoin-dev" <

Post by Raystonn . via bitcoin-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Adam,
- From your explanation it is evident that fast, cheap bitcoin
transactions are possible. It is encouraging that Bitcoin _can_ indeed
compete with Visa, Paypal, et al. via Layer 2 protocols such as Lightning.
The youtube interview with you and Greg re: Lightning requires some
concentration and I'll have to watch it another couple of times to
better grasp everything that is explained about the protocol and its
interaction with Bitcoin.
Thank you for your considered and informative response, else Raystonn
and I might have gotten in an unnecessary scrap about fees, economics
and what not.
regards,
Venzen Khaosan

Post by Adam Back via bitcoin-dev
I dont think people consider other blockchains as a competitive
threat. A PoW-blockchain is a largely singleton data structure
for security reasons (single highest hashrate), it is hard for an
alternative chain to bootstrap or provide meaningful security.
Secondly the world largely lacks expertise to maintain a blockchain
to bitcoin's security level, perhaps you can see a hint of this in
the recently disclosed security vulnerability by Pieter Wuille and
Gregory Maxwell. Calls to this as an argument are not resonating
and probably not helping your argument. Bitcoin has security
properties, and a competing system cant achieve better properties
by bypassing security, any blockchain faces the same fundamental
security / decentralisation limitations.
Secondly Bitcoin can obviously compete with itself with different
parameters and defacto *does* today. I think it is a safe
estimate that > 99% of Bitcoin transactions right now are happening
in Bitcoin related systems with various degrees of audit,
reconciliation, provable reserves etc. I think we can expect this
to continue and become more secure via more reconciliation, and
longer term via lightning or Bitcoin sidechains with different
parameters. It is a different story to have a single central
system (Bitcoin with parameters changed to the point of
centralisation failure) vs having multiple choices, because some
transactions can more easily use relatively centralised systems (eg
micropayments), and more interestingly the combination of a secure
and decentralised layer 1 plus choices of less decentralised layer
2 options, can be interesting because the layer 2 is provided cover
from attack. There is less to be gained by attacking relatively
centralised layer 2 because any payments at risk of policy abuse
(which is typically a small subset) can easily switch to layer 1.
That in itself makes layer 2 transactions also less susceptible to
policy abuse. Further lightning it appears from work so far should
add significant scale while retaining trustlessness and a good
degree of decentralisation.
Finally you seem to be focusing on "artificial" limits where that
is not the issue under consideration. The limits are technical
and relating to decentralisation and security. I wont go over them
again as this topic has been covered many times in recent months.
Any chain that tried to go to extreme parameters (very low block
intervals, or very large blocksizes) would have the same
decentralisation problems as Bitcoin would if it did the same
thing. There are a number of alt coins that have failed as a
result of poor parameter choices, there are inherent security
limits.
Adam
ps Etiquette note for yourself and others: please dont be
repetitive or attempt to be forceful. Many people have spent many
years understanding this very complex system, from my own
experience it is rare indeed to think of an entirely new concept or
analysis, that hasnt' been long considered and put to bed 3 or 4
years ago. Thoughtful polite and constructive comments are welcome
but I recommend to not start from an assumption that you have a
clear and better insight than the entire technical community,
because I have to say from my own experience that is very rarely
the case. It can be useful to test theories on #bitcoin IRC
channel to find out what has been already concluded, find the
references and avoid having to have that hashed out on this list
which is trying to be focussed on technical solutions.
On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev

Post by Raystonn . via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev
Cheapest way to send value? Is this what Bitcoin is trying to
do? So all of the smart contract, programmable money, consensus
coding and tremendous developer effort is bent to the consumer
demand for cheaper fees. Surely thou jests!

These other features can be replicated into any alternative
blockchain, including those with lower fees. In the open-source
world of cryptocurrency, no feature will remain a value-add for
very long after it has been identified to be such. Anything
adding value will quickly be absorbed into competing alternative
blockchains. That will leave economic policy as the
distinguishing factor.

Post by Venzen Khaosan via bitcoin-dev
... it is not the case ... that reluctance to concede blocksize
is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately,
as a means of protecting its degree of decentralization.

A slow or lack of increase to maximum transaction rate will cause
pressure on fees. Whether this is the desired goal is not
relevant. Everyone has agreed this will be the outcome. As to a
smaller block size being needed for additional decentralization,
one must simply ask how much we are all willing to pay for that
additional decentralization. It is likely that the benefit
thereto will have to be demonstrated by some power attacking and
destroying a less decentralized currency before the benefit of
this feature is given monetary value by the market. Until then,
value will bleed to the network with the least friction, because
it will have the greatest ability to grow its network effect.
That means the blockchain with adequate features and cheapest
fees will eventually have the largest market share.
-----Original Message----- From: Venzen Khaosan Sent: Wednesday,
Why Satoshi's temporary anti-spam measure isn'ttemporary

Raystonn, I'm aware that you're addressing your question to Greg
Maxwell, however a point you keep stating as fact calls for
On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote: [snip]

Post by Raystonn . via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev

How do you plan to address the bleeding of value from Bitcoin
to alternative lower-fee blockchains created by the
artificially-high bitcoin transaction fees when users begin
looking for the cheapest way to send value?

Cheapest way to send value? Is this what Bitcoin is trying to do?
So all of the smart contract, programmable money, consensus coding
and tremendous developer effort is bent to the consumer demand for
cheaper fees. Surely thou jests!

Post by Raystonn . via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev

Modern economic study has shown that liquidity moves to the
location of least friction.

Modern economic study? Can you please provide a link or reference
to the study you are referring to.
"liquidity moves to the location of least friction"
This sounds like "econo-speak" and makes no sense. The definition
of Liquidity is the degree to which an asset/security can be bought
or sold in the market without affecting the price.
That is why bitcoin is said to have low liquidity: buying or
selling only 100 BTC visibly affects the exchange price. You
probably mean "people like cheap fees", which is true, but as
others have said, because of Bitcoin's powerful features, they are
willing to pay higher fees and wait longer for transactions to
execute.
As for your public cross-examination of Greg Maxwell, your case
seems to be made on the assumption that limiting the size of the
blockchain is an attempt to artificially raise tx fees, but it is
not the case (as you and others repeatedly argue) that reluctance
to concede blocksize is an attempt to constrain capacity. Greg
Maxwell thoroughly explained in this thread that the protocol's
current state of development relies on blocksize for security and,
ultimately, as a means of protecting its degree of
decentralization.
Surely, this is an obvious concern even for those who are
campaigning for the hare-brained ideal of making Bitcoin a "faster,
cheaper alternative" to visa or paypal? If we lose
decentralization, we lose the whole thing, right? Incorrect or
correct?

Post by Raystonn . via bitcoin-dev
_______________________________________________ bitcoin-dev
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVuetlAAoJEGwAhlQc8H1m2TkH/jKx7V9vCZbOjbxAlfjnR0ai
+QDxMm0K0sL/MlsLVm0FAHwGiKhYJnEeXiZJlXu0eiUz35JALDMtSQiVbQzcHAc2
GvyW3tWUh6+uSfYhsnImQXxlDgCUKIgZvtTM900OWcGXZeLU3W5UdUK5+ietHK0/
1HbZgcljqke+nSsH2aCagd/iNdwCIUcfapsUgB6iPWtZQfLg6SHi8CjbG/Th5Na7
fpA5yJlO4N+Q2JpOVId/LfC7loDCEZtPtYA5NZAsDcEcSIXUycCoGL8LNMIFGJNe
Ko2RNqGeIkb/x8T2USxlkrNUZx/CCF201MMClPLC/LXX1bEMDvO8F0m1TBR1ptg=
=106o
-----END PGP SIGNATURE-----
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Venzen Khaosan via bitcoin-dev]

Jorge,

You know, it is always insightful to get the perspective of active
participants and Core developers like yourself. As Adam pointed out
earlier, the developers have done mileage in this space and have
already considered most of the conceptual issues and technical
challenges that must resurface in waves as new interested parties join
the list. Allow me, in this response to your message, to make a
proposal to those who may be interested:


Bitcoin's protocol functions and the implications of this innovation
for the future are difficult to grasp, even for the smartest among us.
Then there are also the words of Niels Bohr:

"Prediction is difficult, especially about the future."

They say a lot of time and energy is wasted because we don't know what
we don't know. Years of discussion among those in the list has
established certain axioms that determine the options for Bitcoin
going forward. According to my comprehension, the following are some
of the most relevant for the present discussion (please correct me
where I'm off the mark):

1. A high degree of decentralization is prima optima.

2. Bitcoin is much more than a payment network. A lot of the
non-payment features are, arguably, what gives Bitcoin most of its
value. Yet, the payment functionality is a major design feature and
all agree that it should scale - subject to axiom 1.

3. The Bitcoin payment network ("Layer 1"), due to technical
constraints imposed by its p2p design, cannot compete with Visa and
other centralized transmission channels for speed or transaction
volume. Nor can it handle the transaction requirements of the world's
population - the scaling required would necessarily render Bitcoin
centralized, insecure and, therefore, worthless.

4. The addition of "layer 2" protocols (such as Lightning and other
sidechains) will allow fast, low-fee (and with virtually instant
confirmation) bitcoin transactions within two years, according to the
developers active in that:

5. This "layering of protocols" simplifies the scaling (blocksize)
debate because it separates
A) the primary concern for security and fidelity via
decentralization, and
B) the ideal of universal accessibility via fast, low-fee transactions.
Discussion about scalability can therefore proceed with the knowledge
that Lightning and other "layer 2" sidechains will make Bitcoin
accessible to the global majority - and be fast like Bruce Lee - while
the Bitcoin developers can focus on making Bitcoin Core protocol
(layer 1) the world heavyweight champion - Muhammad Ali.

Since I've maintained your interest up to the final sentence, I say:
as an insurance against a capacity crisis before layer 2 is deployed,
why not implement bip100's 2MB blocksize proposals in a testnet?

Post by Jorge Timón via bitcoin-dev
It is important ro note that even if lightning was never developed,
the block size remains at 1 MB forever and fees rise to 10 usd per
transaction, such "high fees" are still extremely competitive with
non-decentralized payment systems that have proportional fees. For
example, 10 usd is still lower than 1% when you are moving more
than 1000 usd. I know, this doesn't work for micro-transactions,
but I don't think Bitcoin can be useful for micro-transactions in
the long term unless something like lightning payment channels is
deployed. Until we accept the second fact, it will be very hard to
discuss any projection of future usage. I think that believing that
all the transactions of the entire world population can be made
in-chain while keeping bitcoin decentralized is incredibly naive.
Not even nasdaq has that capacity (and if full node's require
nasdaq's capacity, I don't think we can talk about a decentralized
system anymore).
On Jul 30, 2015 11:16 AM, "Venzen Khaosan via bitcoin-dev"
Adam,
- From your explanation it is evident that fast, cheap bitcoin
transactions are possible. It is encouraging that Bitcoin _can_
indeed compete with Visa, Paypal, et al. via Layer 2 protocols such
as Lightning.
The youtube interview with you and Greg re: Lightning requires
some concentration and I'll have to watch it another couple of
times to better grasp everything that is explained about the
protocol and its interaction with Bitcoin.
Thank you for your considered and informative response, else
Raystonn and I might have gotten in an unnecessary scrap about
fees, economics and what not.
regards, Venzen Khaosan

Post by Adam Back via bitcoin-dev
I dont think people consider other blockchains as a competitive
threat. A PoW-blockchain is a largely singleton data structure
for security reasons (single highest hashrate), it is hard for
an alternative chain to bootstrap or provide meaningful
security. Secondly the world largely lacks expertise to maintain
a blockchain to bitcoin's security level, perhaps you can see a
hint of this in the recently disclosed security vulnerability by
Pieter Wuille and Gregory Maxwell. Calls to this as an argument
are not resonating and probably not helping your argument.
Bitcoin has security properties, and a competing system cant
achieve better properties by bypassing security, any blockchain
faces the same fundamental security / decentralisation
limitations.
Secondly Bitcoin can obviously compete with itself with
different parameters and defacto *does* today. I think it is a
safe estimate that > 99% of Bitcoin transactions right now are
happening in Bitcoin related systems with various degrees of
audit, reconciliation, provable reserves etc. I think we can
expect this to continue and become more secure via more
reconciliation, and longer term via lightning or Bitcoin
sidechains with different parameters. It is a different story to
have a single central system (Bitcoin with parameters changed to
the point of centralisation failure) vs having multiple choices,
because some transactions can more easily use relatively
centralised systems (eg micropayments), and more interestingly
the combination of a secure and decentralised layer 1 plus
choices of less decentralised layer 2 options, can be interesting
because the layer 2 is provided cover from attack. There is less
to be gained by attacking relatively centralised layer 2 because
any payments at risk of policy abuse (which is typically a small
subset) can easily switch to layer 1. That in itself makes layer
2 transactions also less susceptible to policy abuse. Further
lightning it appears from work so far should add significant
scale while retaining trustlessness and a good degree of
decentralisation.
Finally you seem to be focusing on "artificial" limits where
that is not the issue under consideration. The limits are
technical and relating to decentralisation and security. I wont
go over them again as this topic has been covered many times in
recent months. Any chain that tried to go to extreme parameters
(very low block intervals, or very large blocksizes) would have
the same decentralisation problems as Bitcoin would if it did the
same thing. There are a number of alt coins that have failed as
a result of poor parameter choices, there are inherent security
limits.
Adam
ps Etiquette note for yourself and others: please dont be
repetitive or attempt to be forceful. Many people have spent
many years understanding this very complex system, from my own
experience it is rare indeed to think of an entirely new concept
or analysis, that hasnt' been long considered and put to bed 3 or
4 years ago. Thoughtful polite and constructive comments are
welcome but I recommend to not start from an assumption that you
have a clear and better insight than the entire technical
community, because I have to say from my own experience that is
very rarely the case. It can be useful to test theories on
#bitcoin IRC channel to find out what has been already concluded,
find the references and avoid having to have that hashed out on
this list which is trying to be focussed on technical solutions.
On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev

Post by Raystonn . via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev
Cheapest way to send value? Is this what Bitcoin is trying
to do? So all of the smart contract, programmable money,
consensus coding and tremendous developer effort is bent to
the consumer demand for cheaper fees. Surely thou jests!

These other features can be replicated into any alternative
blockchain, including those with lower fees. In the
open-source world of cryptocurrency, no feature will remain a
value-add for very long after it has been identified to be
such. Anything adding value will quickly be absorbed into
competing alternative blockchains. That will leave economic
policy as the distinguishing factor.

Post by Venzen Khaosan via bitcoin-dev
... it is not the case ... that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell
thoroughly explained in this thread that the protocol's
current state of development relies on blocksize for
security and, ultimately, as a means of protecting its degree
of decentralization.

A slow or lack of increase to maximum transaction rate will
cause pressure on fees. Whether this is the desired goal is
not relevant. Everyone has agreed this will be the outcome.
As to a smaller block size being needed for additional
decentralization, one must simply ask how much we are all
willing to pay for that additional decentralization. It is
likely that the benefit thereto will have to be demonstrated by
some power attacking and destroying a less decentralized
currency before the benefit of this feature is given monetary
value by the market. Until then, value will bleed to the
network with the least friction, because it will have the
greatest ability to grow its network effect. That means the
blockchain with adequate features and cheapest fees will
eventually have the largest market share.

[bitcoin-dev]

Post by Adam Back via bitcoin-dev

Post by Raystonn . via bitcoin-dev
Why Satoshi's temporary anti-spam measure isn'ttemporary

Raystonn, I'm aware that you're addressing your question to Greg
Maxwell, however a point you keep stating as fact calls for
On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote: [snip]

Post by Raystonn . via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev

How do you plan to address the bleeding of value from
Bitcoin to alternative lower-fee blockchains created by
the artificially-high bitcoin transaction fees when users
begin looking for the cheapest way to send value?

Cheapest way to send value? Is this what Bitcoin is trying to
do? So all of the smart contract, programmable money, consensus
coding and tremendous developer effort is bent to the consumer
demand for cheaper fees. Surely thou jests!

Post by Raystonn . via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev

Modern economic study has shown that liquidity moves to
the location of least friction.

Modern economic study? Can you please provide a link or
reference to the study you are referring to.
"liquidity moves to the location of least friction"
This sounds like "econo-speak" and makes no sense. The
definition of Liquidity is the degree to which an asset/security
can be bought or sold in the market without affecting the price.
That is why bitcoin is said to have low liquidity: buying or
selling only 100 BTC visibly affects the exchange price. You
probably mean "people like cheap fees", which is true, but as
others have said, because of Bitcoin's powerful features, they
are willing to pay higher fees and wait longer for transactions
to execute.
As for your public cross-examination of Greg Maxwell, your case
seems to be made on the assumption that limiting the size of
the blockchain is an attempt to artificially raise tx fees, but
it is not the case (as you and others repeatedly argue) that
reluctance to concede blocksize is an attempt to constrain
capacity. Greg Maxwell thoroughly explained in this thread that
the protocol's current state of development relies on blocksize
for security and, ultimately, as a means of protecting its degree
of decentralization.
Surely, this is an obvious concern even for those who are
campaigning for the hare-brained ideal of making Bitcoin a
"faster, cheaper alternative" to visa or paypal? If we lose
decentralization, we lose the whole thing, right? Incorrect or
correct?

Post by Raystonn . via bitcoin-dev
_______________________________________________ bitcoin-dev
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________ bitcoin-dev mailing
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Jorge Timón via bitcoin-dev]

On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev

Post by Gavin via bitcoin-dev
I would like (and have been asking) those people to take the time to quantify those costs and write up those risks in a careful way.

I agree that having a "minimal hardware requirements" specification
would greatly help with this discussions.

Post by Gavin via bitcoin-dev
I believe the costs and risks of 8MB blocks are minimal, and that the benefits of supporting more transaction FAR outweigh those costs and risks, but it is hard to have a rational conversation about that when even simple questions like 'what is s reasonable cost to run a full node' are met with silence.

These tests by Rusty (strong advocate of IBLT and working on it) seem
to indicate otherwise: http://rusty.ozlabs.org/?p=509

On Thu, Jul 30, 2015 at 2:50 PM, Pieter Wuille via bitcoin-dev

Post by Gavin via bitcoin-dev
I think the risks of trying to make a controversial change to the network
FAR outweighs the benefits of a small constant factor that "kicks the can
down the road".

I think the risks of a controversial deployment in consensus rules
changes, outweigh by far potential benefits of ANY consensus forks, no
matter how amazing the potential benefits may seem. Bitcoin may not
survive a controversial hardfork or go 3 years back in adoption,
nobody knows.

Post by Gavin via bitcoin-dev
Let's scale the block size gradually over time, according to technological
growth.

I agree. Unfortunately, technological and economic growth is very hard
to predict.

Post by Gavin via bitcoin-dev
2. Bitcoin is much more than a payment network. A lot of the
non-payment features are, arguably, what gives Bitcoin most of its
value. Yet, the payment functionality is a major design feature and
all agree that it should scale - subject to axiom 1.

I just explained why I disagree with this point. Bitcoin fees depend
on transaction sizes rather than amounts moved. Even ignoring
script-based signatures and all the other advantages in Bitcoin, that
fact alone makes it extremely competitive with "traditional systems"
for many use cases (say, sending 1000 usd from the US to México).
I agree overall with your other points.
Extremely cheap and instant transactions can be provided by lightning,
but cannot be provided by Bitcoin in-chain alone in the long term (it
can't even provide instant irreversible transactions).

Post by Gavin via bitcoin-dev
as an insurance against a capacity crisis before layer 2 is deployed,
why not implement bip100's 2MB blocksize proposals in a testnet?

Of all blocksize proposals, bip102 (the one with the single doubling
to 2MB) is the one I dislike less because it doesn't make any
assumptions about future technological or economic growth (I loved
your Bohr cite).
But it still has something that I dislike from all proposals: the
numbers just seem pulled out of a hat.

But I already created that testnet you propose (and
std::numeric_limits<uint64_t>::max() -1 more testnets for other sizes)
in https://github.com/bitcoin/bitcoin/pull/6382

You can run it with the following runtime options: -chain=sizetest
-blocksize=2000000

Unfortunately, nobody seems interested in running some tests for
several sizes before proposing a concrete size.
As far as I know, nobody has used that branch to test different sizes.

[Thomas Zander via bitcoin-dev]

Post by Jorge Timón via bitcoin-dev
It is important ro note that even if lightning was never developed, the
block size remains at 1 MB forever and fees rise to 10 usd per transaction,
such "high fees" are still extremely competitive with non-decentralized
payment systems that have proportional fees.

What makes you think that when there is such a low availability of transaction
space that paying to be included costs you $10, that Bitcoin is not going to
be outcompeted and replaced or otherwise regarded as worthless?

[Bryan Bishop via bitcoin-dev]

On Thu, Jul 30, 2015 at 9:52 AM, Thomas Zander via bitcoin-dev <

Post by Thomas Zander via bitcoin-dev
What makes you think that when there is such a low availability of transaction
space that paying to be included costs you $10, that Bitcoin is not going to
be outcompeted and replaced or otherwise regarded as worthless?

Ah, well that's simple. Because any decentralized system is going to have
high transaction costs and scarcity anyway. So far the only mechanism we
know for how to do this is something like bitcoin. As a centralized system,
bitcoin is already strongly outcompeted by many, many other designs, so
that shouldn't be very surprising I think.

- Bryan
http://heybryan.org/
1 512 203 0507

[Gavin Andresen via bitcoin-dev]

On Thu, Jul 30, 2015 at 11:24 AM, Bryan Bishop via bitcoin-dev <

Because any decentralized system is going to have high transaction costs
and scarcity anyway.

This is a meme that keeps coming up that I think just isn't true.

What other decentralized systems can we look at as role models?

How decentralized are they?

And why did they succeed when "more efficient" centralized systems did not?


The Internet is the most successful decentralized system to date; what
lessons should we learn?

How decentralized is the technology of the Internet (put aside governance
and the issues of who-assigns-blocks-of-IPs-and-registers-domain-names)?
How many root DNS servers? How many BGP routers along the backbone would
need to be compromised to disrupt traffic? Why don't we see more
disruptions, or why are people willing to tolerate the disruptions that DO
happen?

And how did the Internet out-compete more efficient centralized systems
from the big telecom companies? (I remember some of the arguments that
unreliable, inefficient packet-switching would never replace dedicated
circuits that couldn't get congested and didn't have inefficient timeouts
and retransmissions)


What other successful or unsuccessful decentralized systems should we be
looking at?


I'm old-- I graduated from college in 1988, so I've worked in tech through
the entire rise of the Internet. The lessons I believe we should take away
is that a system doesn't have to be perfect to be successful, and we
shouldn't underestimate people's ability to innovate around what might seem
to be insurmountable problems, IF people are given the ability to innovate.

Yes, people will innovate within a 1MB (or 1MB-scaling-to-2MB by 2021) max
block size, and yes, smaller blocks have utility. But I think we'll get a
lot more innovation and utility without such small, artificial limits.

[Thomas Zander via bitcoin-dev]

Post by Gavin Andresen via bitcoin-dev
What other successful or unsuccessful decentralized systems should we be
looking at?

Parallel compiling systems (distcc, icecream, teambuilder).

Git vs subversion (or perforce).

Not a joke; googles search. Not from a user perspective, naturally. But their
filesystem and internal databases.
Wait, let me get a link; https://en.wikipedia.org/wiki/Google_File_System

and since I'm on wikipedia.

https://en.wikipedia.org/wiki/Parallel_rendering

Thinking about it; one inherent trait of successful distributed systems is
that they are fractal-like. Not one huge mesh, but islands that connect.
Bitcoin core does something similar, but it doesn't really. The 'ping' score
for connections is unreliable and its not really used to propagate smartly...

[Bryan Bishop via bitcoin-dev]

Post by Gavin Andresen via bitcoin-dev
On Thu, Jul 30, 2015 at 11:24 AM, Bryan Bishop via bitcoin-dev <

Because any decentralized system is going to have high transaction costs
and scarcity anyway.

This is a meme that keeps coming up that I think just isn't true.

Specifically I was replying to the argument that went like "the bitcoin
system, in any of its futures with a bunch of non-zero transaction fees, is
going to be replaced by a decentralized system that can commit to
transactions that have lower or zero transaction fees, and which also
otherwise provides the same benefits as bitcoin". My reply was that
decentralized systems are going to have physical limitations that force
their solutions to look certain ways, which would do something like, for
example, explain why there were "$10 fees" in that original scenario in the
first place. Your reply does not seem to share this context?

Also, I don't mean to start a discussion about internet architecture, but
ISP peering agreements do not look particularly like a cryptographic,
decentralized system to me at all. I agree that the internet needs better
architecture. I would call the IETF about this but I think Greg would be
the one to answer or something :-). Would be sorta redundant, heh.

- Bryan
http://heybryan.org/
1 512 203 0507

[Thomas Zander via bitcoin-dev]

Post by Bryan Bishop via bitcoin-dev
On Thu, Jul 30, 2015 at 9:52 AM, Thomas Zander via bitcoin-dev <

Post by Thomas Zander via bitcoin-dev
What makes you think that when there is such a low availability of transaction
space that paying to be included costs you $10, that Bitcoin is not going to
be outcompeted and replaced or otherwise regarded as worthless?

Ah, well that's simple. Because any decentralized system is going to have
high transaction costs and scarcity anyway.

I've been doing system design for about 10 years and I can understand your
initial response.

I have to disagree with you, though. Surely decentralized adds an overhead,
but in its place it adds replication, redundancy and very cheap expansion of
capacity.

Remember when we went from single-core CPUs to multi-core (and
hyperthreading)? Developers were saying it was useless because all apps were
still single-threaded. And now, 15 years later, there are fantastic
frameworks to make this easy.

Same will happen with distributed. Any assumption you wrote above is not
inherent in the technology.

[Thomas Zander via bitcoin-dev]

Post by Thomas Zander via bitcoin-dev
Remember when we went from single-core CPUs to multi-core (and
hyperthreading)? Developers were saying it was useless because all apps
were still single-threaded. And now, 15 years later, there are fantastic
frameworks to make this easy.
Same will happen with distributed. Any assumption you wrote above is not
inherent in the technology.

My brain went a bit to fast (dinner was being served, she made me close the
laptop...) and wrote distributed above while the topic is decentralized.
Its not entirely wrong, even; Libraries or approaches that do distributed will
be useful for decentralized systems. ;)

[Mark Friedenbach via bitcoin-dev]

They aren't really so closely related as you are implying, since bitcoin is
a trustlessly decentralized system. At present every participant needs to
be able to validate the entire chain in order to be certain that their copy
of the ledger state is correct, and miners need to be able to incrementally
validate blocks in particularly short timeframes or else.

It is possible for a decentralized system like bitcoin to scale via
distribution in a way that introduces minimal trust, for example by
probabilistic validation and distribution of fraud proofs. However changes
to bitcoin consensus rules (mostly soft-forks) are required in order to
make this possible.

I don't want to discourage thinking about scaling bitcoin in such ways, as
it is a viable medium term proposal. However right now with the bitcoin
that exists today parallel distribution and decentralization are at odds
with each other.

On Thu, Jul 30, 2015 at 10:42 AM, Thomas Zander via bitcoin-dev <

Post by Thomas Zander via bitcoin-dev

Post by Thomas Zander via bitcoin-dev
Remember when we went from single-core CPUs to multi-core (and
hyperthreading)? Developers were saying it was useless because all apps
were still single-threaded. And now, 15 years later, there are

fantastic

Post by Thomas Zander via bitcoin-dev
frameworks to make this easy.
Same will happen with distributed. Any assumption you wrote above is not
inherent in the technology.

My brain went a bit to fast (dinner was being served, she made me close the
laptop...) and wrote distributed above while the topic is decentralized.
Its not entirely wrong, even; Libraries or approaches that do distributed will
be useful for decentralized systems. ;)
--
Thomas Zander
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Eric Lombrozo via bitcoin-dev]

It is possible for a decentralized system like bitcoin to scale via distribution in a way that introduces minimal trust, for example by probabilistic validation and distribution of fraud proofs. However changes to bitcoin consensus rules (mostly soft-forks) are required in order to make this possible.

Please, Mark, let’s make this happen.

You can count on my full support.

[Thomas Zander via bitcoin-dev]

Post by Mark Friedenbach via bitcoin-dev
It is possible for a decentralized system like bitcoin to scale via
distribution in a way that introduces minimal trust, for example by
probabilistic validation and distribution of fraud proofs. However changes
to bitcoin consensus rules (mostly soft-forks) are required in order to
make this possible.

Sounds overly complicated...

What about a much simpler solution where the miner has a CPU in a well
connected data center. Say, Amsterdam.
He runs bitcoind on there and he, in China or such, connects to it over RPC
(and ssl) to get a "block 000f00" accepted signal. Which would be 100 bytes or
so.

The miner continues to use his current setup, but with actual validation of
the blocks to completely eliminate the risk of mining on orphaned blocks and
at the same time remove most of the cost of larger-than-average bandwidth in
his country.

A slightly more complicated solution is needed to allow the miner to only send
the headers to the bitcoind instance. So he only sends a couple of kb and his
datacenter machine does the actual propagation.

If the risk of duplication becomes an issue, setup multiple propagating nodes
on different sides of the world.

Bottom line for me is that most of the innovation for making stuff better for
miners should be done in miners-specific software. Not in end-user software
like bitcoin-core.

[Jorge Timón via bitcoin-dev]

On Thu, Jul 30, 2015 at 4:52 PM, Thomas Zander via bitcoin-dev

Post by Thomas Zander via bitcoin-dev

Post by Jorge Timón via bitcoin-dev
It is important ro note that even if lightning was never developed, the
block size remains at 1 MB forever and fees rise to 10 usd per transaction,
such "high fees" are still extremely competitive with non-decentralized
payment systems that have proportional fees.

What makes you think that when there is such a low availability of transaction
space that paying to be included costs you $10, that Bitcoin is not going to
be outcompeted and replaced or otherwise regarded as worthless?

I'm just saying that rational economic actors will prefer to pay 10
usd over 11 usd in fees.
My example was: 10 usd flat fee vs 1% fee (both numbers pulled out of a hat).
Well, 10 usd fees is cheaper than 1% fees for any transacted amount
greater than 1000 usd.
Take into account that this is just an extreme example to make my
point: hopefully fees will never rise to a value as high as 10 usd.

[odinn via bitcoin-dev]

I will jump in just because I feel like it because the questions are
fun and so on. (Of course I am not Gregory)

Post by Raystonn . via bitcoin-dev
Gregory, can you please speak to the following points. I would
like a better understanding of your positions.

Note that I am not Gregory, so with that caveat...

Post by Raystonn . via bitcoin-dev
1) Do you believe that Bitcoin's future is as a high-value
settlement network?

No, it will have multiple and diverse purposes into which it can be
used for and can evolve, it would not be sufficient to state that it
has "a future" merely as a high-value settlement network.

Post by Raystonn . via bitcoin-dev
2) Do you believe we need an artificial limit to transaction rate,
perhaps implemented as a maximum block size limit? If so, why?

If you have a proposal on this, please submit it in the formal way as
a BIP draft. Enough time has been burnt on the subject, imho.

Post by Raystonn . via bitcoin-dev
3) Transaction fees will fluctuate with global economic conditions
and technology. Those free-market fluctuations should equally
affect any blockchain. However, if transaction fees on the Bitcoin
network are pushed artificially high, such as with an artificial
limit to transaction rate only applicable to Bitcoin, this will
create a condition where some other blockchains will have lower
fees. How do you plan to address the bleeding of value from
Bitcoin to alternative lower-fee blockchains created by the
artificially-high bitcoin transaction fees when users begin looking
for the cheapest way to send value? Modern economic study has
shown that liquidity moves to the location of least friction.

It is the market. What will happen will happen. If bitcoin
development pushes fees upward as an overall trend and the overall
cost to transact continues to increase, billions of people around the
world will as a result be forced out from most use cases of bitcoin
and the "bleeding out" will occur naturally to alts (to the extent
that persons already possessed bitcoin first and need to transact).
As stated above, liquidity moves to location of least friction.
Bitcoin bagholders can whine all they want, but value will distribute
into the alts gradually.

Post by Raystonn . via bitcoin-dev
4) If you believe it's not a problem to allow alternative
blockchains to leech some of Bitcoin's value,

"allow" is not a relevant term here, as it is not up to anyone what
people are going to do with their crypto of any kind. Unless, of
course, you are fool enough to be using Coinbase and Bitpay or
something like that. They own "your" coin, and they will decide, or
allow, what you do with it or whether you can even access it.
As has been stated before here, I hope you are not using such services.
On the other hand, the following are very interesting:
https://gear.mycelium.com/ - a Payment processor
http://openbazaar.org a decentralized Market
https://bitsquare.io/ a decentralized Exchange
https://electrum.org/ a light wallet that you manage

Post by Raystonn . via bitcoin-dev
a) How much value is it acceptable to lose?

Irrelevant. Better question is, How much should one give? The more
you can give, the better off you will be.

Post by Raystonn . via bitcoin-dev
b) How do you think this will affect Bitcoin miners, whose large
investments in hardware do not transfer to other blockchains?

Too much attention is paid to the miners. Miners should not be
butthurt when people say that we should not put them up on a pedestal.
Think ahead, to when there will no longer be bitcoin mining such as
there is today.

Post by Raystonn . via bitcoin-dev
c) How do you think this will affect the investors and holders of
bitcoin in general?

People will continue to buy and sell. Some major changes are in
store, however. If you would like, see my reflections on what the
months ahead will hold, here:
http://www.twitlonger.com/show/n_1sn3lqs

Post by Raystonn . via bitcoin-dev
-----Original Message----- From: Gregory Maxwell via bitcoin-dev
Sent: Wednesday, July 29, 2015 1:09 PM To: Owen Cc: Bitcoin Dev
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam
measure isn'ttemporary
On Wed, Jul 29, 2015 at 7:56 PM, Owen via bitcoin-dev

Post by Owen via bitcoin-dev

Post by Mike Hearn via bitcoin-dev
Consider this: the highest Bitcoin tx fees can possibly go is
perhaps a little higher than what our competition charges. Too
much higher than that, and people will just say, you know what
.... I'll make a bank transfer. It's cheaper and not much
slower, sometimes no slower at all.

I respectfully disagree with this analysis. The implication is
that bitcoin is merely one of a number of payment technologies.
It's much more than that. It's sound money, censorship
resistance, personal control over money, programmable money, and
more. Without these attributes it's merely a really inefficient
way to do payments.
Given these advantages, there is no reason to believe the
marginal cost of a transaction can't far surpass that of a PayPal
or bank transfer. I personally would pay several multiples of the
competitors' fees to continue using bitcoin.
Sure, some marginal use cases will drop off with greater fees,
but that's normal and expected. These will be use cases where the
user doesn't care about bitcoin's advantages. We must be willing
to let these use cases go anyway, because we unfortunately don't
have room on chain for everything anyone might want to do.
Therefore, bitcoin tx fees can go much higher than the
competition.
Remember how Satoshi referenced the banking crisis in his early
work? The 2008 banking crisis was about a lot of things, but high
credit card and paypal fees wasnt one of them. There's more going
on here than just payments. Any speculative economic analysis
would do better to include this fact.

Precisely. And as "just a payment system" Bitcoin is not an
especially great one: The design requirements for
decenteralization impose considerable costs. To the extent that
the technology in Bitcoin is useful at all for building "just
another payment system" this technology in in the process of being
agressively copied by parties with deep fiat relationships
(including in partnership with centeral banks). If the focus for
Bitcoin's competative advantage becomes exclusively "better"
payments then it will almost certinatly fail in the market-place
against competing systems which avoid the Bitcoin currency adoption
related obsticles (but also gain none of Bitcoin's important
social/political promise).
Also, critically, if Bitcoin's security properties are manintained
and enhanced then Bitcoin can be used to build secure systems which
_also_ accomidate those applications and we can have both. But if
Bitcoin's security properties are not strong then then advanced
tools cannot be built for it. E.g. atomic swaps make trustless
trades with external systems possible; but they are especially
sensitive to long reorginizations by miners... so they can only be
securely used where those reorgs are infeasable. So while I agree
that we must be willing to tolerate not catching every conceivable
use case; most of the time all that means is addressing them via a
less direct but more focused solution rather than ignoring them
completely. _______________________________________________
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________ bitcoin-dev mailing
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn

[Raystonn . via bitcoin-dev]

All of the properties you describe are also properties of many of the
alternative blockchains that currently exist. In this space, Bitcoin gives
up these advantages. Much like anywhere else where liquidity moves within a
system, value will move to the network of least friction. The reality right
now is it's very easy to move value from Bitcoin to another blockchain with
less friction. Because of this, there will never be a high value settlement
network created by an artificially imposed limit on transaction rate. The
value will simply bleed out of Bitcoin to alternative blockchains offering
lower fees if this is attempted. This is basic economics.

-----Original Message-----
From: Owen via bitcoin-dev
Sent: Wednesday, July 29, 2015 12:56 PM
To: Bitcoin Dev
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measureisn't
temporary

Post by Mike Hearn via bitcoin-dev
Consider this: the highest Bitcoin tx fees can possibly go is perhaps a
little higher than what our competition charges. Too much higher than that,
and people will just say, you know what .... I'll make a bank transfer.
It's cheaper and not much slower, sometimes no slower at all.

I respectfully disagree with this analysis. The implication is that bitcoin
is merely one of a number of payment technologies. It's much more than that.
It's sound money, censorship resistance, personal control over money,
programmable money, and more. Without these attributes it's merely a really
inefficient way to do payments.

Given these advantages, there is no reason to believe the marginal cost of a
transaction can't far surpass that of a PayPal or bank transfer. I
personally would pay several multiples of the competitors' fees to continue
using bitcoin.

Sure, some marginal use cases will drop off with greater fees, but that's
normal and expected. These will be use cases where the user doesn't care
about bitcoin's advantages. We must be willing to let these use cases go
anyway, because we unfortunately don't have room on chain for everything
anyone might want to do.

Therefore, bitcoin tx fees can go much higher than the competition.

Remember how Satoshi referenced the banking crisis in his early work? The
2008 banking crisis was about a lot of things, but high credit card and
paypal fees wasnt one of them. There's more going on here than just
payments. Any speculative economic analysis would do better to include this
fact.

[Thomas Zander via bitcoin-dev]

Post by Mike Hearn via bitcoin-dev

Enter a “temporary” anti-spam measure - a one megabyte block size limit.

The one megabyte limit was nothing to do with anti spam. It was a quick
kludge to try and avoid the user experience degrading significantly in
the event of a "DoS block", back when everyone used Bitcoin-Qt. The fear
was that some malicious miner would generate massive blocks and make the
wallet too painful to use, before there were any alternatives.

I thought I clarified this in an earlier post - I meant DoS. Please don’t
digress on such stupid technicalities.

This particular technicality is rather important since it removes the basis of
your argument.
More specifically, your 4 points of what you claim Satoshi expected to happen,
but didn't were in actual fact not planned, wanted or predicted by Satoshi.

So, you can do name calling if you want, but maybe thats not very productive.

Post by Mike Hearn via bitcoin-dev
The plan was to remove it once SPV wallets were widespread. But Satoshi
left before that happened.

Guess what? SPV wallets are still not particularly widespread…

This is an odd statement, we keep on hearing about low bitcoin-core node count
and since that is the only alternative, your statement can only be interpreted
as saying there really are not a whole lot of users out there..
Is that really what you mean?

and those that
are out there are notoriously terrible at detecting network forks and
making sure they are on the right one.

What is the point you are trying to make with that? It seems completely
irrelevant to the point of this thread...

[Jorge Timón via bitcoin-dev]

On Wed, Jul 29, 2015 at 12:43 PM, Eric Lombrozo via bitcoin-dev

Erm…most miners just trust mining pool operators to validate blocks for
them…and some of the biggest pools have been blatantly cutting corners. Yes,
a few pools might have temporarily bled a little…but properly validating is
probably not the equilibrium strategy…and as time goes on, they are likely
to start cutting corners again. Whether they ultimately bleed money isn’t
really the point - many believe that cutting corners is actually a rational
strategy. If you want to discuss the game theory behind this, fine…but the
fact some of the biggest mining pool operators are on record saying they are
likely to continue doing this is enough to seriously put to question one of
the most fundamental assumptions behind the network security model.

Actually validating blocks IS the equilibrium strategy. When the
subsidy is completely gone (or at least when the block reward is not
almost exclusively composed of subsidy [a future where fees are not a
completely negligible part of the total reward]), miners will
re-calculate their estimations and they will find out that mining
empty blocks won't be so profitable in a future with less subsidy. In
fact, with the incentives they currently have (negligible fees)
actually bothering about including transactions at all it's not really
worth it for them. They may just do it because they're nice people,
meta-incentives...whatever the reason is, they users are enjoying a
service they're not paying for.

Only subsidy and no fees creates other incentive problems, not just
SPV mining. But apparently some people think that scaring some users
with unreasonable expectations away because they have to pay fees
(still, non-proportional [to the amount you're moving] fees due to the
irreversibility of the payments: something the reversible payments
based on the banking industry can't simply compete with) it's much
worse than perpetuating big incentive problems that could break the
system. And, of course, short term convenience for users is much more
important than figuring out the long term viability of the system once
the seigniorage (spent on the miner's subsidy) goes away.

The pattern seems clear to be: decentralization and long term
viability don't matter too much to some people.
For some people, short term market cap seems to be the most important
priority and everything else is secondary.

[Thomas Zander via bitcoin-dev]

Post by Jorge Timón via bitcoin-dev
And, of course, short term convenience for users is much more
important than figuring out the long term viability of the system once
the seigniorage (spent on the miner's subsidy) goes away.

There are various decades spanned in that sentence. Your idea of "short term"
is vastly different from mine.

[Gregory Maxwell via bitcoin-dev]

On Wed, Jul 29, 2015 at 9:59 AM, Mike Hearn via bitcoin-dev

Post by Mike Hearn via bitcoin-dev
I do love history lessons from people who weren't actually there.

I doubt the rest of us really enjoy hearing these "lessons" from from
you where you wildly distort history to reflect your views.

Post by Mike Hearn via bitcoin-dev
Satoshi explicitly envisioned a future where only miners ran nodes, so it
had nothing to do with this either.

As others have pointed out-- even if this were true, --- so what?
Many errors were made early on in Bitcoin.

But in this case it's not actually true and I'm really getting fed up
with this continued self-appointment of all that the creator of the
system thought. Your position and knoweldge is not special or
priveleged compared to many of the people that you are arguing with.

It was _well_ understood while the creator of the system was around
that putting every consensus decision into the world into one system
would not scale; and also understood that the users of Bitcoin would
wish to protect its decenteralization by limiting the size of the
chain to keep it verifyable on small devices.

Don't think you can claim otherwise, because doing so is flat out wrong.

In the above statement you're outright backwards-- there was a clear
expectation that all who ran nodes would mine. The delegation of
consensus to third parties was unforseen. Presumably Bitcoin core
making mining inaccessable to users in software was also unforseen.

Post by Mike Hearn via bitcoin-dev
Validators validate for themselves. Calculating a local UTXO set and then
not using it for anything doesn't help anyone. SPV wallets need filtering
and serving capability, but a computer can filter and serve the chain
without validating it.
The only purposes non-mining, non-rpc-serving, non-Qt-wallet-sustaining full

[...]

Post by Mike Hearn via bitcoin-dev
Outside of serving lightweight P2P wallets there's no purpose in running a
P2P node if you aren't mining, or using it as a **trusted node for your own
operations**.

You wrote a long list of activities that are actually irrelevant to
many node users with the result of burrying the main reason any party
should be running a node (emphasis mine).

The incentives of the system demand as it exist today that many other
economically significant parties run nodes in order to keep the half
dozen miners from having a blank check to do whatever they want
(including supporting their operations through inflation)-- do not
think they wouldn't, as we've seen their happy to skip verification
entirely.

(Which, incidentially, is insanely toxic to any security argument for
SPV; ---- and now we see the market failure that results from your and
Gavin years long campaign to ignore problems in the mining ecosystem:
The SPV model which you've fixated on as the true nature of bitcoin
has been demonstrated in practice to have a potentially empty security
claim.)

Post by Mike Hearn via bitcoin-dev
Miners who don't validate have a habit of bleeding money: that's the
system working as designed.

The information I have currently is that the parties engaging in that
activity found it to be tremendously profitable, even including losses
from issues.

[Sriram Karra via bitcoin-dev]

On Wed, Jul 29, 2015 at 10:23 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-***@lists.linuxfoundation.org> wrote:

On Wed, Jul 29, 2015 at 9:59 AM, Mike Hearn via bitcoin-dev

Post by Gregory Maxwell via bitcoin-dev

Post by Mike Hearn via bitcoin-dev
Miners who don't validate have a habit of bleeding money: that's the
system working as designed.

The information I have currently is that the parties engaging in that
activity found it to be tremendously profitable, even including losses
from issues.

Is there any shred of evidence either of you can share to support your
claims on this pivotal point of interest to everyone here?

[Mike Hearn via bitcoin-dev]

It was _well_ .... understood that the users of Bitcoin would wish to
protect its decenteralization by limiting the size of the chain to keep it
verifyable on small devices.

No it wasn't. That is something you invented yourself much later. "Small
devices" isn't even defined anywhere, so there can't have been any such
understanding.

The actual understanding was the opposite. Satoshi's words:

"At first, most users would run network nodes, but as the network grows
beyond a certain point, it would be left more and more to specialists with
server farms of specialized hardware."

That is from 2008:


http://satoshi.nakamotoinstitute.org/emails/cryptography/2/#selection-75.16-83.14


Then he went on to talk about Moore's law and streaming HD videos and the
like. At no point did he ever talk about limiting the system for "small
devices".

I have been both working on and using Bitcoin for longer than you have been
around, Gregory. Please don't attempt to bullshit me about what the plan
was. And stop obscuring what this is about. It's not some personality cult
- the reason I keep beating you over the head with Satoshi's words is
because it's that founding vision of the project that brought everyone
together, and gave us all a shared goal.

If Satoshi had said from the start,

"Bitcoin cannot ever scale. So I intend it to be heavily limited and
used only by a handful of people for rare transactions. I picked 1mb as an
arbitrary limit to ensure it never gets popular."

... then I'd have not bothered getting involved. I'd have said, huh, I
don't really feel like putting effort into a system that is intended to NOT
be popular. And so would many other people.


Don't think you can claim otherwise, because doing so is flat out wrong.
I just did claim otherwise and no, I am not wrong at all.

(Which, incidentially, is insanely toxic to any security argument for

SPV; ---- and now we see the market failure that results from your and

Since when have we "campaigned" to "ignore problems" in the mining
ecosystem? What does that even mean? Was it not I who wrote this blog post?


http://blog.bitcoinfoundation.org/mining-decentralisation-the-low-hanging-fruit/

Gregory, you are getting really crazy now. Stop it. The trend towards
mining centralisation is not the fault of Gavin or myself, or anyone else.
And SPV is exactly what was always intended to be used. It's not something
I "fixated" on, it's right there in the white paper. Satoshi even
encouraged me to keep working on bitcoinj before he left!


Look, it's clear you have decided that the way Bitcoin was meant to evolve
isn't to your personal liking. That's fine. Go make an alt coin where your
founding documents state that it's intended to always run on a 2015
Raspberry Pi, or whatever it is you mean by "small device". Remove SPV
capability from the protocol so everyone has to fully validate. Make sure
that's the understanding that everyone has from day one about what your alt
coin is for. Then when someone says, gee, it'd be nice if we had some more
capacity, you or someone else can go point at the announcement emails and
say "no, GregCoin is meant to always be verifiable on small devices, that's
our social contract and it's written into the consensus rules for that
reason".

But your attempt to convert Bitcoin into that altcoin by exploiting a
temporary hack is desperate, and deeply upsetting to many people. Not many
quit their jobs and created companies to build products only for today's
tiny user base.


My list of "things a full node is useful for" wasn't ordered by importance,
by the way.

[Gregory Maxwell via bitcoin-dev]

Post by Mike Hearn via bitcoin-dev

It was _well_ .... understood that the users of Bitcoin would wish to
protect its decenteralization by limiting the size of the chain to keep it
verifyable on small devices.

No it wasn't. That is something you invented yourself much later. "Small
devices" isn't even defined anywhere, so there can't have been any such
understanding.

[...]

Post by Mike Hearn via bitcoin-dev
Then he went on to talk about Moore's law and streaming HD videos and the
like. At no point did he ever talk about limiting the system for "small
devices".
I have been both working on and using Bitcoin for longer than you have been
around, Gregory. Please don't attempt to bullshit me about what the plan
was. And stop obscuring what this is about. It's not some personality cult -
the reason I keep beating you over the head with Satoshi's words is because
it's that founding vision of the project that brought everyone together, and
gave us all a shared goal.

Mike, my first use of Bitcoin was in 2009. I wasn't vigorously active
in the Bitcoin community until the beginning of 2011, indeed. But this
is just a couple months after you (E.g. first code available for
BitcoinJ was March 2011-- if you go by forums.bitcoin.org account
times my account was created May 5th 2011 vs yours Dec 14th 2010; less
than five months after yours). I was also working with related systems
long before (E.g. RPOW in 2004). So give me a break, there is no rank
to pull here.

Yet again you've managed to call me a bullshitter and guilty of
"invention" when in fact I'm actually quoting the system's creator
(although without the explicit fallacious argument from authority
style you seem prefer). For someone who seems to base all his
arguments on interpretations of someone's words you sure seem to call
their words lies awfully often:

"Piling every proof-of-work quorum system in the world into one
dataset doesn't scale."
[...]
"Bitcoin users might get increasingly tyrannical about limiting the
size of the chain so it's easy for lots of users and small devices."
---- https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917

If you'll note,, the post was Dec 10th 2010 and, presumably, made with
an improved understanding of the implications of the system then
comments made in 2008 before the system was even operational.

(The same message also mentions that smart contracts can be used to
create trustless trade with off-chain systems; As well, later in that
thread: "it will be much easier if you can freely use all the space
you need without worrying about paying fees for expensive space in
Bitcoin's chain.")

I haven't bothered arguing from old posts in the past because I find
the practice of argument from authority on this subject abhorrent. It
undermines the unique value of Bitcoin to argue based on a single
personal opinion, to do so is to miss the point of Bitcoin in a deep
and fundamental way. And in my opinion what you're doing is actually
much worse: arguing from distortions of random quotations. But it's
hard to tolerate the continue revision of history from you in silence.

Moreover, I find those arguments with respect Moore's law especially
unconvincing because while I cannot read the mind of people who are
not a part of this discussion and haven't chosen to comment, I've used
the same argument myself and I know what I was thinking when I used it
(and can establish as much, since I'm more verbose I elaborated on
it): When someone pointed at Bitcoins _global_ broadcast medium and
loudly said that it cannot work because its absurd; and it's very easy
to point out broad scaling behavior about what Bitcoin could achieve
with complete centralization. Once this has been accepted the argument
is _over_ in Bitcoin's favor: Bitcoin's competition has highly
centralized administration and so once someone has accepted Bitcoin
can (in some way) accommodate the worlds transactions, even if that
comes at the cost of 99% of the decentralization, it's clear that
Bitcoin offers something interesting. (And for example, I elaborated
on this in a Wiki edit in Aug 2011,
https://en.bitcoin.it/w/index.php?title=Scalability&action=historysubmit&diff=14273&oldid=14112
-- though I shouldn't need to point this out to you, since it was you
who subsequently erased these words from the page.)

Post by Mike Hearn via bitcoin-dev
Since when have we "campaigned" to "ignore problems" in the mining
ecosystem?

[...]

Post by Mike Hearn via bitcoin-dev
Gregory, you are getting really crazy now. Stop it. The trend towards mining
centralisation is not the fault of Gavin or myself, or anyone else.

For example, you fought vigorously to get Bitcoin Core off
Bitcoin.org, which would ensure that users were not previously
equipped with a node suitable for operating mining (which then
contributed substantially to the poor usability of solutions like
P2Pool; with 98% of it's install time spent waiting for Bitcoin Core
to sync).

You've (in my view) aggressively advocated increasing the resource
utilization of Bitcoin-- increasing the cost to participate in mining
without delegation, with no consideration (or at least disclosure) of
the ramifications on the system overall:
https://bitcointalk.org/index.php?topic=149668.0

Gavin, for example, has advocated removing mining support from Bitcoin
core on several occasions; and constantly professes ignorance on
anything mining. His own interests are up to him, but to not be
concerned about a central part of the system for anyone working on
changing it at such a deep level is-- I think-- a bit problematic.

But I didn't intend to lay blame here, if anything I blame myself for
not being more proactive in arguing against things things in the past.

The trend towards mining centralization is a result of various forces,
many of which are modulated by the very things we're discussing here
(or could be modulated by things we haven't discussed). You're the
principle advocate of increasing the cost of a decentralized ecosystem
around verification and driving the system towards a state where it is
only viable in a more centralized mode. Bitcoin is an artificial
construction, not a force of nature, and when someone seeks to change
it they ought to take responsibility for what happens--- it's not
acceptable to say "oh well, it's not eh fault of anyone" when the
incentives drive it in a bad direction.

Is that your strategy on the systems resource consumption in general?
Full throttle, no action when it goes off the rails, when the easily
foreseeable negative outcomes happen it won't be the "fault" of
anyone? If so, I don't think that is acceptable. We need to face the
areas in which the system is failing, now and in the future... and not
just pump for growth at all cost and shrug and say "oh well, we tried"
when the predictable failure happens. It's far from clear to me that
the world will get a second shot at this in the next several decades
if Bitcoin lapses into the same-old, same-old.

Post by Mike Hearn via bitcoin-dev
And SPV
is exactly what was always intended to be used. It's not something I
"fixated" on, it's right there in the white paper. Satoshi even encouraged
me to keep working on bitcoinj before he left!

The fixation comment was a specific reply to your long list of the
"only reasons" to run a full node, which seemed to be basically said
that the only reason to run one was to act as a server for SPV
clients; as it listed several points on that-- all three of the
numbered points were "serving SPV wallets"-- and buried the rest. I'm
sorry if I read too much into it, though it's also consistent with
your prior responses that the non-scalability of Bitcoin as a whole is
irrelevant due to SPV.

I don't think there is anything fundamentally bad with SPV, it is what
it is; it's a tool and an important one. But at the moment it is far
more limited than you give it credit for both because it is only
secure under certain assumptions which have been provably violated not
just at risk of violation, and because the more complete vision of it
(e.g. with fraud proofs) has never been implemented.

Post by Mike Hearn via bitcoin-dev
Look, it's clear you have decided that the way Bitcoin was meant to evolve
isn't to your personal liking. That's fine. Go make an alt coin where your
founding documents state that it's intended to always run on a 2015
Raspberry Pi, or whatever it is you mean by "small device". Remove SPV
capability from the protocol so everyone has to fully validate. Make sure
that's the understanding that everyone has from day one about what your alt
coin is for. Then when someone says, gee, it'd be nice if we had some more
capacity, you or someone else can go point at the announcement emails and
say "no, GregCoin is meant to always be verifiable on small devices, that's
our social contract and it's written into the consensus rules for that
reason".

Now that I've established the "small device" text you're railing on
here actually came from the system's creator prior to your
involvement, can I expect an admission that your own "personal liking"
doesn't have special authority over the system? But I hope you don't
create an altcoin: I think it's possible to find ways to accommodate
people with very different preferences under one tent, and if we are
to build and support a worldwide system we _must_ find those ways
rather than fragmenting the marketplace.

[Thomas Zander via bitcoin-dev]

I have just been around for 2 years or so, and its interesting to see you two
argue and give links to the past conversations.

But do realize that if you argue in public about content that is easy to read
by anyone that you have to double check your memory fits the facts.
And I feel you skipped that this time...

Post by Gregory Maxwell via bitcoin-dev
(The same message also mentions that smart contracts can be used to
create trustless trade with off-chain systems;
As well, later in that
thread: "it will be much easier if you can freely use all the space
you need without worrying about paying fees for expensive space in
Bitcoin's chain.")

Hmm... A DNS record is much much bigger than a single bitcoin transaction has
space for.
I don't think you can take his quote out of context. The thread shows that
having a full domain-registry DB on chain is what he was explaining doesn't fit
with Bitcoin.
So Satoshi just explains that a rich database shouldn't live on the
blockchain. Similarly with the quote you made before;
"Piling every proof-of-work quorum system in the world into one
dataset doesn't scale."
It just fights the stupid idea of sharing the blockchain space with tons of
global databases.

Please re-read the whole thread as it really doesn't support your view that
Satoshi argued that somehow decentralization would be protected by limiting
the size of the chain.

[odinn via bitcoin-dev]

Mike, tone it down, please, when I read your stuff it's like you are
drinking too much Red bull or something.

It was _well_ .... understood that the users of Bitcoin would wish
to protect its decenteralization by limiting the size of the chain
to keep it verifyable on small devices.
No it wasn't. That is something you invented yourself much later.
"Small devices" isn't even defined anywhere, so there can't have
been any such understanding.
"At first, most users would run network nodes, but as the network
grows beyond a certain point, it would be left more and more to
specialists with server farms of specialized hardware."
http://satoshi.nakamotoinstitute.org/emails/cryptography/2/#selection-

75.16-83.14

Then he went on to talk about Moore's law and streaming HD videos
and the like. At no point did he ever talk about limiting the
system for "small devices".
I have been both working on and using Bitcoin for longer than you
have been around, Gregory. Please don't attempt to bullshit me
about what the plan was. And stop obscuring what this is about.
It's not some personality cult - the reason I keep beating you over
the head with Satoshi's words is because it's that founding vision
of the project that brought everyone together, and gave us all a
shared goal.
If Satoshi had said from the start,
"Bitcoin cannot ever scale. So I intend it to be heavily limited
and used only by a handful of people for rare transactions. I
picked 1mb as an arbitrary limit to ensure it never gets popular."
... then I'd have not bothered getting involved. I'd have said,
huh, I don't really feel like putting effort into a system that is
intended to NOT be popular. And so would many other people.
Don't think you can claim otherwise, because doing so is flat out wrong.
I just did claim otherwise and no, I am not wrong at all.
(Which, incidentially, is insanely toxic to any security argument
for SPV; ---- and now we see the market failure that results from
your and Gavin years long campaign to ignore problems in the mining
Since when have we "campaigned" to "ignore problems" in the mining
ecosystem? What does that even mean? Was it not I who wrote this blog post?
http://blog.bitcoinfoundation.org/mining-decentralisation-the-low-hang

ing-fruit/

Gregory, you are getting really crazy now. Stop it. The trend
towards mining centralisation is not the fault of Gavin or myself,
or anyone else. And SPV is exactly what was always intended to be
used. It's not something I "fixated" on, it's right there in the
white paper. Satoshi even encouraged me to keep working on bitcoinj
before he left!
Look, it's clear you have decided that the way Bitcoin was meant
to evolve isn't to your personal liking. That's fine. Go make an
alt coin where your founding documents state that it's intended to
always run on a 2015 Raspberry Pi, or whatever it is you mean by
"small device". Remove SPV capability from the protocol so everyone
has to fully validate. Make sure that's the understanding that
everyone has from day one about what your alt coin is for. Then
when someone says, gee, it'd be nice if we had some more capacity,
you or someone else can go point at the announcement emails and say
"no, GregCoin is meant to always be verifiable on small devices,
that's our social contract and it's written into the consensus
rules for that reason".
But your attempt to convert Bitcoin into that altcoin by exploiting
a temporary hack is desperate, and deeply upsetting to many people.
Not many quit their jobs and created companies to build products
only for today's tiny user base.
My list of "things a full node is useful for" wasn't ordered by
importance, by the way.
_______________________________________________ bitcoin-dev mailing
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn

[Raystonn via bitcoin-dev]

_______________________________________________
bitcoin-dev mailing list
bitcoin-***@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Milly Bitcoin via bitcoin-dev]

I have been looking up ways to measure decentralization at the moment.
There are some good discussions as they relate to Bitcoin but they are
scattered in different places. I just took over BitcoinStandards.com so
i thought about using that site to post stuff.

Russ

Russ, do you have time to get started on your list? It would add value.
On 30 Jul 2015 5:15 pm, Milly Bitcoin via bitcoin-dev
These are the types of things I have been discussing in relation to a
-A list of metrics
-A Risk analysis of the baseline system. Bitcoin as it is now.
-Mitigation strategies for each risk.
-A set of goals.
-A Road map for each goal that lists the changes or possible avenues to
achieve that goal.
Proposed changes would be measured against the same metrics and a risk
analysis done so it can be compared with the baseline.
For example, the block size debate would be discussed in the context of
a road map related to a goal of increase scaling. One of the metrics
would be a decentralization metric. (A framework for a
decentralization
metric is at
http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf).
Cost would be one aspect of the decentralization metric.
Russ

[Jean-Paul Kogelman via bitcoin-dev]

Forgot to include the list.

Date: July 31, 2015 at 4:02:20 PM PDT
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
- A Minimum Specification of hardware: This is the lowest hardware configuration Bitcoin Core will run on at maximum capacity.
- A theoretical model that takes into account all of the components in Bitcoin Core and how they affect Min Spec.
- A benchmark tool to measure how changes affect Min Spec (and for users to see how their hardware measures up to Min Spec).
jp

Post by Jorge Timón via bitcoin-dev
On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev

Post by Milly Bitcoin via bitcoin-dev
These are the types of things I have been discussing in relation to a
-A list of metrics
-A Risk analysis of the baseline system. Bitcoin as it is now.
-Mitigation strategies for each risk.
-A set of goals.
-A Road map for each goal that lists the changes or possible avenues to
achieve that goal.
Proposed changes would be measured against the same metrics and a risk
analysis done so it can be compared with the baseline.
For example, the block size debate would be discussed in the context of a
road map related to a goal of increase scaling. One of the metrics would be
a decentralization metric. (A framework for a decentralization metric is at
http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf).
Cost would be one aspect of the decentralization metric.

All this sounds very reasonable and useful.
And if a formal organization owns this "process", that's fine as well.
I still think hardforks need to be uncontroversial (using the vague "I
will know it when I see it" defintion) and no individual or
organization can be an "ultimate decider" or otherwise Bitcoin losses
all it's p2p nature (and this seems the point where you, Milly, and I
disagree).
But metrics and data tend to help when it comes to "I will know it
when I see it" and "evidences".
So, yes, by all means, let's have an imperfect decentralization metric
rather than not having anything to compare proposals. Competing
decentralization metrics can appear later: we need a first one first.
I would add that we should have sets of simulations being used to
calculate some of those metrics, but maybe I'm just going too deep
into details.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev