public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] Hard fork proposal from last week's meeting
@ 2017-03-29 19:50 Raystonn .
  2017-03-30 10:34 ` Tom Zander
  0 siblings, 1 reply; 81+ messages in thread
From: Raystonn . @ 2017-03-29 19:50 UTC (permalink / raw)
  To: Jared Lee Richardson, bitcoin-dev

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

Low node costs are a good goal for nodes that handle transactions the node operator can afford.  Nobody is going to run a node for a network they do not use for their own transactions.  If transactions have fees that prohibit use for most economic activity, that means node count will drop until nodes are generally run by those who settle large amounts.  That is very centralizing.

Raystonn

On 29 Mar 2017 12:14 p.m., Jared Lee Richardson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
In order for any blocksize increase to be agreed upon, more consensus is needed.  The proportion of users believing no blocksize increases are needed is larger than the hardfork target core wants(95% consensus).  The proportion of users believing in microtransactions for all is also larger than 5%, and both of those groups may be larger than 10% respectively.  I don't think either the Big-blocks faction nor the low-node-costs faction have even a simple majority of support.  Getting consensus is going to be a big mess, but it is critical that it is done.

On Wed, Mar 29, 2017 at 12:49 AM, Martin Lízner via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
If there should be a hard-fork, Core team should author the code. Other dev teams have marginal support among all BTC users.

Im tending to believe, that HF is necessary evil now. But lets do it in conservative approach:
- Fix historical BTC issues, improve code
- Plan HF activation date well ahead - 12 months+
- Allow increasing block size on year-year basis as Luke suggested
- Compromise with miners on initial block size bump (e.g. 2MB)
- SegWit

Martin Lizner

On Tue, Mar 28, 2017 at 6:59 PM, Wang Chun via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
I've proposed this hard fork approach last year in Hong Kong Consensus
but immediately rejected by coredevs at that meeting, after more than
one year it seems that lots of people haven't heard of it. So I would
post this here again for comment.

The basic idea is, as many of us agree, hard fork is risky and should
be well prepared. We need a long time to deploy it.

Despite spam tx on the network, the block capacity is approaching its
limit, and we must think ahead. Shall we code a patch right now, to
remove the block size limit of 1MB, but not activate it until far in
the future. I would propose to remove the 1MB limit at the next block
halving in spring 2020, only limit the block size to 32MiB which is
the maximum size the current p2p protocol allows. This patch must be
in the immediate next release of Bitcoin Core.

With this patch in core's next release, Bitcoin works just as before,
no fork will ever occur, until spring 2020. But everyone knows there
will be a fork scheduled. Third party services, libraries, wallets and
exchanges will have enough time to prepare for it over the next three
years.

We don't yet have an agreement on how to increase the block size
limit. There have been many proposals over the past years, like
BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
on. These hard fork proposals, with this patch already in Core's
release, they all become soft fork. We'll have enough time to discuss
all these proposals and decide which one to go. Take an example, if we
choose to fork to only 2MB, since 32MiB already scheduled, reduce it
from 32MiB to 2MB will be a soft fork.

Anyway, we must code something right now, before it becomes too late.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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




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

^ permalink raw reply	[flat|nested] 81+ messages in thread
* Re: [bitcoin-dev] Hard fork proposal from last week's meeting
@ 2017-03-31 21:23 Rodney Morris
  2017-03-31 23:13 ` Eric Voskuil
  0 siblings, 1 reply; 81+ messages in thread
From: Rodney Morris @ 2017-03-31 21:23 UTC (permalink / raw)
  To: bitcoin-dev

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

You guessed wrong. Multiple data centres are as much about redundancy and
resiliency, and latency.

As for the cost, data centre space, business grade communication lines, and
staff are orders of magnitude more expensive than the physical hardware
they support.

I'd like to call you out on your continuing reduction to absurdity and
slippery slope arguments. Just because we can't handle 4GB blocks today,
doesn't mean we shouldn't aim in that direction. Doesn't mean we shouldn't
be taking our first second and third baby steps in that direction.

If the obsession with every personal computer being able to run a fill node
continues then bitcoin will be consigned to the dustbin of history, a
footnote to the story of the global crypto currency that eventually took
over the world.

Thanks
Rodney


Date: Fri, 31 Mar 2017 12:14:42 -0400
From: David Vorick <david.vorick@gmail•com>
To: Jared Lee Richardson <jaredr26@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Message-ID:
        <CAFVRnyqSMVj2Ttc4_5vuk73Z5yRJdxeSodvkdjqsrHbgghcmUQ@mail•gmail.com>
Content-Type: text/plain; charset="utf-8"


Then explain why PayPal has multiple datacenters. And why Visa has multiple
datacenters. And why the banking systems have multiple datacenters each.

I'm guessing it's because you need that much juice to run a global payment
system at the transaction volumes that they run at.



Unless you have professional experience working directly with transaction
processors handling tens of millions of financial transactions per day, I
think we can fully discount your assessment that it would be a rounding
error in the budget of a major exchange or Bitcoin processor to handle that
much load. And even if it was, it wouldn't matter because it's extremely
important to Bitcoin's security that it's everyday users are able to and
are actively running full nodes.

I'm not going to take the time to refute everything you've been saying but
I will say that most of your comments have demonstrated a similar level of
ignorance as the one above.

This whole thread has been absurdly low quality.

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

^ permalink raw reply	[flat|nested] 81+ messages in thread
* Re: [bitcoin-dev] Hard fork proposal from last week's meeting
@ 2017-03-29 19:33 Daniele Pinna
  2017-03-29 20:28 ` Peter R
  2017-03-29 20:28 ` David Vorick
  0 siblings, 2 replies; 81+ messages in thread
From: Daniele Pinna @ 2017-03-29 19:33 UTC (permalink / raw)
  To: Bitcoin Dev

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

What about periodically committing the entire UTXO set to a special
checkpoint block which becomes the new de facto Genesis block?

Daniele

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

Message: 5
Date: Wed, 29 Mar 2017 16:41:29 +0000
From: Andrew Johnson <andrew.johnson83@gmail•com>
To: David Vorick <david.vorick@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Message-ID:
        <CAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg@mail•gmail.com>
Content-Type: text/plain; charset="utf-8"

I believe that as we continue to add users to the system by scaling
capacity that we will see more new nodes appear, but I'm at a bit of a loss
as to how to empirically prove it.

I do see your point on increasing load on archival nodes, but the majority
of that load is going to come from new nodes coming online, they're the
only ones going after very old blocks.   I could see that as a potential
attack vector, overwhelm the archival nodes by spinning up new nodes
constantly, therefore making it difficult for a "real" new node to get up
to speed in a reasonable amount of time.

Perhaps the answer there would be a way to pay an archival node a small
amount of bitcoin in order to retrieve blocks older than a certain cutoff?
Include an IP address for the node asking for the data as metadata in the
transaction...  Archival nodes could set and publish their own policy, let
the market decide what those older blocks are worth.  Would also help to
incentivize running archival node, which we do need.  Of course, this isn't
very user friendly.

We can take this to bitcoin-discuss, if we're getting too far off topic.


On Wed, Mar 29, 2017 at 11:25 AM David Vorick <david.vorick@gmail•com>
wrote:

>
> On Mar 29, 2017 12:20 PM, "Andrew Johnson" <andrew.johnson83@gmail•com>
> wrote:
>
> What's stopping these users from running a pruned node?  Not every node
> needs to store a complete copy of the blockchain.
>
>
> Pruned nodes are not the default configuration, if it was the default
> configuration then I think you would see far more users running a pruned
> node.
>
> But that would also substantially increase the burden on archive nodes.
>
>
> Further discussion about disk space requirements should be taken to
> another thread.
>
>
> --
Andrew Johnson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
attachments/20170329/9b48ebe3/attachment.html>

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

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

^ permalink raw reply	[flat|nested] 81+ messages in thread
* Re: [bitcoin-dev] Hard fork proposal from last week's meeting
@ 2017-03-28 19:56 Paul Iverson
  2017-03-28 20:16 ` Pieter Wuille
  2017-03-28 20:43 ` Tom Zander
  0 siblings, 2 replies; 81+ messages in thread
From: Paul Iverson @ 2017-03-28 19:56 UTC (permalink / raw)
  To: bitcoin-dev

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

Thank you for the proposal Wang Chung!

It is clear that, spam aside, blocks are getting full and we need increase
them soon. What I don't like about your proposal is it forces all node
operators to implicitly accept larger blocks in 2020, even maybe against
their will. 32 MB blocks might result in a loss of decentralization, and it
might be too difficult to coordinate for small blocks before it's too late.


So I think Core can't decide on hard forks like this. It must be left up to
the users. I think only choice is for Core to add a run-time option to
allow node operators to increase block size limit, so that this very
controversial decision is not coming from Core. It must come from the
community.

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

^ permalink raw reply	[flat|nested] 81+ messages in thread
* [bitcoin-dev] Hard fork proposal from last week's meeting
@ 2017-03-28 16:59 Wang Chun
  2017-03-28 17:13 ` Matt Corallo
                   ` (5 more replies)
  0 siblings, 6 replies; 81+ messages in thread
From: Wang Chun @ 2017-03-28 16:59 UTC (permalink / raw)
  To: bitcoin-dev

I've proposed this hard fork approach last year in Hong Kong Consensus
but immediately rejected by coredevs at that meeting, after more than
one year it seems that lots of people haven't heard of it. So I would
post this here again for comment.

The basic idea is, as many of us agree, hard fork is risky and should
be well prepared. We need a long time to deploy it.

Despite spam tx on the network, the block capacity is approaching its
limit, and we must think ahead. Shall we code a patch right now, to
remove the block size limit of 1MB, but not activate it until far in
the future. I would propose to remove the 1MB limit at the next block
halving in spring 2020, only limit the block size to 32MiB which is
the maximum size the current p2p protocol allows. This patch must be
in the immediate next release of Bitcoin Core.

With this patch in core's next release, Bitcoin works just as before,
no fork will ever occur, until spring 2020. But everyone knows there
will be a fork scheduled. Third party services, libraries, wallets and
exchanges will have enough time to prepare for it over the next three
years.

We don't yet have an agreement on how to increase the block size
limit. There have been many proposals over the past years, like
BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
on. These hard fork proposals, with this patch already in Core's
release, they all become soft fork. We'll have enough time to discuss
all these proposals and decide which one to go. Take an example, if we
choose to fork to only 2MB, since 32MiB already scheduled, reduce it
from 32MiB to 2MB will be a soft fork.

Anyway, we must code something right now, before it becomes too late.


^ permalink raw reply	[flat|nested] 81+ messages in thread

end of thread, other threads:[~2017-04-02 19:12 UTC | newest]

Thread overview: 81+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-29 19:50 [bitcoin-dev] Hard fork proposal from last week's meeting Raystonn .
2017-03-30 10:34 ` Tom Zander
2017-03-30 11:19   ` David Vorick
2017-03-30 21:42     ` Jared Lee Richardson
2017-03-30 11:24   ` Aymeric Vitte
  -- strict thread matches above, loose matches on Subject: below --
2017-03-31 21:23 Rodney Morris
2017-03-31 23:13 ` Eric Voskuil
     [not found]   ` <CABerxhGeofH4iEonjB1xKOkHcEVJrR+D4QhHSw5cWYsjmW4JpQ@mail.gmail.com>
2017-04-01  1:41     ` Rodney Morris
2017-04-01  6:18   ` Jared Lee Richardson
2017-04-01  7:41     ` Eric Voskuil
     [not found]       ` <CAAt2M1_sHsCD_AX-vm-oy-4tY+dKoDAJhfVUc4tnoNBFn-a+Dg@mail.gmail.com>
     [not found]         ` <CAAt2M19Gt8PmcPUGUHKm2kpMskpN4soF6M-Rb46HazKMV2D9mg@mail.gmail.com>
2017-04-01 14:45           ` Natanael
     [not found]       ` <CAD1TkXusCe-O3CGQkXyRw_m3sXS9grGxMqkMk8dOvFNXeV5zGQ@mail.gmail.com>
2017-04-01 18:42         ` Jared Lee Richardson
     [not found]   ` <CAAt2M1_kuCBQWd9dis5UwJX8+XGVPjjiOA54aD74iS2L0cYcTQ@mail.gmail.com>
     [not found]     ` <CAAt2M19Nr2KdyRkM_arJ=LBnqDQQyLQ2QQ-UBC8=gFnemCdPMg@mail.gmail.com>
2017-04-01 13:26       ` Natanael
2017-03-29 19:33 Daniele Pinna
2017-03-29 20:28 ` Peter R
2017-03-29 22:17   ` Jared Lee Richardson
2017-03-29 20:28 ` David Vorick
2017-03-29 22:08   ` Jared Lee Richardson
2017-03-30  7:11     ` Luv Khemani
2017-03-30 17:16       ` Jared Lee Richardson
2017-03-31  4:21         ` Luv Khemani
2017-03-31  5:28           ` Jared Lee Richardson
2017-03-31  8:19             ` Luv Khemani
2017-03-31 15:59               ` Jared Lee Richardson
2017-03-31 16:14                 ` David Vorick
2017-03-31 16:46                   ` Jared Lee Richardson
2017-03-31 18:23                     ` David Vorick
2017-03-31 18:58                       ` Eric Voskuil
2017-04-01  6:15                       ` Jared Lee Richardson
2017-03-28 19:56 Paul Iverson
2017-03-28 20:16 ` Pieter Wuille
2017-03-28 20:43 ` Tom Zander
2017-03-28 20:53   ` Alphonse Pace
2017-03-28 21:06     ` Luke Dashjr
2017-03-28 16:59 Wang Chun
2017-03-28 17:13 ` Matt Corallo
2017-03-29  8:45   ` Jared Lee Richardson
2017-03-28 17:23 ` Alphonse Pace
2017-03-28 17:31   ` Wang Chun
2017-03-28 17:33     ` Jeremy
2017-03-28 17:50     ` Douglas Roark
2017-03-28 17:33   ` Juan Garavaglia
2017-03-28 17:53     ` Alphonse Pace
2017-03-28 22:36       ` Juan Garavaglia
2017-03-29  2:59         ` Luv Khemani
2017-03-29  6:24         ` Emin Gün Sirer
2017-03-29 15:34           ` Johnson Lau
2017-04-01 16:15             ` Leandro Coutinho
2017-03-29  9:16       ` Jared Lee Richardson
2017-03-29 16:00         ` Aymeric Vitte
2017-03-28 17:34 ` Johnson Lau
2017-03-28 17:46   ` Luke Dashjr
2017-03-28 20:50   ` Tom Zander
2017-03-29  4:21     ` Johnson Lau
2017-03-28 20:48 ` Tom Zander
2017-03-29  6:32 ` Bram Cohen
2017-03-29  9:37   ` Jorge Timón
2017-03-29 19:07     ` Jared Lee Richardson
2017-04-02 19:02       ` Staf Verhaegen
2017-03-29  7:49 ` Martin Lízner
2017-03-29 15:57   ` David Vorick
2017-03-29 16:08     ` Aymeric Vitte
     [not found]       ` <CAFVRnyo1XGNbq_F8UfqqJWHCVH14iMCUMU-R5bOh+h3mtwSUJg@mail.gmail.com>
2017-03-29 16:18         ` David Vorick
2017-03-29 16:20           ` Andrew Johnson
2017-03-29 16:25             ` David Vorick
2017-03-29 16:41               ` Andrew Johnson
2017-03-29 17:14                 ` Aymeric Vitte
2017-03-29 20:53               ` Jared Lee Richardson
2017-03-29 20:32           ` Jared Lee Richardson
2017-03-29 21:36             ` praxeology_guy
2017-03-29 22:33             ` Aymeric Vitte
2017-03-30  5:23               ` Ryan J Martin
2017-03-30 10:30                 ` Tom Zander
2017-03-30 16:44                   ` Jared Lee Richardson
2017-03-30 20:51                   ` Jared Lee Richardson
2017-03-30 21:57                     ` Tom Zander
     [not found]               ` <CAD1TkXvx=RKvjC8BUstwtQxUUQwG4eiU9XmF1wr=bU=xcVg5WQ@mail.gmail.com>
2017-03-30 10:13                 ` Aymeric Vitte
2017-03-29 19:46     ` Jared Lee Richardson
2017-03-29 19:10   ` Jared Lee Richardson
2017-03-29 19:36     ` praxeology_guy
2017-04-02 19:12     ` Staf Verhaegen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox