* [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
@ 2015-07-28 22:25 Eric Lombrozo
2015-07-29 0:43 ` Jean-Paul Kogelman
2015-07-29 9:59 ` Mike Hearn
0 siblings, 2 replies; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-28 22:25 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]
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.
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-28 22:25 [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
@ 2015-07-29 0:43 ` Jean-Paul Kogelman
2015-07-29 0:44 ` Eric Lombrozo
2015-07-29 0:46 ` Mark Friedenbach
2015-07-29 9:59 ` Mike Hearn
1 sibling, 2 replies; 69+ messages in thread
From: Jean-Paul Kogelman @ 2015-07-29 0:43 UTC (permalink / raw)
To: Eric Lombrozo; +Cc: 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
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 0:43 ` Jean-Paul Kogelman
@ 2015-07-29 0:44 ` Eric Lombrozo
2015-07-29 0:46 ` Mark Friedenbach
1 sibling, 0 replies; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-29 0:44 UTC (permalink / raw)
To: Jean-Paul Kogelman; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
> On Jul 28, 2015, at 5:43 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>
>
>> 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.
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 0:43 ` Jean-Paul Kogelman
2015-07-29 0:44 ` Eric Lombrozo
@ 2015-07-29 0:46 ` Mark Friedenbach
2015-07-29 0:55 ` Eric Lombrozo
1 sibling, 1 reply; 69+ messages in thread
From: Mark Friedenbach @ 2015-07-29 0:46 UTC (permalink / raw)
To: Jean-Paul Kogelman; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]
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 <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> > 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
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 1628 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 0:46 ` Mark Friedenbach
@ 2015-07-29 0:55 ` Eric Lombrozo
2015-07-29 2:40 ` Eric Lombrozo
0 siblings, 1 reply; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-29 0:55 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: Bitcoin Dev
[-- Attachment #1.1: Type: text/plain, Size: 2150 bytes --]
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
> On Jul 28, 2015, at 5:46 PM, Mark Friedenbach <mark@friedenbach•org> wrote:
>
> 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 <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
> > 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
> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
[-- Attachment #1.2: Type: text/html, Size: 3281 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 0:55 ` Eric Lombrozo
@ 2015-07-29 2:40 ` Eric Lombrozo
2015-07-29 3:37 ` Eric Lombrozo
2015-07-29 11:18 ` Thomas Zander
0 siblings, 2 replies; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-29 2:40 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: Bitcoin Dev
[-- Attachment #1.1: Type: text/plain, Size: 5861 bytes --]
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
> On Jul 28, 2015, at 5:55 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
> 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
>
>> On Jul 28, 2015, at 5:46 PM, Mark Friedenbach <mark@friedenbach•org <mailto:mark@friedenbach•org>> wrote:
>>
>> 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 <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>>
>> > 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
>> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>
>
[-- Attachment #1.2: Type: text/html, Size: 8167 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 2:40 ` Eric Lombrozo
@ 2015-07-29 3:37 ` Eric Lombrozo
2015-07-29 3:46 ` Milly Bitcoin
2015-07-29 11:18 ` Thomas Zander
1 sibling, 1 reply; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-29 3:37 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: Bitcoin Dev
[-- Attachment #1.1: Type: text/plain, Size: 494 bytes --]
> On Jul 28, 2015, at 7:40 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
> 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?!?!?!?
[-- Attachment #1.2: Type: text/html, Size: 1352 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 3:37 ` Eric Lombrozo
@ 2015-07-29 3:46 ` Milly Bitcoin
2015-07-29 5:17 ` Eric Lombrozo
0 siblings, 1 reply; 69+ messages in thread
From: Milly Bitcoin @ 2015-07-29 3:46 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 3:46 ` Milly Bitcoin
@ 2015-07-29 5:17 ` Eric Lombrozo
0 siblings, 0 replies; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-29 5:17 UTC (permalink / raw)
To: Milly Bitcoin; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]
> On Jul 28, 2015, at 8:46 PM, Milly Bitcoin via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> 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
> bitcoin-dev@lists•linuxfoundation.org
> 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
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-28 22:25 [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-29 0:43 ` Jean-Paul Kogelman
@ 2015-07-29 9:59 ` Mike Hearn
2015-07-29 10:43 ` Eric Lombrozo
2015-07-29 16:53 ` Gregory Maxwell
1 sibling, 2 replies; 69+ messages in thread
From: Mike Hearn @ 2015-07-29 9:59 UTC (permalink / raw)
To: Eric Lombrozo; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4318 bytes --]
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!
> 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.
> 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
> 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.
> 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
> 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.
> 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?
[-- Attachment #2: Type: text/html, Size: 5720 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 9:59 ` Mike Hearn
@ 2015-07-29 10:43 ` Eric Lombrozo
2015-07-29 11:15 ` Mike Hearn
` (2 more replies)
2015-07-29 16:53 ` Gregory Maxwell
1 sibling, 3 replies; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-29 10:43 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1.1: Type: text/plain, Size: 8064 bytes --]
> On Jul 29, 2015, at 2:59 AM, Mike Hearn <hearn@vinumeris•com> wrote:
>
> 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.
>
> 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?
>
> 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.
> 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.
>
> Now on to your claims:
>
> 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>)
>
> 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.
> 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.
> The only purposes non-mining, non-rpc-serving, non-Qt-wallet-sustaining full nodes are needed for with today's network are:
> 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.
>
>
> 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.
>
> 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.
>
> 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?
[-- Attachment #1.2: Type: text/html, Size: 13217 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 10:43 ` Eric Lombrozo
@ 2015-07-29 11:15 ` Mike Hearn
2015-07-29 12:03 ` Eric Lombrozo
` (2 more replies)
2015-07-29 11:29 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Thomas Zander
2015-07-29 18:00 ` Jorge Timón
2 siblings, 3 replies; 69+ messages in thread
From: Mike Hearn @ 2015-07-29 11:15 UTC (permalink / raw)
To: Eric Lombrozo; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 6810 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 9422 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 2:40 ` Eric Lombrozo
2015-07-29 3:37 ` Eric Lombrozo
@ 2015-07-29 11:18 ` Thomas Zander
1 sibling, 0 replies; 69+ messages in thread
From: Thomas Zander @ 2015-07-29 11:18 UTC (permalink / raw)
To: bitcoin-dev
On Tuesday 28. July 2015 19.40.21 Eric Lombrozo via bitcoin-dev wrote:
> 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.
--
Thomas Zander
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 10:43 ` Eric Lombrozo
2015-07-29 11:15 ` Mike Hearn
@ 2015-07-29 11:29 ` Thomas Zander
2015-07-29 18:00 ` Jorge Timón
2 siblings, 0 replies; 69+ messages in thread
From: Thomas Zander @ 2015-07-29 11:29 UTC (permalink / raw)
To: bitcoin-dev
On Wednesday 29. July 2015 03.43.50 Eric Lombrozo via bitcoin-dev wrote:
> > > 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.
> > 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...
--
Thomas Zander
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 11:15 ` Mike Hearn
@ 2015-07-29 12:03 ` Eric Lombrozo
2015-07-29 12:13 ` Thomas Zander
2015-07-29 17:17 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Raystonn .
2015-07-29 19:56 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Owen
2 siblings, 1 reply; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-29 12:03 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1.1: Type: text/plain, Size: 8920 bytes --]
> On Jul 29, 2015, at 4:15 AM, Mike Hearn <hearn@vinumeris•com> wrote:
>
> 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.
> 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>)
>
> Maybe when there is a need? I already discussed this topic of need here:
>
> https://medium.com/@octskyward/hashing-7d04a887acc8 <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 <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.
>
[-- Attachment #1.2: Type: text/html, Size: 13175 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 12:03 ` Eric Lombrozo
@ 2015-07-29 12:13 ` Thomas Zander
0 siblings, 0 replies; 69+ messages in thread
From: Thomas Zander @ 2015-07-29 12:13 UTC (permalink / raw)
To: bitcoin-dev
On Wednesday 29. July 2015 05.03.45 Eric Lombrozo via bitcoin-dev wrote:
> 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?
--
Thomas Zander
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 9:59 ` Mike Hearn
2015-07-29 10:43 ` Eric Lombrozo
@ 2015-07-29 16:53 ` Gregory Maxwell
2015-07-29 17:30 ` Sriram Karra
2015-07-29 18:03 ` Mike Hearn
1 sibling, 2 replies; 69+ messages in thread
From: Gregory Maxwell @ 2015-07-29 16:53 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
On Wed, Jul 29, 2015 at 9:59 AM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.
> 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.
> 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:
[...]
> 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.)
> 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.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-29 11:15 ` Mike Hearn
2015-07-29 12:03 ` Eric Lombrozo
@ 2015-07-29 17:17 ` Raystonn .
2015-07-29 19:56 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Owen
2 siblings, 0 replies; 69+ messages in thread
From: Raystonn . @ 2015-07-29 17:17 UTC (permalink / raw)
To: Mike Hearn, Eric Lombrozo; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 7263 bytes --]
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.
--------------------------------------------------------------------------------
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 11505 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 16:53 ` Gregory Maxwell
@ 2015-07-29 17:30 ` Sriram Karra
2015-07-29 18:03 ` Mike Hearn
1 sibling, 0 replies; 69+ messages in thread
From: Sriram Karra @ 2015-07-29 17:30 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
On Wed, Jul 29, 2015 at 10:23 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
On Wed, Jul 29, 2015 at 9:59 AM, 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?
[-- Attachment #2: Type: text/html, Size: 1029 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 10:43 ` Eric Lombrozo
2015-07-29 11:15 ` Mike Hearn
2015-07-29 11:29 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Thomas Zander
@ 2015-07-29 18:00 ` Jorge Timón
2015-07-30 7:08 ` Thomas Zander
2 siblings, 1 reply; 69+ messages in thread
From: Jorge Timón @ 2015-07-29 18:00 UTC (permalink / raw)
To: Eric Lombrozo; +Cc: Bitcoin Dev
On Wed, Jul 29, 2015 at 12:43 PM, Eric Lombrozo via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 16:53 ` Gregory Maxwell
2015-07-29 17:30 ` Sriram Karra
@ 2015-07-29 18:03 ` Mike Hearn
2015-07-29 19:53 ` Gregory Maxwell
2015-07-30 9:05 ` odinn
1 sibling, 2 replies; 69+ messages in thread
From: Mike Hearn @ 2015-07-29 18:03 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3686 bytes --]
>
> 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
> Gavin years long campaign to ignore problems in the mining ecosystem:
>
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.
[-- Attachment #2: Type: text/html, Size: 5484 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 18:03 ` Mike Hearn
@ 2015-07-29 19:53 ` Gregory Maxwell
2015-07-30 14:15 ` Thomas Zander
2015-07-30 9:05 ` odinn
1 sibling, 1 reply; 69+ messages in thread
From: Gregory Maxwell @ 2015-07-29 19:53 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
On Wed, Jul 29, 2015 at 6:03 PM, Mike Hearn <hearn@vinumeris•com> wrote:
>> 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:
[...]
> 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.)
> Since when have we "campaigned" to "ignore problems" in the mining
> ecosystem?
[...]
> 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.
> 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.
> 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.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 11:15 ` Mike Hearn
2015-07-29 12:03 ` Eric Lombrozo
2015-07-29 17:17 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Raystonn .
@ 2015-07-29 19:56 ` Owen
2015-07-29 20:09 ` Gregory Maxwell
2015-07-29 20:23 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measureisn't temporary Raystonn .
2 siblings, 2 replies; 69+ messages in thread
From: Owen @ 2015-07-29 19:56 UTC (permalink / raw)
To: Bitcoin Dev
On July 29, 2015 7:15:49 AM EDT, 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.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 19:56 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Owen
@ 2015-07-29 20:09 ` Gregory Maxwell
2015-07-29 21:28 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Raystonn .
2015-07-29 20:23 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measureisn't temporary Raystonn .
1 sibling, 1 reply; 69+ messages in thread
From: Gregory Maxwell @ 2015-07-29 20:09 UTC (permalink / raw)
To: Owen; +Cc: Bitcoin Dev
On Wed, Jul 29, 2015 at 7:56 PM, Owen via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On July 29, 2015 7:15:49 AM EDT, 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.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measureisn't temporary
2015-07-29 19:56 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Owen
2015-07-29 20:09 ` Gregory Maxwell
@ 2015-07-29 20:23 ` Raystonn .
1 sibling, 0 replies; 69+ messages in thread
From: Raystonn . @ 2015-07-29 20:23 UTC (permalink / raw)
To: Owen, 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
On July 29, 2015 7:15:49 AM EDT, 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.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-29 20:09 ` Gregory Maxwell
@ 2015-07-29 21:28 ` Raystonn .
2015-07-29 22:11 ` Venzen Khaosan
2015-07-30 9:44 ` odinn
0 siblings, 2 replies; 69+ messages in thread
From: Raystonn . @ 2015-07-29 21:28 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: 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
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On July 29, 2015 7:15:49 AM EDT, 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.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-29 21:28 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Raystonn .
@ 2015-07-29 22:11 ` Venzen Khaosan
2015-07-29 23:10 ` Raystonn .
2015-07-30 9:44 ` odinn
1 sibling, 1 reply; 69+ messages in thread
From: Venzen Khaosan @ 2015-07-29 22:11 UTC (permalink / raw)
To: Raystonn .; +Cc: bitcoin-dev
-----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]
> 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?
-----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-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-29 22:11 ` Venzen Khaosan
@ 2015-07-29 23:10 ` Raystonn .
2015-07-30 3:49 ` Adam Back
0 siblings, 1 reply; 69+ messages in thread
From: Raystonn . @ 2015-07-29 23:10 UTC (permalink / raw)
To: venzen; +Cc: 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.
> ... 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-dev@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]
> 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?
-----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-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-29 23:10 ` Raystonn .
@ 2015-07-30 3:49 ` Adam Back
2015-07-30 4:51 ` Andrew LeCody
2015-07-30 9:16 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Venzen Khaosan
0 siblings, 2 replies; 69+ messages in thread
From: Adam Back @ 2015-07-30 3:49 UTC (permalink / raw)
To: Raystonn .; +Cc: 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
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>> 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.
>
>> ... 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-dev@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]
>>
>> 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?
> -----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
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 3:49 ` Adam Back
@ 2015-07-30 4:51 ` Andrew LeCody
2015-07-30 8:21 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-30 9:16 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Venzen Khaosan
1 sibling, 1 reply; 69+ messages in thread
From: Andrew LeCody @ 2015-07-30 4:51 UTC (permalink / raw)
To: Adam Back, Raystonn .; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 12408 bytes --]
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 <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >> 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.
> >
> >> ... 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-dev@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]
> >>
> >> 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?
> > -----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
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 15008 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 18:00 ` Jorge Timón
@ 2015-07-30 7:08 ` Thomas Zander
0 siblings, 0 replies; 69+ messages in thread
From: Thomas Zander @ 2015-07-30 7:08 UTC (permalink / raw)
To: bitcoin-dev
On Wednesday 29. July 2015 20.00.10 Jorge Timón via bitcoin-dev wrote:
> 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.
--
Thomas Zander
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-30 4:51 ` Andrew LeCody
@ 2015-07-30 8:21 ` Eric Lombrozo
2015-07-30 9:15 ` Eric Lombrozo
2015-07-30 12:29 ` Gavin
0 siblings, 2 replies; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-30 8:21 UTC (permalink / raw)
To: Andrew LeCody; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 15155 bytes --]
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.
> On Jul 29, 2015, at 9:51 PM, Andrew LeCody via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> 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 <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> 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
>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>> 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.
>>>
>>>> ... 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-dev@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]
>>>>
>>>> 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?
>>> -----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
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 18:03 ` Mike Hearn
2015-07-29 19:53 ` Gregory Maxwell
@ 2015-07-30 9:05 ` odinn
1 sibling, 0 replies; 69+ messages in thread
From: odinn @ 2015-07-30 9:05 UTC (permalink / raw)
To: Mike Hearn, Gregory Maxwell; +Cc: Bitcoin Dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike, tone it down, please, when I read your stuff it's like you are
drinking too much Red bull or something.
On 07/29/2015 11:03 AM, Mike Hearn via bitcoin-dev wrote:
> 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 Gavin years long campaign to ignore problems in the mining
> ecosystem:
>
>
> 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
> list bitcoin-dev@lists•linuxfoundation.org
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVuejTAAoJEGxwq/inSG8CKigH+gJpevuZ/mbCy9cjhLvX6VT/
NBQjU82EPDkMkASqoQOekIBOrgODBcN8HsR1xnPHYZYh9HmMaQ/kZDZI3EUP76CU
s1vvL0AQC11b0aai+z1K5XU6xK+HxRewujBj9lKtH/JuRUHoKUrRIn/5KxT6Nb5+
OXCpoXKnynfu7T57RrVBOKCPW0Oo7jay9owjDzy+J/ATfqqPDB++7nDbPPVzyrNs
6TlHaC/CxRcq832lwBe1KwaX4A7KFiqHwWoK5/R7Ccyj5X21nHXnDOuXLqwOfGtH
1aARAQ6dqHor5Kw9/Y7yAdoNnrK3XYR80Qdr6I77f3X2B40GdnBiBOSUpoQNAB0=
=nRef
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-30 8:21 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
@ 2015-07-30 9:15 ` Eric Lombrozo
2015-07-30 12:29 ` Gavin
1 sibling, 0 replies; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-30 9:15 UTC (permalink / raw)
To: Andrew LeCody; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 16155 bytes --]
> On Jul 30, 2015, at 1:21 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
> 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.
>
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
>> On Jul 29, 2015, at 9:51 PM, Andrew LeCody via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> 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 <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>> 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
>>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>> 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.
>>>>
>>>>> ... 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-dev@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]
>>>>>
>>>>> 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?
>>>> -----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
>>>> bitcoin-dev@lists•linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 3:49 ` Adam Back
2015-07-30 4:51 ` Andrew LeCody
@ 2015-07-30 9:16 ` Venzen Khaosan
2015-07-30 9:38 ` Jorge Timón
1 sibling, 1 reply; 69+ messages in thread
From: Venzen Khaosan @ 2015-07-30 9:16 UTC (permalink / raw)
To: Adam Back; +Cc: 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
On 07/30/2015 10:49 AM, Adam Back wrote:
> 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
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>> 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.
>>
>>> ... 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-dev@lists•linuxfoundation.org Subject: Re: [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
> 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?
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev@lists•linuxfoundation.org
>> 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-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 9:16 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Venzen Khaosan
@ 2015-07-30 9:38 ` Jorge Timón
2015-07-30 13:33 ` Venzen Khaosan
2015-07-30 14:52 ` Thomas Zander
0 siblings, 2 replies; 69+ messages in thread
From: Jorge Timón @ 2015-07-30 9:38 UTC (permalink / raw)
To: venzen; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 11099 bytes --]
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" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> -----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
>
>
>
> On 07/30/2015 10:49 AM, Adam Back wrote:
> > 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
> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >>> 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.
> >>
> >>> ... 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-dev@lists•linuxfoundation.org Subject: Re: [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
> > 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?
> >> _______________________________________________ bitcoin-dev
> >> mailing list bitcoin-dev@lists•linuxfoundation.org
> >> 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
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 13269 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-29 21:28 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Raystonn .
2015-07-29 22:11 ` Venzen Khaosan
@ 2015-07-30 9:44 ` odinn
1 sibling, 0 replies; 69+ messages in thread
From: odinn @ 2015-07-30 9:44 UTC (permalink / raw)
To: Raystonn ., Gregory Maxwell; +Cc: Bitcoin Dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I will jump in just because I feel like it because the questions are
fun and so on. (Of course I am not Gregory)
On 07/29/2015 02:28 PM, Raystonn . via bitcoin-dev wrote:
> 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...
> 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.
>
> 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.
>
> 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.
>
> 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
then:
> 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.
> 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.
> 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
>
>
> -----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
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> On July 29, 2015 7:15:49 AM EDT, 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. _______________________________________________
> bitcoin-dev mailing list bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation.org
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVufH2AAoJEGxwq/inSG8C1mgH/3poEpk8pDDgZ7YQlGmAZjiO
MDBempLkfm1BFFoNAzjMn9mwtmL9wDfpn/sd/YbuIriJjQR2WSl6zy/sLx/uIYxd
qRuSRwOzN6wN7NfAuG7Lt3NtawOjAgl87n5YhRVB/d/MAK5HAvx3L9ME1Px//qsF
Czg5r0XG4ZiQnT8J30caMtooSVU9toradAmMleVbMVOi9KViyuW2IvXz5mM1jYHh
h+CB+CVHlhuKubXWpnnxYtOLLRQM5QSyfQiMPimVG0QPSOC5UkXJNo5gK6YMtBkT
0FevJyoMF+0LVTTPVGms+jolxu2PX3RW59nhNKEAuxOWfeHdMFFGtPP04XbpqSo=
=R3aj
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-30 8:21 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-30 9:15 ` Eric Lombrozo
@ 2015-07-30 12:29 ` Gavin
2015-07-30 12:50 ` Pieter Wuille
2015-07-30 23:33 ` Eric Lombrozo
1 sibling, 2 replies; 69+ messages in thread
From: Gavin @ 2015-07-30 12:29 UTC (permalink / raw)
To: Eric Lombrozo; +Cc: Bitcoin Dev
> On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote:
>
> 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.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-30 12:29 ` Gavin
@ 2015-07-30 12:50 ` Pieter Wuille
2015-07-30 14:03 ` Thomas Zander
2015-07-30 14:05 ` Gavin Andresen
2015-07-30 23:33 ` Eric Lombrozo
1 sibling, 2 replies; 69+ messages in thread
From: Pieter Wuille @ 2015-07-30 12:50 UTC (permalink / raw)
To: Gavin; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]
On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> > On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote:
> >
> > 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.
--
Pieter
[-- Attachment #2: Type: text/html, Size: 3283 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 9:38 ` Jorge Timón
@ 2015-07-30 13:33 ` Venzen Khaosan
2015-07-30 14:10 ` Jorge Timón
2015-07-30 14:52 ` Thomas Zander
1 sibling, 1 reply; 69+ messages in thread
From: Venzen Khaosan @ 2015-07-30 13:33 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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:
http://www.youtube.com/watch?v=jE_elgnIw3M
http://www.youtube.com/watch?v=fBS_ieDwQ9k
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?
On 07/30/2015 04:38 PM, Jorge Timón wrote:
> 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"
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
> 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
>
>
>
> On 07/30/2015 10:49 AM, Adam Back wrote:
>> 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
>> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>>>> 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.
>>>
>>>> ... 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-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org> Subject: Re:
> [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
>> 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?
>>> _______________________________________________ bitcoin-dev
>>> mailing list bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVuieTAAoJEGwAhlQc8H1meAIH/RHUV72bbMItZOT7rvhEU56r
lqEcvwXBSCYgsh1ieVeTdC/ydJnRSzWsdZxM3D7PEOzutlG+VaJQVSJREItGb2GW
PYiZ3uwSwF64nRq5bZ7aS2pT/Zo1a1yAf4H5rbeyxxoWC+zkmSsmcf73MgmslIuU
7XXHNztCX3glfOctr+J61WEKBw0ItQCTsp9J08yVlj/gvKTi3U2jDcYV5mf/3D0j
pvXl244DG4b+nYetRyyonYbZelSUYfCghNBJhUYZApVmcgfKDRPeX1uWfkl0HuUd
Kc+uZtrhJaUXdRlqc50nOsRSCAK+d4PGClF8JFlzI65+SG7VzkVqc8SkSDfNXfY=
=r4SA
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-30 12:50 ` Pieter Wuille
@ 2015-07-30 14:03 ` Thomas Zander
2015-07-30 14:05 ` Gavin Andresen
1 sibling, 0 replies; 69+ messages in thread
From: Thomas Zander @ 2015-07-30 14:03 UTC (permalink / raw)
To: bitcoin-dev
On Thursday 30. July 2015 14.50.46 Pieter Wuille via bitcoin-dev wrote:
> > 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. ;)
> 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.
> 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?
--
Thomas Zander
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-30 12:50 ` Pieter Wuille
2015-07-30 14:03 ` Thomas Zander
@ 2015-07-30 14:05 ` Gavin Andresen
2015-07-30 14:28 ` Pieter Wuille
2015-07-30 15:36 ` Jorge Timón
1 sibling, 2 replies; 69+ messages in thread
From: Gavin Andresen @ 2015-07-30 14:05 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille <pieter.wuille@gmail•com>
wrote:
> 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.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 2030 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 13:33 ` Venzen Khaosan
@ 2015-07-30 14:10 ` Jorge Timón
0 siblings, 0 replies; 69+ messages in thread
From: Jorge Timón @ 2015-07-30 14:10 UTC (permalink / raw)
To: venzen; +Cc: Bitcoin Dev
On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.
> 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
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.
> 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.
On Thu, Jul 30, 2015 at 3:33 PM, Venzen Khaosan <venzen@mail•bihthai.net> wrote:
> 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).
> 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?
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.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 19:53 ` Gregory Maxwell
@ 2015-07-30 14:15 ` Thomas Zander
0 siblings, 0 replies; 69+ messages in thread
From: Thomas Zander @ 2015-07-30 14:15 UTC (permalink / raw)
To: 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...
On Wednesday 29. July 2015 19.53.02 Gregory Maxwell via bitcoin-dev wrote:
> (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.
--
Thomas Zander
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-30 14:05 ` Gavin Andresen
@ 2015-07-30 14:28 ` Pieter Wuille
2015-07-30 15:36 ` Jorge Timón
1 sibling, 0 replies; 69+ messages in thread
From: Pieter Wuille @ 2015-07-30 14:28 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2631 bytes --]
On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen <gavinandresen@gmail•com>
wrote:
> On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille <pieter.wuille@gmail•com>
> wrote:
>
>> 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
> 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?
> 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
> 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
> 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.
> 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.
--
Pieter
[-- Attachment #2: Type: text/html, Size: 4443 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 9:38 ` Jorge Timón
2015-07-30 13:33 ` Venzen Khaosan
@ 2015-07-30 14:52 ` Thomas Zander
2015-07-30 15:24 ` Bryan Bishop
2015-07-30 15:41 ` Jorge Timón
1 sibling, 2 replies; 69+ messages in thread
From: Thomas Zander @ 2015-07-30 14:52 UTC (permalink / raw)
To: bitcoin-dev
On Thursday 30. July 2015 11.38.00 Jorge Timón via bitcoin-dev wrote:
> 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?
--
Thomas Zander
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 14:52 ` Thomas Zander
@ 2015-07-30 15:24 ` Bryan Bishop
2015-07-30 15:55 ` Gavin Andresen
2015-07-30 16:07 ` Thomas Zander
2015-07-30 15:41 ` Jorge Timón
1 sibling, 2 replies; 69+ messages in thread
From: Bryan Bishop @ 2015-07-30 15:24 UTC (permalink / raw)
To: Thomas Zander, bitcoin-dev, Bryan Bishop
[-- Attachment #1: Type: text/plain, Size: 728 bytes --]
On Thu, Jul 30, 2015 at 9:52 AM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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
[-- Attachment #2: Type: text/html, Size: 1209 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-30 14:05 ` Gavin Andresen
2015-07-30 14:28 ` Pieter Wuille
@ 2015-07-30 15:36 ` Jorge Timón
1 sibling, 0 replies; 69+ messages in thread
From: Jorge Timón @ 2015-07-30 15:36 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille <pieter.wuille@gmail•com>
> 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
> 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.
> 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.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 14:52 ` Thomas Zander
2015-07-30 15:24 ` Bryan Bishop
@ 2015-07-30 15:41 ` Jorge Timón
1 sibling, 0 replies; 69+ messages in thread
From: Jorge Timón @ 2015-07-30 15:41 UTC (permalink / raw)
To: Thomas Zander; +Cc: Bitcoin Dev
On Thu, Jul 30, 2015 at 4:52 PM, Thomas Zander via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Thursday 30. July 2015 11.38.00 Jorge Timón via bitcoin-dev wrote:
>> 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.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 15:24 ` Bryan Bishop
@ 2015-07-30 15:55 ` Gavin Andresen
2015-07-30 17:24 ` Thomas Zander
2015-07-31 15:27 ` Bryan Bishop
2015-07-30 16:07 ` Thomas Zander
1 sibling, 2 replies; 69+ messages in thread
From: Gavin Andresen @ 2015-07-30 15:55 UTC (permalink / raw)
To: Bryan Bishop; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]
On Thu, Jul 30, 2015 at 11:24 AM, Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 2906 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 15:24 ` Bryan Bishop
2015-07-30 15:55 ` Gavin Andresen
@ 2015-07-30 16:07 ` Thomas Zander
2015-07-30 17:42 ` Thomas Zander
1 sibling, 1 reply; 69+ messages in thread
From: Thomas Zander @ 2015-07-30 16:07 UTC (permalink / raw)
To: bitcoin-dev
On Thursday 30. July 2015 10.24.07 Bryan Bishop wrote:
> On Thu, Jul 30, 2015 at 9:52 AM, Thomas Zander via bitcoin-dev <
>
> bitcoin-dev@lists•linuxfoundation.org> wrote:
> > 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
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 15:55 ` Gavin Andresen
@ 2015-07-30 17:24 ` Thomas Zander
2015-07-31 15:27 ` Bryan Bishop
1 sibling, 0 replies; 69+ messages in thread
From: Thomas Zander @ 2015-07-30 17:24 UTC (permalink / raw)
To: Bitcoin Dev
On Thursday 30. July 2015 11.55.50 Gavin Andresen wrote:
> 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...
--
Thomas Zander
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 16:07 ` Thomas Zander
@ 2015-07-30 17:42 ` Thomas Zander
2015-07-30 18:02 ` Mark Friedenbach
0 siblings, 1 reply; 69+ messages in thread
From: Thomas Zander @ 2015-07-30 17:42 UTC (permalink / raw)
To: bitcoin-dev
On Thursday 30. July 2015 18.07.40 Thomas Zander via bitcoin-dev wrote:
> 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. ;)
--
Thomas Zander
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 17:42 ` Thomas Zander
@ 2015-07-30 18:02 ` Mark Friedenbach
2015-07-31 0:22 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-31 8:06 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Thomas Zander
0 siblings, 2 replies; 69+ messages in thread
From: Mark Friedenbach @ 2015-07-30 18:02 UTC (permalink / raw)
To: Thomas Zander; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]
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 <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Thursday 30. July 2015 18.07.40 Thomas Zander via bitcoin-dev wrote:
> > 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. ;)
>
> --
> Thomas Zander
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2680 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-30 12:29 ` Gavin
2015-07-30 12:50 ` Pieter Wuille
@ 2015-07-30 23:33 ` Eric Lombrozo
2015-07-31 0:15 ` Milly Bitcoin
2015-07-31 6:42 ` Thomas Zander
1 sibling, 2 replies; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-30 23:33 UTC (permalink / raw)
To: Gavin; +Cc: Bitcoin Dev
[-- Attachment #1.1: Type: text/plain, Size: 803 bytes --]
> On Jul 30, 2015, at 5:29 AM, Gavin <gavinandresen@gmail•com> wrote:
>
> 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
[-- Attachment #1.2: Type: text/html, Size: 1665 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-30 23:33 ` Eric Lombrozo
@ 2015-07-31 0:15 ` Milly Bitcoin
2015-07-31 21:30 ` Jorge Timón
2015-07-31 6:42 ` Thomas Zander
1 sibling, 1 reply; 69+ messages in thread
From: Milly Bitcoin @ 2015-07-31 0:15 UTC (permalink / raw)
To: 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
On 7/30/2015 7:33 PM, Eric Lombrozo via bitcoin-dev wrote:
>
>> On Jul 30, 2015, at 5:29 AM, Gavin <gavinandresen@gmail•com
>> <mailto:gavinandresen@gmail•com>> wrote:
>>
>> 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
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-30 18:02 ` Mark Friedenbach
@ 2015-07-31 0:22 ` Eric Lombrozo
2015-07-31 8:06 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Thomas Zander
1 sibling, 0 replies; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-31 0:22 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: Bitcoin Dev
[-- Attachment #1.1: Type: text/plain, Size: 505 bytes --]
> On Jul 30, 2015, at 11:02 AM, Mark Friedenbach via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> 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.
[-- Attachment #1.2: Type: text/html, Size: 1381 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-30 23:33 ` Eric Lombrozo
2015-07-31 0:15 ` Milly Bitcoin
@ 2015-07-31 6:42 ` Thomas Zander
2015-07-31 20:45 ` Eric Lombrozo
1 sibling, 1 reply; 69+ messages in thread
From: Thomas Zander @ 2015-07-31 6:42 UTC (permalink / raw)
To: bitcoin-dev
On Thursday 30. July 2015 16.33.16 Eric Lombrozo via bitcoin-dev wrote:
> 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
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 18:02 ` Mark Friedenbach
2015-07-31 0:22 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
@ 2015-07-31 8:06 ` Thomas Zander
1 sibling, 0 replies; 69+ messages in thread
From: Thomas Zander @ 2015-07-31 8:06 UTC (permalink / raw)
To: Bitcoin Dev
On Thursday 30. July 2015 11.02.43 Mark Friedenbach wrote:
> 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.
--
Thomas Zander
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary
2015-07-30 15:55 ` Gavin Andresen
2015-07-30 17:24 ` Thomas Zander
@ 2015-07-31 15:27 ` Bryan Bishop
1 sibling, 0 replies; 69+ messages in thread
From: Bryan Bishop @ 2015-07-31 15:27 UTC (permalink / raw)
To: Gavin Andresen, Bryan Bishop; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]
On Thu, Jul 30, 2015 at 10:55 AM, Gavin Andresen <gavinandresen@gmail•com>
wrote:
> On Thu, Jul 30, 2015 at 11:24 AM, Bryan Bishop via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> 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
[-- Attachment #2: Type: text/html, Size: 2308 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-31 6:42 ` Thomas Zander
@ 2015-07-31 20:45 ` Eric Lombrozo
2015-07-31 20:57 ` Eric Lombrozo
2015-08-01 20:22 ` John T. Winslow
0 siblings, 2 replies; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-31 20:45 UTC (permalink / raw)
To: Thomas Zander; +Cc: Jean-Paul Kogelman via bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]
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" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Thursday 30. July 2015 16.33.16 Eric Lombrozo via bitcoin-dev wrote:
> > 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
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2211 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-31 20:45 ` Eric Lombrozo
@ 2015-07-31 20:57 ` Eric Lombrozo
2015-08-01 20:22 ` John T. Winslow
1 sibling, 0 replies; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-31 20:57 UTC (permalink / raw)
To: Thomas Zander; +Cc: Jean-Paul Kogelman via bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]
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.
On Jul 31, 2015 1:45 PM, "Eric Lombrozo" <elombrozo@gmail•com> wrote:
> 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" <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> On Thursday 30. July 2015 16.33.16 Eric Lombrozo via bitcoin-dev wrote:
>> > 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
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
[-- Attachment #2: Type: text/html, Size: 2881 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-31 0:15 ` Milly Bitcoin
@ 2015-07-31 21:30 ` Jorge Timón
2015-07-31 21:43 ` Eric Lombrozo
0 siblings, 1 reply; 69+ messages in thread
From: Jorge Timón @ 2015-07-31 21:30 UTC (permalink / raw)
To: Milly Bitcoin; +Cc: Bitcoin Dev
On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.
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.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-31 21:30 ` Jorge Timón
@ 2015-07-31 21:43 ` Eric Lombrozo
0 siblings, 0 replies; 69+ messages in thread
From: Eric Lombrozo @ 2015-07-31 21:43 UTC (permalink / raw)
To: Jorge Timón; +Cc: Jean-Paul Kogelman via bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]
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" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > 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.
>
> 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
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3265 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-31 20:45 ` Eric Lombrozo
2015-07-31 20:57 ` Eric Lombrozo
@ 2015-08-01 20:22 ` John T. Winslow
2015-08-01 21:05 ` Pieter Wuille
1 sibling, 1 reply; 69+ messages in thread
From: John T. Winslow @ 2015-08-01 20:22 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 5672 bytes --]
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
On 7/31/2015 1:45 PM, Eric Lombrozo via bitcoin-dev wrote:
>
> 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"
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
> On Thursday 30. July 2015 16.33.16 <tel:2015%2016.33.16> Eric
> Lombrozo via bitcoin-dev wrote:
> > 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
> bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 7966 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-08-01 20:22 ` John T. Winslow
@ 2015-08-01 21:05 ` Pieter Wuille
0 siblings, 0 replies; 69+ messages in thread
From: Pieter Wuille @ 2015-08-01 21:05 UTC (permalink / raw)
To: John T. Winslow; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]
On Sat, Aug 1, 2015 at 10:22 PM, John T. Winslow via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.
> 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.
--
Pieter
[-- Attachment #2: Type: text/html, Size: 3197 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
[not found] <f9e27b28-f967-45f7-bd1b-c427534ade9c@me.com>
@ 2015-07-31 23:05 ` Jean-Paul Kogelman
0 siblings, 0 replies; 69+ messages in thread
From: Jean-Paul Kogelman @ 2015-07-31 23:05 UTC (permalink / raw)
To: Jean-Paul Kogelman via bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3090 bytes --]
Forgot to include the list.
> From: Jean-Paul Kogelman <jeanpaulkogelman@me•com>
> Date: July 31, 2015 at 4:02:20 PM PDT
> To: Jorge Timón <jtimon@jtimon•cc>
> Cc: milly@bitcoins•info
> Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
>
>
> I wrote about this a earlier this month: http://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg00383.html
>
> You basically want 3 things:
>
> - 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
>
>> On Jul 31, 2015, at 02:31 PM, Jorge Timón via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>
>> On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>> 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.
>>
>> 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
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 5636 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-31 1:25 Raystonn
@ 2015-07-31 3:18 ` Milly Bitcoin
0 siblings, 0 replies; 69+ messages in thread
From: Milly Bitcoin @ 2015-07-31 3:18 UTC (permalink / raw)
To: Raystonn; +Cc: 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
On 7/30/2015 9:25 PM, Raystonn wrote:
> 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
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> 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
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
@ 2015-07-31 1:25 Raystonn
2015-07-31 3:18 ` Milly Bitcoin
0 siblings, 1 reply; 69+ messages in thread
From: Raystonn @ 2015-07-31 1:25 UTC (permalink / raw)
To: Milly Bitcoin; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/html, Size: 3373 bytes --]
^ permalink raw reply [flat|nested] 69+ messages in thread
end of thread, other threads:[~2015-08-01 21:05 UTC | newest]
Thread overview: 69+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-28 22:25 [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-29 0:43 ` Jean-Paul Kogelman
2015-07-29 0:44 ` Eric Lombrozo
2015-07-29 0:46 ` Mark Friedenbach
2015-07-29 0:55 ` Eric Lombrozo
2015-07-29 2:40 ` Eric Lombrozo
2015-07-29 3:37 ` Eric Lombrozo
2015-07-29 3:46 ` Milly Bitcoin
2015-07-29 5:17 ` Eric Lombrozo
2015-07-29 11:18 ` Thomas Zander
2015-07-29 9:59 ` Mike Hearn
2015-07-29 10:43 ` Eric Lombrozo
2015-07-29 11:15 ` Mike Hearn
2015-07-29 12:03 ` Eric Lombrozo
2015-07-29 12:13 ` Thomas Zander
2015-07-29 17:17 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Raystonn .
2015-07-29 19:56 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Owen
2015-07-29 20:09 ` Gregory Maxwell
2015-07-29 21:28 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Raystonn .
2015-07-29 22:11 ` Venzen Khaosan
2015-07-29 23:10 ` Raystonn .
2015-07-30 3:49 ` Adam Back
2015-07-30 4:51 ` Andrew LeCody
2015-07-30 8:21 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-30 9:15 ` Eric Lombrozo
2015-07-30 12:29 ` Gavin
2015-07-30 12:50 ` Pieter Wuille
2015-07-30 14:03 ` Thomas Zander
2015-07-30 14:05 ` Gavin Andresen
2015-07-30 14:28 ` Pieter Wuille
2015-07-30 15:36 ` Jorge Timón
2015-07-30 23:33 ` Eric Lombrozo
2015-07-31 0:15 ` Milly Bitcoin
2015-07-31 21:30 ` Jorge Timón
2015-07-31 21:43 ` Eric Lombrozo
2015-07-31 6:42 ` Thomas Zander
2015-07-31 20:45 ` Eric Lombrozo
2015-07-31 20:57 ` Eric Lombrozo
2015-08-01 20:22 ` John T. Winslow
2015-08-01 21:05 ` Pieter Wuille
2015-07-30 9:16 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Venzen Khaosan
2015-07-30 9:38 ` Jorge Timón
2015-07-30 13:33 ` Venzen Khaosan
2015-07-30 14:10 ` Jorge Timón
2015-07-30 14:52 ` Thomas Zander
2015-07-30 15:24 ` Bryan Bishop
2015-07-30 15:55 ` Gavin Andresen
2015-07-30 17:24 ` Thomas Zander
2015-07-31 15:27 ` Bryan Bishop
2015-07-30 16:07 ` Thomas Zander
2015-07-30 17:42 ` Thomas Zander
2015-07-30 18:02 ` Mark Friedenbach
2015-07-31 0:22 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-31 8:06 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Thomas Zander
2015-07-30 15:41 ` Jorge Timón
2015-07-30 9:44 ` odinn
2015-07-29 20:23 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measureisn't temporary Raystonn .
2015-07-29 11:29 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Thomas Zander
2015-07-29 18:00 ` Jorge Timón
2015-07-30 7:08 ` Thomas Zander
2015-07-29 16:53 ` Gregory Maxwell
2015-07-29 17:30 ` Sriram Karra
2015-07-29 18:03 ` Mike Hearn
2015-07-29 19:53 ` Gregory Maxwell
2015-07-30 14:15 ` Thomas Zander
2015-07-30 9:05 ` odinn
2015-07-31 1:25 Raystonn
2015-07-31 3:18 ` Milly Bitcoin
[not found] <f9e27b28-f967-45f7-bd1b-c427534ade9c@me.com>
2015-07-31 23:05 ` Jean-Paul Kogelman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox