[bitcoin-dev] Scaling Bitcoin conference micro-report

[bitcoin-dev] Scaling Bitcoin conference micro-report

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]

During Scaling Bitcoin, Bitcoin Core committers and notable contributors
got together and chatted about where a "greatest common denominator" type
consensus might be.  The following is a without-attribution (Chatham House)
summary.  This is my own personal summary of the chat; any errors are my
own; this is _not_ a consensus statement or anything formal.

- Background (pre-conference, was on public IRC): "net-utxo", calculating
transaction size within block by applying a delta to transaction size based
on the amount of data added, or removed, from the UTXO set.  Fee is then
evaluated after the delta is applied.  This aligns user incentives with
UTXO resource usage/cost.  Original idea by gmaxwell (and others??).

- Many interested or at least willing to accept a "short term bump", a hard
fork to modify block size limit regime to be cost-based via "net-utxo"
rather than a simple static hard limit.  2-4-8 and 17%/year were debated
and seemed "in range" with what might work as a short term bump - net after
applying the new cost metric.

- Hard fork method:  Leaning towards "if (timestamp > X)" flag day hard
fork Y months in the future.  Set high bit in version, resulting in a
negative number, to more cleanly fork away.  "miner advisement" - miners,
as they've done recently, signal non-binding (Bitcoin Core does not examine
the value) engineering readiness for a hard fork via coinbase moniker.
Some fork cancellation method is useful, if unsuccessful after Z time
elapses.

- As discussed publicly elsewhere, other forks may be signaled via setting
a bit in version, and then triggering a fork'ing change once a threshold is
reached.

Chat participants are invited to reply to this message with their own
corrections and comments and summary in their view.

For the wider community, take this as one of many "inputs" described at
Scaling Bitcoin.  Over the next few months developers and the community
should evaluate everything discussed and work towards some concrete
proposal(s) that are implemented, tested and simulated in December in Hong
Kong.

[-- Attachment #2: Type: text/html, Size: 2724 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Matt Corallo]

I only have one "correction", included inline.

On 09/16/15 21:32, Jeff Garzik via bitcoin-dev wrote:
> 
> During Scaling Bitcoin, Bitcoin Core committers and notable contributors
> got together and chatted about where a "greatest common denominator"
> type consensus might be.  The following is a without-attribution
> (Chatham House) summary.  This is my own personal summary of the chat;
> any errors are my own; this is _not_ a consensus statement or anything
> formal.
> 
> - Background (pre-conference, was on public IRC): "net-utxo",
> calculating transaction size within block by applying a delta to
> transaction size based on the amount of data added, or removed, from the
> UTXO set.  Fee is then evaluated after the delta is applied.  This
> aligns user incentives with UTXO resource usage/cost.  Original idea by
> gmaxwell (and others??).
> 
> - Many interested or at least willing to accept a "short term bump", a
> hard fork to modify block size limit regime to be cost-based via
> "net-utxo" rather than a simple static hard limit.  2-4-8 and 17%/year
> were debated and seemed "in range" with what might work as a short term
> bump - net after applying the new cost metric.

I would be careful to point out that hard numbers were deliberately NOT
discussed. Though some general things were thrown out, they were not
extensively discussed nor agreed to. I personally think 2-4 is "in
range", though 8 maybe not so much. Of course it depends on exactly how
the non-blocksize limit accounting/adjusting is done.

Still, the "greatest common denominator" agreement did not seem to be
agreeing to an increase which continues over time, but which instead
limits itself to a set, smooth increase for X time and then requires a
second hardfork if there is agreement on a need for more blocksize at
that point.


> - Hard fork method:  Leaning towards "if (timestamp > X)" flag day hard
> fork Y months in the future.  Set high bit in version, resulting in a
> negative number, to more cleanly fork away.  "miner advisement" -
> miners, as they've done recently, signal non-binding (Bitcoin Core does
> not examine the value) engineering readiness for a hard fork via
> coinbase moniker.  Some fork cancellation method is useful, if
> unsuccessful after Z time elapses.
> 
> - As discussed publicly elsewhere, other forks may be signaled via
> setting a bit in version, and then triggering a fork'ing change once a
> threshold is reached.
> 
> Chat participants are invited to reply to this message with their own
> corrections and comments and summary in their view.
> 
> For the wider community, take this as one of many "inputs" described at
> Scaling Bitcoin.  Over the next few months developers and the community
> should evaluate everything discussed and work towards some concrete
> proposal(s) that are implemented, tested and simulated in December in
> Hong Kong.

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]

Correction of a correction, in-line:

On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > - Many interested or at least willing to accept a "short term bump", a
> > hard fork to modify block size limit regime to be cost-based via
> > "net-utxo" rather than a simple static hard limit.  2-4-8 and 17%/year
> > were debated and seemed "in range" with what might work as a short term
> > bump - net after applying the new cost metric.
>
> I would be careful to point out that hard numbers were deliberately NOT
> discussed. Though some general things were thrown out, they were not
> extensively discussed nor agreed to. I personally think 2-4 is "in
> range", though 8 maybe not so much. Of course it depends on exactly how
> the non-blocksize limit accounting/adjusting is done.
>
> Still, the "greatest common denominator" agreement did not seem to be
> agreeing to an increase which continues over time, but which instead
> limits itself to a set, smooth increase for X time and then requires a
> second hardfork if there is agreement on a need for more blocksize at
> that point.
>

Perhaps it is accurate to say that there wasn't consensus at all except
that (1) we think we can work together on resolving this impasse (yay!),
and (2) it is conceivable that changing from block size to some other
metric might provide the basis for a compromise on near-term numbers.

As an example, I do not think the net-UTXO metric provides any benefit with
respect to scalability, and in some ways makes the situation worse (even
though it helpfully solves an unrelated problem of spammy dust outputs).
But there are other possible metrics and I maintain hope that data will
show the benefit of another metric or other metrics combined with net-UTXO
in a way that will allow us to reach consensus.

As a further example, I also am quite concerned about 2-4-8MB with either
block size or net-UTXO as the base metric. As you say, it depends on how
the non-blocksize limit accounting/adjusting is done... But if a metric
were chosen that addressed my concerns (worst case propagation and
validation time), then I could be in favor of an initial bump that allowed
a larger number of typical transactions in a block.

But where I really need to disagree is on the requirement for a 2nd hard
fork. I will go on record as being definitively against this. While being
conservative with respect to exponentials, I would very much like to make
sure that there is a long-term growth curve as part of any proposal. I am
willing to accept a hard-fork if the adopted plan is too conservative, but
I do not want to be kicking the can down the road to a scheduled 2nd hard
fork that absolutely must occur. That, I feel, could be a more dangerous
outcome than an exponential that outlasts conservative historical trends.

I commend Jeff for writing a Chatham-rules summary of the outcome of some
hallway conversations that occurred. On the whole I think his summary does
represent the majority view of the opinions expressed by core developers at
the workshop. I will caution though that on nearly every issue there were
those expressed disagreement but did not fight the issue, and those who
said nothing and left unpolled opinions. Nevertheless this summary is
informative as it feeds forwards into the design of proposals that will be
made prior to the Hong Kong workshop in December, in order that they have a
higher likelihood of success.

[-- Attachment #2: Type: text/html, Size: 4080 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 5329 bytes --]

"But if a metric were chosen that addressed my concerns (worst case
propagation and validation time), then I could be in favor of an initial
bump that allowed a larger number of typical transactions in a block."

+1.  A ratio is much more valuable than a simple metric.  It seems clearly
difficult to identify a reasonable limit to block size, but the ratio
between any one of several possible metrics and bytes in a block would work
well and may already have a very good reasonable expected range.

I like BTCDaysDestroyed (BTCDD) best.  If it might be time consuming to
compute, then it need only be computed for all blocks less than or equal in
size to the average size of the largest 200 or so blocks in the previous
difficulty period.  To exceed that limit, a miner would have to ensure that
the block has enough BTCDD per byte.  "Enough" could be hardcoded in each
release, or if it's simple enough, use the ratio as computed over all the
blocks in the previous difficulty period as the lower limit.

notplato

On Thu, Sep 17, 2015 at 10:55 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Correction of a correction, in-line:
>
> On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> > - Many interested or at least willing to accept a "short term bump", a
>> > hard fork to modify block size limit regime to be cost-based via
>> > "net-utxo" rather than a simple static hard limit.  2-4-8 and 17%/year
>> > were debated and seemed "in range" with what might work as a short term
>> > bump - net after applying the new cost metric.
>>
>> I would be careful to point out that hard numbers were deliberately NOT
>> discussed. Though some general things were thrown out, they were not
>> extensively discussed nor agreed to. I personally think 2-4 is "in
>> range", though 8 maybe not so much. Of course it depends on exactly how
>> the non-blocksize limit accounting/adjusting is done.
>>
>> Still, the "greatest common denominator" agreement did not seem to be
>> agreeing to an increase which continues over time, but which instead
>> limits itself to a set, smooth increase for X time and then requires a
>> second hardfork if there is agreement on a need for more blocksize at
>> that point.
>>
>
> Perhaps it is accurate to say that there wasn't consensus at all except
> that (1) we think we can work together on resolving this impasse (yay!),
> and (2) it is conceivable that changing from block size to some other
> metric might provide the basis for a compromise on near-term numbers.
>
> As an example, I do not think the net-UTXO metric provides any benefit
> with respect to scalability, and in some ways makes the situation worse
> (even though it helpfully solves an unrelated problem of spammy dust
> outputs). But there are other possible metrics and I maintain hope that
> data will show the benefit of another metric or other metrics combined with
> net-UTXO in a way that will allow us to reach consensus.
>
> As a further example, I also am quite concerned about 2-4-8MB with either
> block size or net-UTXO as the base metric. As you say, it depends on how
> the non-blocksize limit accounting/adjusting is done... But if a metric
> were chosen that addressed my concerns (worst case propagation and
> validation time), then I could be in favor of an initial bump that allowed
> a larger number of typical transactions in a block.
>
> But where I really need to disagree is on the requirement for a 2nd hard
> fork. I will go on record as being definitively against this. While being
> conservative with respect to exponentials, I would very much like to make
> sure that there is a long-term growth curve as part of any proposal. I am
> willing to accept a hard-fork if the adopted plan is too conservative, but
> I do not want to be kicking the can down the road to a scheduled 2nd hard
> fork that absolutely must occur. That, I feel, could be a more dangerous
> outcome than an exponential that outlasts conservative historical trends.
>
> I commend Jeff for writing a Chatham-rules summary of the outcome of some
> hallway conversations that occurred. On the whole I think his summary does
> represent the majority view of the opinions expressed by core developers at
> the workshop. I will caution though that on nearly every issue there were
> those expressed disagreement but did not fight the issue, and those who
> said nothing and left unpolled opinions. Nevertheless this summary is
> informative as it feeds forwards into the design of proposals that will be
> made prior to the Hong Kong workshop in December, in order that they have a
> higher likelihood of success.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

[-- Attachment #2: Type: text/html, Size: 6605 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 6320 bytes --]

To be quite frank, I'm a little disappointed we've fallen back on arguing over numbers pulled out of a hat rather than discussing far more fundamental issues such as the dev process generally, consensus building, and our basic understanding of what Bitcoin really is, its strengths and weaknesses, where it shows most promise, and communicating a more unified vision to the industry and the public.

On September 18, 2015 10:10:08 AM PDT, Dave Scotese via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>"But if a metric were chosen that addressed my concerns (worst case
>propagation and validation time), then I could be in favor of an
>initial
>bump that allowed a larger number of typical transactions in a block."
>
>+1.  A ratio is much more valuable than a simple metric.  It seems
>clearly
>difficult to identify a reasonable limit to block size, but the ratio
>between any one of several possible metrics and bytes in a block would
>work
>well and may already have a very good reasonable expected range.
>
>I like BTCDaysDestroyed (BTCDD) best.  If it might be time consuming to
>compute, then it need only be computed for all blocks less than or
>equal in
>size to the average size of the largest 200 or so blocks in the
>previous
>difficulty period.  To exceed that limit, a miner would have to ensure
>that
>the block has enough BTCDD per byte.  "Enough" could be hardcoded in
>each
>release, or if it's simple enough, use the ratio as computed over all
>the
>blocks in the previous difficulty period as the lower limit.
>
>notplato
>
>On Thu, Sep 17, 2015 at 10:55 PM, Mark Friedenbach via bitcoin-dev <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Correction of a correction, in-line:
>>
>> On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> > - Many interested or at least willing to accept a "short term
>bump", a
>>> > hard fork to modify block size limit regime to be cost-based via
>>> > "net-utxo" rather than a simple static hard limit.  2-4-8 and
>17%/year
>>> > were debated and seemed "in range" with what might work as a short
>term
>>> > bump - net after applying the new cost metric.
>>>
>>> I would be careful to point out that hard numbers were deliberately
>NOT
>>> discussed. Though some general things were thrown out, they were not
>>> extensively discussed nor agreed to. I personally think 2-4 is "in
>>> range", though 8 maybe not so much. Of course it depends on exactly
>how
>>> the non-blocksize limit accounting/adjusting is done.
>>>
>>> Still, the "greatest common denominator" agreement did not seem to
>be
>>> agreeing to an increase which continues over time, but which instead
>>> limits itself to a set, smooth increase for X time and then requires
>a
>>> second hardfork if there is agreement on a need for more blocksize
>at
>>> that point.
>>>
>>
>> Perhaps it is accurate to say that there wasn't consensus at all
>except
>> that (1) we think we can work together on resolving this impasse
>(yay!),
>> and (2) it is conceivable that changing from block size to some other
>> metric might provide the basis for a compromise on near-term numbers.
>>
>> As an example, I do not think the net-UTXO metric provides any
>benefit
>> with respect to scalability, and in some ways makes the situation
>worse
>> (even though it helpfully solves an unrelated problem of spammy dust
>> outputs). But there are other possible metrics and I maintain hope
>that
>> data will show the benefit of another metric or other metrics
>combined with
>> net-UTXO in a way that will allow us to reach consensus.
>>
>> As a further example, I also am quite concerned about 2-4-8MB with
>either
>> block size or net-UTXO as the base metric. As you say, it depends on
>how
>> the non-blocksize limit accounting/adjusting is done... But if a
>metric
>> were chosen that addressed my concerns (worst case propagation and
>> validation time), then I could be in favor of an initial bump that
>allowed
>> a larger number of typical transactions in a block.
>>
>> But where I really need to disagree is on the requirement for a 2nd
>hard
>> fork. I will go on record as being definitively against this. While
>being
>> conservative with respect to exponentials, I would very much like to
>make
>> sure that there is a long-term growth curve as part of any proposal.
>I am
>> willing to accept a hard-fork if the adopted plan is too
>conservative, but
>> I do not want to be kicking the can down the road to a scheduled 2nd
>hard
>> fork that absolutely must occur. That, I feel, could be a more
>dangerous
>> outcome than an exponential that outlasts conservative historical
>trends.
>>
>> I commend Jeff for writing a Chatham-rules summary of the outcome of
>some
>> hallway conversations that occurred. On the whole I think his summary
>does
>> represent the majority view of the opinions expressed by core
>developers at
>> the workshop. I will caution though that on nearly every issue there
>were
>> those expressed disagreement but did not fight the issue, and those
>who
>> said nothing and left unpolled opinions. Nevertheless this summary is
>> informative as it feeds forwards into the design of proposals that
>will be
>> made prior to the Hong Kong workshop in December, in order that they
>have a
>> higher likelihood of success.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
>-- 
>I like to provide some work at no charge to prove my value. Do you need
>a
>techie?
>I own Litmocracy <http://www.litmocracy.com> and Meme Racing
><http://www.memeracing.net> (in alpha).
>I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
>which
>now accepts Bitcoin.
>I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
>"He ought to find it more profitable to play by the rules" - Satoshi
>Nakamoto
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 6869 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Matt Corallo]

I did not intend to imply that there was agreement on a desire to
schedule a second hardfork. My wording may have been a bit too loose.
Instead, I believe there was much agreement that doing a short-term
hardfork now, with many agreeing that a second would hopefully be
entirely unnecessary/impossible, while others thought that a second
would be necessary and would have to happen. While this may set up a
similar controversy again in several years, I think everyone agreed that
we cannot predict the future and I, personally, think none of us should
be committing to a viewpoint for what should be done at that time.

Personally, I think it is also critical that there be no messaging that
people should rely on or assume there will be a future increase after a
short-term bump (which I also do not believe people should be relying on
now).

Matt

On 09/18/15 05:55, Mark Friedenbach wrote:
> Correction of a correction, in-line:
> 
> On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
>     > - Many interested or at least willing to accept a "short term bump", a
>     > hard fork to modify block size limit regime to be cost-based via
>     > "net-utxo" rather than a simple static hard limit.  2-4-8 and 17%/year
>     > were debated and seemed "in range" with what might work as a short term
>     > bump - net after applying the new cost metric.
> 
>     I would be careful to point out that hard numbers were deliberately NOT
>     discussed. Though some general things were thrown out, they were not
>     extensively discussed nor agreed to. I personally think 2-4 is "in
>     range", though 8 maybe not so much. Of course it depends on exactly how
>     the non-blocksize limit accounting/adjusting is done.
> 
>     Still, the "greatest common denominator" agreement did not seem to be
>     agreeing to an increase which continues over time, but which instead
>     limits itself to a set, smooth increase for X time and then requires a
>     second hardfork if there is agreement on a need for more blocksize at
>     that point.
> 
> 
> Perhaps it is accurate to say that there wasn't consensus at all except
> that (1) we think we can work together on resolving this impasse (yay!),
> and (2) it is conceivable that changing from block size to some other
> metric might provide the basis for a compromise on near-term numbers.
> 
> As an example, I do not think the net-UTXO metric provides any benefit
> with respect to scalability, and in some ways makes the situation worse
> (even though it helpfully solves an unrelated problem of spammy dust
> outputs). But there are other possible metrics and I maintain hope that
> data will show the benefit of another metric or other metrics combined
> with net-UTXO in a way that will allow us to reach consensus.
> 
> As a further example, I also am quite concerned about 2-4-8MB with
> either block size or net-UTXO as the base metric. As you say, it depends
> on how the non-blocksize limit accounting/adjusting is done... But if a
> metric were chosen that addressed my concerns (worst case propagation
> and validation time), then I could be in favor of an initial bump that
> allowed a larger number of typical transactions in a block.
> 
> But where I really need to disagree is on the requirement for a 2nd hard
> fork. I will go on record as being definitively against this. While
> being conservative with respect to exponentials, I would very much like
> to make sure that there is a long-term growth curve as part of any
> proposal. I am willing to accept a hard-fork if the adopted plan is too
> conservative, but I do not want to be kicking the can down the road to a
> scheduled 2nd hard fork that absolutely must occur. That, I feel, could
> be a more dangerous outcome than an exponential that outlasts
> conservative historical trends.
> 
> I commend Jeff for writing a Chatham-rules summary of the outcome of
> some hallway conversations that occurred. On the whole I think his
> summary does represent the majority view of the opinions expressed by
> core developers at the workshop. I will caution though that on nearly
> every issue there were those expressed disagreement but did not fight
> the issue, and those who said nothing and left unpolled opinions.
> Nevertheless this summary is informative as it feeds forwards into the
> design of proposals that will be made prior to the Hong Kong workshop in
> December, in order that they have a higher likelihood of success.

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 97 bytes --]

Any change that results in this happening all over again in a few years
does not have consensus.

[-- Attachment #2: Type: text/html, Size: 118 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[cipher anthem]

[-- Attachment #1: Type: text/html, Size: 1852 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

>
> Let me get this straight. You start this whole debate with a "kick the can
> down the road" proposal to increase the block size to 20MB, which obviously
> would require another hard fork in the future, but if someone else proposes
> a similar "kicka the can" proposal you will outright reject it?
>

Which part of "in the next few years" was unclear?

This seems to be a persistent problem in the block size debates: the
assumption that there are only two numbers, zero and infinity.

BIP101 tops out at 8 gigabyte blocks, which would represent extremely high
transaction rates compared to today. *If* Bitcoin ever became so popular,
it would be a long way in the future, and many things could have happened:

   1. Bitcoin may have become as irrelevant as the Commodore 64 is.
   2. We may have invented upgrades that make Bitcoin 100x more efficient
   than today.
   3. Hardware may have improved so much that it no longer matters.
   4. The world may have been devastated by nuclear war and nobody gives a
   shit about internet currencies anymore, because there is no internet.

It's silly to ignore the time dimension in these decisions. Bitcoin will
not last forever: even if it becomes very successful it will one day it
will be replaced by something better, so it does not have to handle
infinite usage.

But hey, as you bring it up, I'd have been happy with no upper limit at
all. There's nothing magic about 8 gigabytes. I go along with BIP 101
because it is still the only proposal that is both reasonable and
implemented, and I'm willing to compromise.

[-- Attachment #2: Type: text/html, Size: 2024 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 4314 bytes --]

On Fri, Sep 18, 2015 at 08:06:23PM +0000, Matt Corallo via bitcoin-dev wrote:
> I did not intend to imply that there was agreement on a desire to
> schedule a second hardfork. My wording may have been a bit too loose.
> Instead, I believe there was much agreement that doing a short-term
> hardfork now, with many agreeing that a second would hopefully be
> entirely unnecessary/impossible, while others thought that a second
> would be necessary and would have to happen. While this may set up a
> similar controversy again in several years, I think everyone agreed that
> we cannot predict the future and I, personally, think none of us should
> be committing to a viewpoint for what should be done at that time.
> 
> Personally, I think it is also critical that there be no messaging that
> people should rely on or assume there will be a future increase after a
> short-term bump (which I also do not believe people should be relying on
> now).

Agreed!

We still seem to be in a possition where there is fundemental
disagreements about the threat model we should design for, and
ultimately, what we want Bitcoin to be. For instance, yesterday I was on
a blocksize panel, and Valery Vavilov - CEO of the ASIC manufacturer and
miner BitFury - stated that he thought we needed to setup a system of
large, high-bandwidth, high-powered, Bitcoin nodes at institutions such
as universities and large companies to allow the Bitcoin blocksize to be
raised multiple orders of magnitude. (e.g. hundreds of megabytes, or
even multiple gigabytes) In discussion with him he seemed to expect that
we'd have just a few hundred Bitcoin nodes at most, with SPV being the
standard way of using Bitcoin.

While to many of us that sounds crazy, if you're threat model assumes
Bitcoin is a legal/regulated service provided by a highly trusted mining
community it's a reasonable design. Mike Hearn recently posted his
threat model, which specifically argues we should assume governments are
not a threat. (and Hearn has previously argued that the design of
Bitcoin assumes a majority of miners are "honest" rather than merely
economically rational) Similarly Gavin Andresen was also on that panel,
and stated that he believes the idea that Bitcoin has O(n^2) scaling is
wrong, implying he doesn't think a large % of the Bitcoin user base will
continue to run fully validating nodes. (note that there are other
possibilities he could be referring to here, although again with
different security assumptions and/or unproven tech)

The main objection I raised during the committer/contributor discussions
to the idea of a "short term bump" was messaging. I think it's fair to
say that nearly all the support for a small blocksize increase stemmed
from the (perceived) need to give Bitcoin users and Bitcoin
infrastructure some more time to adapt to a world where the blocksize
does not grow sufficiently to meet demand, resulting in higher
transaction fees and the practical requirement to use the Bitcoin
blockchain more efficiently. (or of course the development of genuinely
scalable blockchain technology) With that in mind, it's important that
we properly communicate that fact, or as Hearn replied, we'll run into
the same problem all over again in a few years, but with even less
safety margin in the system.

My second objection was one of science. Any bump should be accompanied
by some kind of model describing scientifically what we were trying to
achieve and where the numbers chosen came from. For instance, Pieter
Wuille's BIP103 proposes 17% per year based on a bandwidth growth model,
the assumption that bandwidth is the bottleneck we're trying to keep
constant, and the design criteria to keep centralization roughly
constant. (all else being equal) Sure there's lots of potential flaws in
that proposal, but the _message_ that we're basing it on science rather
than political "horse-trading" is very important.

As for the disagreements, it's quite likely that we can't come to
genuine consensus in the fact of those fundemental disagreements about
what Bitcoin should be. I don't have any good way to resolve that, and
I'm open to suggestions!

-- 
'peter'[:-1]@petertodd.org
000000000000000000da942d1651d405c157821a3fa55bd0c11cd9b39321e574

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[NxtChg]

>While to many of us that sounds crazy, if you're threat model assumes
>Bitcoin is a legal/regulated service provided by a highly trusted mining
>community it's a reasonable design.

There is a large, grey area all the way to "legal/regulated service provided by a highly trusted mining community".

Painting the worst looking picture is either a defect in thinking or intentional FUD.


> Mike Hearn recently posted his threat model, which specifically argues we
> should assume governments are not a threat.

There are two ways to fight governments:

1. either you become too big to close, so political repercussions become unacceptable

2. or you become too tiny to hunt, in which case you are much better off with a specialized alt-coin, designed specifically for that purpose.

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]

On 09/18/2015 11:06 PM, NxtChg via bitcoin-dev wrote:
>> While to many of us that sounds crazy, if you're threat model assumes
>> Bitcoin is a legal/regulated service provided by a highly trusted
>> mining community it's a reasonable design.
>
> There is a large, grey area all the way to "legal/regulated service
> provided by a highly trusted mining community". Painting the worst
> looking picture is either a defect in thinking or intentional FUD.

The state is the threat in the Bitcoin threat model. You comments below
acknowledge it. The assumption of hostile state actors is the only
rational starting point. That which is regulated (and regulatable) in
Bitcoin is the attack surface.

While of course there are various degrees of weakness, the reference to
"legal/regulated service provided by a highly trusted mining" as the
threat is by no means irrational or misdirecting. This threat represents
the difference between Bitcoin and Fedcoin.

I found Mike's threat model downright disturbing. All benefits of
Bitcoin arise from its resistance to this threat. Anyone investor in
this space should be paying attention... the apparent benefits of
Bitcoin will vaporize with regulation.

>> Mike Hearn recently posted his threat model, which specifically
>> argues we should assume governments are not a threat.
>
> There are two ways to fight governments:
>
> 1. either you become too big to close, so political repercussions
> become unacceptable

This is extremely naive. At a minimum, getting popular/successful (and
regulated) is the formula for regulatory capture.

> 2. or you become too tiny to hunt, in which case you are much better
> off with a specialized alt-coin, designed specifically for that
> purpose.

I assume you are referring some marginal and largely irrelevant effort.

False dichotomy.

[cross-posted to libbitcoin]


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[NxtChg]

>The state is the threat in the Bitcoin threat model. You comments below
>acknowledge it. The assumption of hostile state actors is the only
>rational starting point. That which is regulated (and regulatable) 
>in Bitcoin is the attack surface.

I think, you just proved my point. If your goal is to shrink the attack surface as much as possible,
you are better off being a marginalized alt-coin.


>This threat represents the difference between Bitcoin and Fedcoin.

_This_ is the false dichotomy. There's a range of coins between DarkCoin and FedCoin.


>This is extremely naive. At a minimum, getting popular/successful (and regulated) is the formula for regulatory capture.

Let me give you an example.

Suppose you are a regular guy, say Peter Todd, and you are faced with 10 policemen in anti-riot gear.

You can fight them in two ways:

1. become stronger, so you could provide an adequate response, either by turning into Hulk or by getting another 30-50 Peter Todds.

2. lose some fat, learn a few parkour tricks and move around mostly by night behind dumpsters.

The worst you can fare is just being Peter Todd with a backpack and an expensive camera on his neck, wandering around the city in daylight.


Your vision of Bitcoin is the most vulnerable to government attacks.

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

On 09/19/2015 12:27 AM, NxtChg wrote:
>> This is extremely naive. At a minimum, getting popular/successful (and regulated) is the formula for regulatory capture.
> 
> Let me give you an example.
> 
> Suppose you are a regular guy, say Peter Todd, and you are faced with 10 policemen in anti-riot gear.
> 
> You can fight them in two ways:
> 
> 1. become stronger, so you could provide an adequate response, either by turning into Hulk or by getting another 30-50 Peter Todds.

Your vision of censorship resistance is to become such a strong central
authority that you can resist it in direct physical confrontation. If
you succeed at this, you are the threat.

> 2. lose some fat, learn a few parkour tricks and move around mostly by night behind dumpsters.

And your alternative is to lurk in dark corners.


The inability to see another option is the inability to understand what
Satoshi created.

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[NxtChg]

>Your vision of censorship resistance is to become such a strong 
>central authority that you can resist it in direct physical confrontation. 
>If you succeed at this, you are the threat.

My vision is a strong _decentralized_ system, which is:

  a) too important to close,

  b) able to provide adequate response to governments, like EFF or Google do.

Having a substantial attack surface and, at the same time, not having significant power is the worst fighting strategy.

It's the "Peter Todd vs 10 cops" scenario.


>The inability to see another option is the inability to understand what Satoshi created.

So your closing remark is basically, "you're too stupid to understand"?

I'll take it.

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

On 09/19/2015 12:57 AM, NxtChg wrote:>
>> Your vision of censorship resistance is to become such a strong
>> central authority that you can resist it in direct physical
>> confrontation. If you succeed at this, you are the threat.
>
> My vision is a strong _decentralized_ system, which is:
>
>   a) too important to close,

Your argument is that the state is not a threat to a system designed to
deprive the state of seigniorage, because the state will see that system
as too important?

Bitcoin cannot be both decentralized and reliant on being, "too
important to close". If it can be closed there is insufficient
decentralization.

I was concerned that this was going off topic for a technical forum.
However this is the central technical issue of Bitcoin. If one does not
understand the threat then one cannot model it or design systems to
defend against it. On the other hand, this is unfortunately not new
territory, so I'll leave it at this, which is also not news to most of us...


>   b) able to provide adequate response to governments, like EFF or
Google do.

"The National Security Agency paid millions of dollars to cover the
costs of major internet companies involved in the Prism surveillance
program after a court ruled that some of the agency's activities were
unconstitutional, according to top-secret material passed to the Guardian.

The technology companies, which the NSA says includes Google..."

http://www.theguardian.com/world/2013/aug/23/nsa-prism-costs-tech-companies-paid

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[NxtChg]

>Your argument is that the state is not a threat to a system 
>designed to deprive the state of seigniorage, because the state will see that 
>system as too important?

Well, if you look at governments from the point of youtube illuminati videos, then, yeah, I guess my position would seem a bit off.

But in that case no threat model or small blocks are gonna save you. As history shows, even if you go as deep as Dread Pirate Roberts, you will eventually be caught and prosecuted.

So start building SilkRoadCoin, which only works via TOR, has ASIC-resistant algorithm and 10 Kb blocks. Then you might have a tiny chance.

Most of us subscribed to a global "electronic cash system" and we intend to continue using Bitcoin for that.

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]

>
> Your argument is that the state is not a threat to a system designed to
> deprive the state of seigniorage, because the state will see that system
> as too important?
>

And so we get to one of the hearts of the debate.

The axiom upon which you and NxtChg disagree is this: he/she believes
governments can crush Bitcoin if they want regardless of how decentralised
it is, and you don't.

If one believes governments have the power to end Bitcoin no matter what,
then the only true protection comes from popularity. Governments find it
hard to ban things that are wildly popular with their voters. This is the
Uber approach: grow fast, annoy governments, but be popular enough that
banning you is politically risky.

If you don't believe that governments can end Bitcoin because of
decentralisation, then the opposite conclusion is logical: growth can be
dangerous because stateless money will be inherently opposed by the state,
therefore if growth == less decentralisation, growth increases the risk of
state shutdown.

I don't think we have to choose between decentralisation and growth
actually - computers are just amazingly fast. But that's irrelevant here.

The point is, your disagreement is summed up by your statement:


> Bitcoin cannot be both decentralized and reliant on being, "too important
> to close". If it can be closed there is insufficient decentralization.
>

I believe this statement is wrong because governments can shut down Bitcoin
at any point regardless of its level of decentralisation. This is true
because:

   - Most governments can easily spend enough money to do a 51% attack,
   especially if they can compel chip fabs to cooperate for free. This attack
   works regardless of how decentralised Bitcoin is.

   - Any government can end Bitcoin usage in its territory by jailing
   anyone who advertises acceptance/trading of bitcoins, or prices in BTC.
   Because merchants *must* advertise in order to alert customers that
   trades in BTC are possible, this is an attack which is unsolvable. If
   ordinary people can find such merchants so can government agents.

It may appear that trade cannot be suppressed because merchants can all
become anonymous too, a la Silk Road. However, if use of Bitcoin is banned
then it becomes impossible to convert coins into local currency as that
requires cooperation of banks ..... making it useless for even anonymous
merchants. An outlaw currency is useless even to outlaws.

Because Bitcoin's existence ultimately relies on government cooperation and
acceptance, the best way to ensure its survival is growth. Lots of it.

[-- Attachment #2: Type: text/html, Size: 3188 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[phm]

Mike Hearn via bitcoin-dev wrote:
> Governments find it hard to ban things that are wildly popular with
> their voters. This is the Uber approach: grow fast, annoy governments,
> but be popular enough that banning you is politically risky.
Governments do not find it hard to ban things that threaten their
authority, least of all their authority to control money, and they also
do not find it hard to ban things which are popular. I'm sure the
millions of people with felony drug charges for the possession of
marijuana, a plant, understand this better than you appear to. Also, in
the US, despite overwhelming resistance on a broad scale, legislation
continues to be presented which would violate the 2nd amendment right to
keep and bear arms.

Bitcoin does not enjoy nearly the popularity that marijuana and guns do,
and likely never may. But even if it did, the government can be relied
on to outlaw it once it understands the true extent to which Bitcoin can
undermine its ability to control stores of value. A mining network that
anyone can contribute to would enable Bitcoin to stay alive in spite of
this, much like torrents have enabled people to continue pirating music
regardless of how many websites have been taken down.
>
> If you don't believe that governments can end Bitcoin because of
> decentralisation, then the opposite conclusion is logical: growth can
> be dangerous because stateless money will be inherently opposed by the
> state, therefore if growth == less decentralisation, growth increases
> the risk of state shutdown.
I think there's a difference between natural growth and the kind of
growth that's being proposed by bank-backed start-ups and pro-censorship
entities.
>
> I don't think we have to choose between decentralisation and growth
> actually - computers are just amazingly fast. But that's irrelevant here.
>
> The point is, your disagreement is summed up by your statement:
>  
>
>     Bitcoin cannot be both decentralized and reliant on being,
>     "too important to close". If it can be closed there is
>     insufficient decentralization.
>
>
> I believe this statement is wrong because governments can shut down
> Bitcoin at any point regardless of its level of decentralisation. This
> is true because:
>
>   * Most governments can easily spend enough money to do a 51% attack,
>     especially if they can compel chip fabs to cooperate for free.
>     This attack works regardless of how decentralised Bitcoin is.
>
>   * Any government can end Bitcoin usage in its territory by jailing
>     anyone who advertises acceptance/trading of bitcoins, or prices in
>     BTC. Because merchants /must/ advertise in order to alert
>     customers that trades in BTC are possible, this is an attack which
>     is unsolvable. If ordinary people can find such merchants so can
>     government agents.
>
> It may appear that trade cannot be suppressed because merchants can
> all become anonymous too, a la Silk Road. However, if use of Bitcoin
> is banned then it becomes impossible to convert coins into local
> currency as that requires cooperation of banks ..... making it useless
> for even anonymous merchants. An outlaw currency is useless even to
> outlaws.
A ban on Bitcoin would lead to a rise in p2p markets. The government is
an inefficient sinkhole at its very best and it has never successfully
eradicated anything.

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

phm got most of this, but...

On Sat, Sep 19, 2015 at 2:53 PM, phm via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Mike Hearn via bitcoin-dev wrote:
>
> >
> >   * Most governments can easily spend enough money to do a 51% attack,
> >     especially if they can compel chip fabs to cooperate for free.
> >     This attack works regardless of how decentralised Bitcoin is.
> >
> >   * Any government can end Bitcoin usage in its territory by jailing
> >     anyone who advertises acceptance/trading of bitcoins, or prices in
> >     BTC. Because merchants /must/ advertise in order to alert
> >     customers that trades in BTC are possible, this is an attack which
> >     is unsolvable. If ordinary people can find such merchants so can
> >     government agents.
> >
>
Pot is used as money, and they do jail people for it, but it doesn't have
the effect to which you refer. It has the opposite effect, partially
because it enriches suppliers.

The 51% attack is a good point, but they would be taking a huge risk.
Ideas don't die, just people.  For example, they got Ross Ulbricht, not DPR.

Government is the group of people that does things that are not acceptable
if anyone else does them, and that is because people cheer for them when
they do those things, rather than pointing out that they are not
acceptable.  The movie "The Deep Web" shows how bitcoin helps to turn this
misfortune around.

[-- Attachment #2: Type: text/html, Size: 2022 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Milly Bitcoin]

> Government is the group of people that does things ...

Governments (note the plural) are a collection of entities made up of 
people that do all sorts of things both good and bad.  Attaching your 
political agenda to Bitcoin with the hopes people will agree with it 
after using Bitcoin is not a viable plan to promote your agenda nor is 
it a plan for mass adoption.

Russ

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[NxtChg]

>Bitcoin does not enjoy nearly the popularity that marijuana and guns do,

Marijuana is an individual activity. Precisely the problem with Bitcoin you envision, where each one of us could be easily jailed.

Guns are quite different: they have NRA and judging by how successful it is at fending _any_ sort of gun control laws, it can very effectively counter-balance the government.

If Bitcoin had it's own NBitA, it would be in a much better position to defend itself than a bunch of individual users.


>A mining network that anyone can contribute to would enable Bitcoin to stay alive in spite of this

Again. Start building an alt-coin with ASIC-resistant algorithm then, it's much more important than the small blocks in your model.

And it must also have other features to support your fight: integrated darkcoin-style anonymity, only TOR as the protocol, etc.

Trying to use Bitcoin, which is overly-exposed, for this kind of fight is a pretty dumb idea.

You won't have the benefits of a small attack surface and you won't have the benefits of strength - the most vulnerable position.

Not to mention that many people simply don't share your vision of Bitcoin as a marginalized outlawed coin somewhere in the depths of TOR.

Looking at how enthusiastically people in smallblockistan promote the most vulnerable position, I'd say they are all agents of USG. 

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]

>
> Also, in the US, despite overwhelming resistance on a broad scale,
> legislation continues to be presented which would violate the 2nd amendment
> right to keep and bear arms.


And yet the proposed legislation goes nowhere, and the USA continues to
stand alone in having the first world's weakest gun control laws.

You are just supporting my point with this example. Obama would like to
restrict guns, but can't, because they are too popular (in the USA).

The comparison to BitTorrent is likewise weak: governments hardly care
about piracy. They care enough to pass laws occasionally, but not enough to
put serious effort into enforcement. Wake me up when the USA establishes a
Copyright Enforcement Administration with the same budget and powers as the
DEA.

Internet based black markets exist only because governments tolerate them
(for now). A ban on Tor, Bitcoin or both would send them back to the
pre-2011 state where they were virtually non-existent. Governments tolerate
this sort of abuse only because they believe, I think correctly, that
Bitcoin can have great benefits for their ordinary voters and for now are
willing to let the tech industry experiment.

But for that state of affairs to continue, the benefits must actually
appear. That requires growth.

I think there's a difference between natural growth and the kind of growth
> that's being proposed by bank-backed start-ups and pro-censorship entities.
>

What difference? Are you saying the people who come to Bitcoin because of a
startup are somehow less "natural" than other users?

[-- Attachment #2: Type: text/html, Size: 2177 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

Replying to this specific email only because it is the most recent in my
mail client.

Does this conversation have to happen on-list? It seems to have wandered
incredibly far off-topic.

On Sun, Sep 20, 2015 at 5:25 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Also, in the US, despite overwhelming resistance on a broad scale,
>> legislation continues to be presented which would violate the 2nd amendment
>> right to keep and bear arms.
>
>
> And yet the proposed legislation goes nowhere, and the USA continues to
> stand alone in having the first world's weakest gun control laws.
>
> You are just supporting my point with this example. Obama would like to
> restrict guns, but can't, because they are too popular (in the USA).
>
> The comparison to BitTorrent is likewise weak: governments hardly care
> about piracy. They care enough to pass laws occasionally, but not enough to
> put serious effort into enforcement. Wake me up when the USA establishes a
> Copyright Enforcement Administration with the same budget and powers as the
> DEA.
>
> Internet based black markets exist only because governments tolerate them
> (for now). A ban on Tor, Bitcoin or both would send them back to the
> pre-2011 state where they were virtually non-existent. Governments tolerate
> this sort of abuse only because they believe, I think correctly, that
> Bitcoin can have great benefits for their ordinary voters and for now are
> willing to let the tech industry experiment.
>
> But for that state of affairs to continue, the benefits must actually
> appear. That requires growth.
>
> I think there's a difference between natural growth and the kind of growth
>> that's being proposed by bank-backed start-ups and pro-censorship entities.
>>
>
> What difference? Are you saying the people who come to Bitcoin because of
> a startup are somehow less "natural" than other users?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3220 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[NxtChg]

>Does this conversation have to happen on-list? It seems to have wandered incredibly far off-topic.

How is this off-topic? This a fundamental decision, from which all the other development decisions follow.

And apparently it's far from settled, with one part pulling in the direction of HideCoin and the other in the direction of PopCoin.

The block limit debate is a direct consequence of this fundamental disagreement.

Until this is settled, Bitcoin has no clear direction and developers cannot make effective decisions: it's hard to get anywhere when you don't know where you're going.

Even though this disagreement probably won't be resolved on this list, it's helpful to have this discussion for people to understand what the root problem is.

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Milly Bitcoin]

> Until this is settled, Bitcoin has no clear direction and developers cannot make effective decisions:

How exactly do things set "settled" in this environment?

People looking at Bitcoin think a small group of developers and miners 
"control" these decisions.  Not sure if "control" is the right word but 
that is the perception.

Russ

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Steven Pine]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

It's amazing how foolish some people are to continue trusting governments
especially in light of recent history: a seemingly endless, Orwellian 'war
on terror', multiple regional conflicts often justified by fake evidence,
wholesale disregard of law and basic human covenants such as do not
torture, ubiquitous and secret global surveillance.

Anyone who doesn't consider governments the proper threat model is either a
shill or an idiot.
On Sep 20, 2015 12:34 PM, "Milly Bitcoin via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Until this is settled, Bitcoin has no clear direction and developers
>> cannot make effective decisions:
>>
>
> How exactly do things set "settled" in this environment?
>
> People looking at Bitcoin think a small group of developers and miners
> "control" these decisions.  Not sure if "control" is the right word but
> that is the perception.
>
> Russ
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 1751 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Milly Bitcoin]

Your reply has nothing to do with my comment.  It looks like you just go 
around posting wing nut stuff without regard to what is being discussed. 
  A proper threat model considers all possible threats and looks at the 
probability of each.

Obviously from your comment you have no experience in threat models and 
limited education in general.


Russ


On 9/20/2015 4:23 PM, Steven Pine wrote:
> It's amazing how foolish some people are to continue trusting
> governments especially in light of recent history: a seemingly endless,
> Orwellian 'war on terror', multiple regional conflicts often justified
> by fake evidence, wholesale disregard of law and basic human covenants
> such as do not torture, ubiquitous and secret global surveillance.
>
> Anyone who doesn't consider governments the proper threat model is
> either a shill or an idiot.
>
> On Sep 20, 2015 12:34 PM, "Milly Bitcoin via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>         Until this is settled, Bitcoin has no clear direction and
>         developers cannot make effective decisions:
>
>
>     How exactly do things set "settled" in this environment?
>
>     People looking at Bitcoin think a small group of developers and
>     miners "control" these decisions.  Not sure if "control" is the
>     right word but that is the perception.
>
>     Russ
>
>
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[s7r]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Nobody said anything about trusting the governments in the way such as
you describe.

No matter how much you want to disagree here, Mike Hearn is right on
some aspects. He only said that bitcoin needs to have larger user
base, more use cases, making it more popular and less likely to be
banned by the governments because of political reasons. He did not say
"let's trust the governments and centralize bitcoin, give them the
possibility to trace/seize/control people's bitcoins, own all the full
nodes or hashing power" or anything like this. So, I think he wants to
suggest "be smart and Play by the rules, follow your interest". The
general threat model for which we want to scale is: larger user base
(not necessarily by increasing the blocksize - just increase the
transactions per second using the best way from all points of view),
more use cases for simple people who only do basic stuff, more
popularity but all these without the possibility for some actor to
control more than he should (like a government agency). For example,
just a summary (among many others): it will always be impossible to
freeze anyone's coins, or take them without the party's consent, or
make it mandatory to tie bitcoin addresses / wallets to real world
identities.

If we think governments are the threat, it's bad. This is because they
can make bitcoin illegal, and no matter what you or I think, there
will _always_ be more people who follow the laws (even the immoral
ones) than people who don't. If it's illegal / banned in relevant
places/countries/continents, bitcoin will be useless. What good will
it be if you can only use it anonymously in a dark-web via Tor, and
you can't tell anyone you do it and can't exchange it to fiat or vice
versa? Bitcoin has to be legit, have normal use cases and be as
popular as possible. Don't think that if tomorrow some government bans
bitcoin there will be a revolution supporting freedom and free speech
and who had this terrible idea will be jailed forever - this will not
happen. What will happen is that users under that jurisdiction will
not use bitcoin any more, merchants from there will not accept bitcoin
any more and exchangers from there will disappear. If some of them
will remain to continue doing it as an outlaw, I assume their number
will be insignificant anyway. If we move towards crypto-anarchy where
we want to say "f*** the laws, f*** the government, f*** everything",
we already lost and this should not be the consensus here under any
circumstances. We, a few computer experts on this mail list using
bitcoin is not what it will make it strong. What will make it strong
is millions of human beings from all social classes and with various
occupations using it for whatever boring reason each one might have.

+1: An outlaw currency is useless even to outlaws.


> On 9/20/2015 4:23 PM, Steven Pine wrote:
>> It's amazing how foolish some people are to continue trusting 
>> governments especially in light of recent history: a seemingly
>> endless, Orwellian 'war on terror', multiple regional conflicts
>> often justified by fake evidence, wholesale disregard of law and
>> basic human covenants such as do not torture, ubiquitous and
>> secret global surveillance.
>> 
>> Anyone who doesn't consider governments the proper threat model
>> is either a shill or an idiot.
>> 
>> On Sep 20, 2015 12:34 PM, "Milly Bitcoin via bitcoin-dev" 
>> <bitcoin-dev@lists.linuxfoundation.org 
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>> 
>> Until this is settled, Bitcoin has no clear direction and 
>> developers cannot make effective decisions:
>> 
>> 
>> How exactly do things set "settled" in this environment?
>> 
>> People looking at Bitcoin think a small group of developers and 
>> miners "control" these decisions.  Not sure if "control" is the 
>> right word but that is the perception.
>> 
>> Russ
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJV/yYyAAoJEIN/pSyBJlsRbagH/1mv0u+xUy2FhYhk07irH9Qd
+U/v7xOLfrzz8j7BzcqLAt3Jey0r00oWbLpay4EyhtoOjPFSFwXZ5Cz/2FChbTFO
kNFtrQpR9ioRAHslePzhIWl0Zl3qz6a7HzrYGl7hLZVJGmXdAncpGEZLpgjONggb
R+dbKipICkRCjuOWZkpULLVUEfTTdy7bkBTR33wVb7QxRhdJNdLtXc9E0xEWPwfy
AalDSu/nhg+VLjIW9NUGky8oqk1pqnHS8AkkAt0jLaemdWgLTzt6Ll4+w4GYaLrj
Ac2te3HXPwUzyq9xnoae5ESOU7MWzkzvyKQs35c4z03aLz2UxHjEL6o6K50leAw=
=43rd
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Eric Lombrozo]

------ Original Message ------
From: "s7r via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
To: bitcoin-dev@lists.linuxfoundation.org
Sent: 9/20/2015 2:33:38 PM
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

>The general threat model for which we want to scale is: larger user 
>base
>(not necessarily by increasing the blocksize - just increase the
>transactions per second using the best way from all points of view),
>more use cases for simple people who only do basic stuff, more
>popularity but all these without the possibility for some actor to
>control more than he should (like a government agency).

Larger user base won't necessarily protect against governments if we 
still have chokepoints they can go after. Given that as a currency 
Bitcoin  currently represents a negligible portion of the world's 
economy, even growing the user base by some small factor is at best a 
token gesture in our fight against governmental threats. If governments 
successfully take down critical pieces of our network infrastructure, 
Bitcoin will fail and most people will continue doing business as usual 
(using fiat currency), most of them never even noticing anything 
noteworthy happened at all.

What we really need to grow is the number of nodes on the network that 
participate in its basic infrastructure - namely: miners, validators, 
etc...and the more centralized these activities become, the easier it 
will be for governments to clamp down.
>

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Milly Bitcoin]

> Larger user base won't necessarily protect against governments if we
> still have chokepoints they can go after.


Bitcoin will always have chokepoints governments can go after.  Hackers 
already targeted routers to divert mining traffic awhile back.  Bitcoin 
traffic is easily seen and blocked by ISP's.  It has already been 
pointed out that laws against merchants and exchanges cannot be defended 
against any other way than to have many people use the system.  (As a 
developer you, of course, did not mention the threat of having a tiny 
number of developers who have significant influence over Bitcoin.  It 
always amazes me the endless discussion over miners centralization and 
almost zero discussion of developer decentralization.)

Increasing the nodes by a factor of 2 or 3 or keeping the block size 
small to increase the diversity of miners by a few percent will have 
zero effect if those other government threats were to actually happen.

Russ

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Eric Lombrozo]

------ Original Message ------
From: "Milly Bitcoin via bitcoin-dev" 
<bitcoin-dev@lists.linuxfoundation.org>
To: bitcoin-dev@lists.linuxfoundation.org
Sent: 9/20/2015 3:02:32 PM
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

>>Larger user base won't necessarily protect against governments if we
>>still have chokepoints they can go after.
>
>
>Bitcoin will always have chokepoints governments can go after.  Hackers 
>already targeted routers to divert mining traffic awhile back.  Bitcoin 
>traffic is easily seen and blocked by ISP's.  It has already been 
>pointed out that laws against merchants and exchanges cannot be 
>defended against any other way than to have many people use the system.
Almost none of these merchants depend on Bitcoin in any significant way 
for revenue...and that's likely to remain the case for a good while. 
Merchants that have chosen to accept Bitcoin are typically using a 
handful of payment processors, again...chokepoints. And almost none of 
them are contributing any network resources back to Bitcoin.

Exchanges are indeed serious chokepoints. But increasing the number of 
users will probably have relatively little effect on this unless we also 
increase the number of exchanges and decentralize the exchanges. If all 
we had to do is increase the number of users, the same argument could be 
used to claim that banks would be less susceptible to governmental 
crackdowns if they just had more account holders.

Exchange decentralization is indeed another thing we must work towards - 
but that's probably beyond the scope of the more pressing issue which is 
building consensus in Bitcoin development.

>(As a developer you, of course, did not mention the threat of having a 
>tiny number of developers who have significant influence over Bitcoin.  
>It always amazes me the endless discussion over miners centralization 
>and almost zero discussion of developer decentralization.)
I've pointed out this weakness of Bitcoin *numerous* times. That I 
failed to mention it here does not mean it hasn't been discussed 
elsewhere. Some of us have also been actively working towards developing 
a more modular, layered architecture and better implementations that 
will afford greater decentralization in software development with less 
need for critical code reviews, less pushback from downstream developers 
who must continuously rebase, a better process for building consensus in 
the community, and simpler app migration.

>
>
>Increasing the nodes by a factor of 2 or 3 or keeping the block size 
>small to increase the diversity of miners by a few percent will have 
>zero effect if those other government threats were to actually happen.
>
We need to increase the basic infrastructure nodes by a factor much 
larger than 2 or 3...more like 100 or 1000...and it's entirely doable 
with properly aligned incentives.

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

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Milly Bitcoin]

>Some of us have also been actively working towards developing
> a more modular, layered architecture and better implementations that
> will afford greater decentralization in software development with less
> need for critical code reviews, less pushback from downstream developers
> who must continuously rebase, a better process for building consensus in
> the community, and simpler app migration.

It sounds more efficient but it is not clear to me that it would change 
the level of centralization of how the final decisions are made.

One threat to Bintcoin involves incentive for companies to hire 
developers.  The only reason is to change (or not change) Bitcoin Core 
so it is beneficial to their interests.  I am not sure anything can be 
done about that risk but it needs to be understood and considered and 
not just ignored.

> We need to increase the basic infrastructure nodes by a factor much
> larger than 2 or 3...more like 100 or 1000...and it's entirely doable
> with properly aligned incentives.

I assume that would mean fees that hike transaction fees and make 
Bitcoin more expensive?

Russ

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Eric Lombrozo]

------ Original Message ------
From: "Milly Bitcoin via bitcoin-dev" 
<bitcoin-dev@lists.linuxfoundation.org>
To: bitcoin-dev@lists.linuxfoundation.org
Sent: 9/20/2015 3:51:36 PM
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

>>Some of us have also been actively working towards developing
>>a more modular, layered architecture and better implementations that
>>will afford greater decentralization in software development with less
>>need for critical code reviews, less pushback from downstream 
>>developers
>>who must continuously rebase, a better process for building consensus 
>>in
>>the community, and simpler app migration.
>
>It sounds more efficient but it is not clear to me that it would change 
>the level of centralization of how the final decisions are made.
>
>One threat to Bintcoin involves incentive for companies to hire 
>developers.  The only reason is to change (or not change) Bitcoin Core 
>so it is beneficial to their interests.  I am not sure anything can be 
>done about that risk but it needs to be understood and considered and 
>not just ignored.
Core development process and decentralized dev/community consensus 
building (in particular for consensus-critical changes) is at the top of 
my priorities as issues right now...and one that I'd love to discuss 
more in depth...but it probably deserves its own thread. The political 
angle seems very difficult right now while the systems architecture 
stuff seems a bit more tractable...and it seems that without 
architectural changes it will be extremely hard to decentralize 
development and easily bring large numbers of new developers in.

>
>>We need to increase the basic infrastructure nodes by a factor much
>>larger than 2 or 3...more like 100 or 1000...and it's entirely doable
>>with properly aligned incentives.
>
>I assume that would mean fees that hike transaction fees and make 
>Bitcoin more expensive?
>
Not necessarily. Right now we already pay around 3,600 bitcoins a day in 
inflationary subsidies, very little of which goes to the majority of 
critical infrastructure nodes and their operators. This is a problem 
with the current protocol design, one we'll hopefully be able to fix.

Having more core infrastructure nodes doesn't need to raise costs per 
transaction - but it will most likely require abandoning the current 
approach of having three basic node classes: miners (which tend towards 
centralized pools), full nodes (which must validate each of everyone's 
transaction and in return get paid nothing), and thin clients (which 
essentially amount to parasitic nodes that do not contribute any 
resources back to the network and must be subsidized).

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

Mike wrote:
... Obama would like to restrict guns, but can't, because they are too
popular (in the USA).
... Governments tolerate this sort of abuse [black markets] only because
they believe, I think correctly, that Bitcoin can have great benefits for
their ordinary voters and for now are willing to let the tech industry
experiment.

Those two reasons must be recognized for their differences.  What does it
mean that something is "too popular" if the ultimate goal of government is
"great benefits for their ordinary voters"?  It means the government
assumes that some things are bad for people even though they are popular.
Crystal meth and heroin come to mind.  This is a natural concern of all
decent parents for their children, and the reason that cultures for
millennia have had rites of passage, wherein the child takes on the
responsibility of determining for him or her self whether or not a popular
thing provides great benefits.  That responsibility is the birthright of
every human being. Why is there an institution that usurps it?  How do the
people within that institution benefit from being part of it?

Some history to study and answer these questions includes:

   - The origination of public schooling as motivated by Johann Fichte's
   public letters to his king in response to Prussia's loss to Napolean at
   Jena.
   - Franz Oppenheimer's book, The State, tracing the origination of the
   idea of a state, or group of people who make up and enforce laws.
   - Carroll Quigley's history book, Tragedy and Hope.
   - Larken Rose's book, Kicking the Dragon.
   - The Republic, by Plato, but only once you understand those other books.
   - If you want a shortcut, John Taylor Gatto did a five-hour interview
   which is now titled "The Ultimate History Lesson with John Taylor Gatto."
   It is heavily sourced by its producer in case anyone wants to verify the
   information he provides.

I'm "notplato" for a reason.

notplato

[-- Attachment #2: Type: text/html, Size: 2168 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Corey Haddad]

[-- Attachment #1: Type: text/plain, Size: 3117 bytes --]

If it turns out that the blocksize divide is hinging on differing developer
views on the nature of the threat posed by governments, perhaps it would be
better to defer to people who specialize in that area.  There are plenty of
them operating in the Bitcoin space.  I am familiar with some of the United
States based policy people, such as Jerry Brito, Alex Fowler, Constance
Choi, Jim Harper, Patrick Murck, etc..  If they are not sure how to frame
their ideas as they relate to this debate, maybe the devs could pose some
questions for them to answer.  If the bitcoin policy people are not of
help, maybe we should turn to some political philosophers or something.

The main idea here is that if this is a politics question, please consider
you may be outside your area of expertise.


On Sun, Sep 20, 2015 at 5:11 PM, Dave Scotese via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Mike wrote:
> ... Obama would like to restrict guns, but can't, because they are too
> popular (in the USA).
> ... Governments tolerate this sort of abuse [black markets] only because
> they believe, I think correctly, that Bitcoin can have great benefits for
> their ordinary voters and for now are willing to let the tech industry
> experiment.
>
> Those two reasons must be recognized for their differences.  What does it
> mean that something is "too popular" if the ultimate goal of government is
> "great benefits for their ordinary voters"?  It means the government
> assumes that some things are bad for people even though they are popular.
> Crystal meth and heroin come to mind.  This is a natural concern of all
> decent parents for their children, and the reason that cultures for
> millennia have had rites of passage, wherein the child takes on the
> responsibility of determining for him or her self whether or not a popular
> thing provides great benefits.  That responsibility is the birthright of
> every human being. Why is there an institution that usurps it?  How do the
> people within that institution benefit from being part of it?
>
> Some history to study and answer these questions includes:
>
>    - The origination of public schooling as motivated by Johann Fichte's
>    public letters to his king in response to Prussia's loss to Napolean at
>    Jena.
>    - Franz Oppenheimer's book, The State, tracing the origination of the
>    idea of a state, or group of people who make up and enforce laws.
>    - Carroll Quigley's history book, Tragedy and Hope.
>    - Larken Rose's book, Kicking the Dragon.
>    - The Republic, by Plato, but only once you understand those other
>    books.
>    - If you want a shortcut, John Taylor Gatto did a five-hour interview
>    which is now titled "The Ultimate History Lesson with John Taylor Gatto."
>    It is heavily sourced by its producer in case anyone wants to verify the
>    information he provides.
>
> I'm "notplato" for a reason.
>
> notplato
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3769 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Milly Bitcoin]

On 9/21/2015 1:04 AM, Corey Haddad via bitcoin-dev wrote:
 > If it turns out that the blocksize divide is hinging on differing
 > developer views on the nature of the threat posed by governments,
 > perhaps it would be better to defer to people who specialize in that
 > area.  ...
...
 > The main idea here is that if this is a politics question, please
 > consider you may be outside your area of expertise.


That is a great suggestion.  Jerry Brito is the number one guy to go to 
for this information.  You will find that many early Bitcoiners are 
completely clueless as to the motivations of regulators.  However, you 
still have the problem that some influential developers know Bitcoin but 
otherwise are completely ignorant.  They will go around claiming 
everyone who discusses regulation is a "statist" and so forth.  Some 
people on this list actually claimed I am "statist" simply by pointing 
out that governments do both good and bad things and that most people 
trust and depend on governments to a certain extent.  That is simply a 
fact, it does not support any agenda.

Another example are the developers who are going around claiming a 
stress test is a criminal action against those running nodes.  Such a 
claim brings all kinds of complicated legal questions about the 
liability of people running nodes.  Instead of contacting someone who 
researched the issue (such as Peter Šurda who ended up posting several 
sensible replies) the developer posted some hyperbolic article on Reddit 
which did nothing but promote misinformation.  On top of that it makes 
Bitcoiners look totally ridiculous.  One day they claim Bitcoin will 
collapse all these government institutions and the next day they want 
those same government institutions to arrest people for overflowing 
their memory pool.

One final issue about the conference ... the developers should not be 
accepting advertisers engaged in nefarious activities.  In particular 
BicoinTalk was accepted as an advertiser.  It is well known that site 
has promoted fake banks where many users lost money 
(CoinLeders/Inputs.io), illegal investments schemes where,any people 
lost funds (BLBSE) and whole host of questionable, illegal, immoral, and 
unethical activities.  Just because the guy who runs the site wrote a 
block explorer that does not mean the developers should blindly promote 
a highly questionable web site that damages Bitcoin's reputation.  The 
people running these events need to start acting responsibly.

Russ

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[NxtChg]

>Larger user base won't necessarily protect against governments if 
>we still have chokepoints they can go after.

This is the critical confusion about Bitcoin decentralization, which leads to this whole recent mess of shouting at each other.

Decentralization is _not_ a way to withstand an attack, if the government "goes after you".

Many people got this idea drilled into their heads in the previous years, that Bitcoin is a "movement" to fight governments, and decentralization is its main weapon.

They confuse Bitcoin and Anonymous.


>What we really need to grow is the number of nodes on the network 
>that participate in its basic infrastructure - namely: miners, validators, etc...

Absolutely. Nobody argues that we shouldn't care about decentralization.

But who's gonna pay for all this? What are the incentives?

We need Bitcoin to get much more popular for this to happen.

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[NxtChg]

>Anyone who doesn't consider governments the proper threat model is either a shill or an idiot.

You meant to say "threat". This is what threat model is: https://en.wikipedia.org/wiki/Threat_model

Nobody here discounts governments as a threat.

As to the "proper threat model", you can't construct one since your attacker is essentially unbounded.

For example, any large government could easily obtain 51% of hash power and then only accept transactions from "certified services".

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Steven Pine]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

That's a simple fallacy, historically governments even hegemons, fail, in
fact it would be odd to assert that a government will not fail, therefore
ascribing godlike and limitless powers to a government is again the view of
either a shill or someone untutored in history.

On Sun, Sep 20, 2015 at 5:10 PM, NxtChg <nxtchg@hush.com> wrote:

>
> >Anyone who doesn't consider governments the proper threat model is either
> a shill or an idiot.
>
> You meant to say "threat". This is what threat model is:
> https://en.wikipedia.org/wiki/Threat_model
>
> Nobody here discounts governments as a threat.
>
> As to the "proper threat model", you can't construct one since your
> attacker is essentially unbounded.
>
> For example, any large government could easily obtain 51% of hash power
> and then only accept transactions from "certified services".
>
>


-- 
Steven Pine
(510) 517-7075

[-- Attachment #2: Type: text/html, Size: 1469 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Milly Bitcoin]

> therefore ascribing godlike and limitless powers to a government is
> again the view of either a shill or someone untutored in history.

Since nobody ever ascribed "godlike and limitless powers to a 
government" on this list your comment has no bearing on anything 
discussed here.  I am sure the whole world, except for a few 
underemployed gamers who discovered Bitcoin, are all untutored in history.

As for this thread, the question was how/when is a Bitcoin development 
issue considered "settled?"

Russ

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Milly Bitcoin]

Threat models can be developed for things like threats from governments. 
  The idea in developing a model is to put in the context of other 
possible threats.  For example, someone with a few million to burn can 
easily crash the exchange rate or buy a couple core developers much 
easier and cheaper than doing a 51% attack.  These attacks can be done 
by governments and non-governments alike.  The people who consider 
threats from government and think everyone associated with Bitcoin is 
somehow "pure" are irrational cultists who have no business discussing 
threat models in the first place.

Russ



On 9/20/2015 5:10 PM, NxtChg via bitcoin-dev wrote:
>
>> Anyone who doesn't consider governments the proper threat model is either a shill or an idiot.
>
> You meant to say "threat". This is what threat model is: https://en.wikipedia.org/wiki/Threat_model
>
> Nobody here discounts governments as a threat.
>
> As to the "proper threat model", you can't construct one since your attacker is essentially unbounded.
>
> For example, any large government could easily obtain 51% of hash power and then only accept transactions from "certified services".
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

Steven,

You make a decent point...but please try to keep the discourse civil. 
It's already hard enough trying to figure this stuff out without fanning 
more flames.

------ Original Message ------
From: "Steven Pine via bitcoin-dev" 
<bitcoin-dev@lists.linuxfoundation.org>
To: "Milly Bitcoin" <milly@bitcoins.info>
Cc: bitcoin-dev@lists.linuxfoundation.org
Sent: 9/20/2015 1:23:28 PM
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

>It's amazing how foolish some people are to continue trusting 
>governments especially in light of recent history: a seemingly endless, 
>Orwellian 'war on terror', multiple regional conflicts often justified 
>by fake evidence, wholesale disregard of law and basic human covenants 
>such as do not torture, ubiquitous and secret global surveillance.
>
>Anyone who doesn't consider governments the proper threat model is 
>either a shill or an idiot.
>
>On Sep 20, 2015 12:34 PM, "Milly Bitcoin via bitcoin-dev" 
><bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>Until this is settled, Bitcoin has no clear direction and developers 
>>>cannot make effective decisions:
>>
>>How exactly do things set "settled" in this environment?
>>
>>People looking at Bitcoin think a small group of developers and miners 
>>"control" these decisions.  Not sure if "control" is the right word 
>>but that is the perception.
>>
>>Russ
>>
>>
>>_______________________________________________
>>bitcoin-dev mailing list
>>bitcoin-dev@lists.linuxfoundation.org
>>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 3264 bytes --]

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

>
> Does this conversation have to happen on-list? It seems to have wandered
> incredibly far off-topic.
>

I understand, it does seem off topic. But ..... what was the topic again?
All Jeff's mail and the followups seem to say is there was a meeting where
some people (unnamed) agreed to do something (unspecified) if the metric
used is modified (which doesn't change the fundamental issues).

So there isn't really much on-topic to discuss. If/when Wladimir starts a
thread, with a BIP, and says "this is how it's gonna be in Bitcoin Core",
then there will be things to discuss.

[-- Attachment #2: Type: text/html, Size: 882 bytes --]

[bitcoin-dev] Improving Blocksize Communication Through Markets

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]

Dear List,

1. Are you sick of hearing about THE BLOCKSIZE?
2. Do you feel that long-settled blocksize issues are coming up again
and again, resulting in duplicated work and communications burnout?
3. Do you feel that, while scalability is important and all, people
should just shut up about it already so that you can talk about X
Feature that you actually spent your time on?
4. Do you ever stop and think: How much *money* was spent for everyone
to travel to Montreal, stay at their hotels, and to rent the conference
venue and broadcasting accommodations? Shouldn't there be a way of just
*purchasing* the information we wanted more directly?
5. Do you feel that the inherent subjectivity of the conversation
encourages “political maneuvers” such as character assassination,
reduction of complex issues to minimal (two) unrepresentative “parties”,
and harassment / threats of violence (for the “greater good”)?

As I presented at the Montreal Conference, there is a way to
substantially improve the discussion. Would you believe that Hal Finney
himself advocated it just seven short years ago?

I happen to know it back-to-front, and the (simple) pieces are already
coded into my own more-complex project Truthcoin.

You could wait for me to hack the pieces together myself (which might
take a long time), or you, a competent/fast C++ developer familiar with
Bitcoin and/or Sidechain-Elements, could talk to me for 30 minutes, and
(depending on your skill level) bang it out in, probably, one weekend.

More details are on the project page ( http://bitcoinblocksize.com/ ),
some technical details are in the Github README.

I have also created a Slack:
https://blocksize-markets.slack.com/messages/general/

Sincerely,
Paul

[-- Attachment #2: Type: text/html, Size: 3268 bytes --]

Re: [bitcoin-dev] Improving Blocksize Communication Through Markets

[Isidor Zeuner]

Hi there,

replies in-line:

[...]
> 4. Do you ever stop and think: How much *money* was spent for everyone
> to travel to Montreal, stay at their hotels, and to rent the conference
> venue and broadcasting accommodations?

Not to mention that trying to solve a global issue with a conference
local to Montreal is a good example for _centralizing_ Bitcoin...

[...]
> More details are on the project page ( http://bitcoinblocksize.com/ ),
> some technical details are in the Github README.
>

I agree that letting the market decide is the way to go. But I
don't understand why we would want to have yet another
(side-)chain because of that. The market can already decide at the
point where _every_ Bitcoin user starts to discriminate the Bitcoins
he accepts between the client versions of the blocks where the
Bitcoins come from (and the corresponding BIPs where the version
numbers relate to). If a miner decides to follow a particular block
size policy against the will of the community, the market could
quickly rectify it when the miner realizes that no one accepts the
resulting coins anymore, leading to financial loss for the miner.

Best regards,

Isidor