* [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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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
0 siblings, 0 replies; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ messages in thread
* Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
2015-07-29 19:56 ` 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 .
0 siblings, 1 reply; 47+ 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] 47+ 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 19:56 ` Owen
2015-07-29 20:09 ` Gregory Maxwell
1 sibling, 1 reply; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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
2015-07-30 7:08 ` Thomas Zander
2 siblings, 1 reply; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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 19:56 ` Owen
1 sibling, 1 reply; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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
2015-07-29 19:56 ` Owen
2015-07-29 11:29 ` Thomas Zander
2015-07-29 18:00 ` Jorge Timón
2 siblings, 2 replies; 47+ 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] 47+ 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; 47+ 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] 47+ messages in thread
* Re: [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
2015-07-29 10:43 ` Eric Lombrozo
2015-07-29 16:53 ` Gregory Maxwell
2015-07-30 15:24 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Bryan Bishop
2 siblings, 2 replies; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ 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; 47+ 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] 47+ messages in thread
* Re: [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 0:44 ` Eric Lombrozo
2015-07-29 0:46 ` Mark Friedenbach
2015-07-29 9:59 ` Mike Hearn
2015-07-30 15:24 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Bryan Bishop
2 siblings, 2 replies; 47+ 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] 47+ messages in thread
* [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
` (2 more replies)
0 siblings, 3 replies; 47+ 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] 47+ messages in thread
end of thread, other threads:[~2015-08-01 21:05 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <f9e27b28-f967-45f7-bd1b-c427534ade9c@me.com>
2015-07-31 23:05 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Jean-Paul Kogelman
2015-07-31 1:25 Raystonn
2015-07-31 3:18 ` Milly Bitcoin
-- strict thread matches above, loose matches on Subject: below --
2015-07-28 22:25 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 19:56 ` 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-29 11:29 ` 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-30 15:24 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox