Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Johnson Lau via bitcoin-dev]

> On 29 Mar 2017, at 04:50, Tom Zander  > wrote:
> 
> On Tuesday, 28 March 2017 19:34:23 CEST Johnson Lau via bitcoin-dev wrote:
>> So if we really want to get prepared for a potential HF with unknown
>> parameters,
> 
> That was not suggested.
> 
> Maybe you can comment on the very specific suggestion instead?
> 
> -- 
> Tom Zander
> Blog: https://zander.github.io 
> Vlog: https://vimeo.com/channels/tomscryptochannel 
> 

Just take something like FlexTran as example. How you could get prepared for 
that without first finalising the spec?

Or changing the block interval from 10 minutes to some other value?

Also, fixing the sighash bug for legacy scripts?

There are many other ideas that require a HF:
https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Luv Khemani via bitcoin-dev]

Hi Juan


  >  I tend to believe more in Moore’s law, Butters' Law of Photonics and 
Kryder’s Law all has been verified for many years and support that 32 MB in 
2020 are possible and equals or less than 1 MB in 2010.



  Protocol development, especially one in control of people's money cannot be 
based on beliefs. Do you have actual data to show significant increases in 
desktop CPU, memory and bandwidth?


All empirical evidence points to the opposite.

Intel has been struggling to eek out 5-10% gains for each generation of its 
CPUs. The growth of the total blockchain size at 1MB alone is much faster than 
this.

CPU Core counts have also been stagnant for a decade.

Disk Space growth has also been slowing and with the trend towards SSDs, 
available disk space in a typical PC has turned negative sharply.


Regards

Luv



From: bitcoin-dev-boun...@lists.linuxfoundation.org 
 on behalf of Juan Garavaglia 
via bitcoin-dev 
Sent: Wednesday, March 29, 2017 6:36 AM
To: Alphonse Pace; Wang Chun
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting


Alphonse,



Even when several of the experts involved in the document you refer has my 
respect and admiration, I do not agree with some of their conclusions some of 
their estimations are not accurate other changed like Bootstrap Time, Cost per 
Confirmed Transaction they consider a network of 450,000,00 GH and today is 
3.594.236.966 GH, the energy consumption per GH is old, the cost of electricity 
is wrong even when the document was made and is hard to find any parameter used 
that is valid for an analysis today.



Again with all respect to the experts involved in that analysis is not valid 
today.



I tend to believe more in Moore’s law, Butters' Law of Photonics and Kryder’s 
Law all has been verified for many years and support that 32 MB in 2020 are 
possible and equals or less than 1 MB in 2010.



Again may be is not possible Johnson Lau and LukeJr invested a significant 
amount of time investigating ways to do a safe HF, and may be not possible to 
do a safe HF today but from processing power, bandwidth and storage is totally 
valid and Wang Chung proposal has solid grounds.



Regards



Juan





From: Alphonse Pace [mailto:alp.bitc...@gmail.com]
Sent: Tuesday, March 28, 2017 2:53 PM
To: Juan Garavaglia ; Wang Chun <1240...@gmail.com>
Cc: Bitcoin Protocol Discussion 
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting



Juan,



I suggest you take a look at this paper: 
http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf  It may help you form opinions 
based in science rather than what appears to be nothing more than a hunch.  It 
shows that even 4MB is unsafe.  SegWit provides up to this limit.

On Scaling Decentralized 
Blockchains
fc16.ifca.ai
On Scaling Decentralized Blockchains (A Position Paper) Kyle Croman 0 ;1, 
Christian Decker 4, Ittay Eyal , Adem Efe Gencer , Ari Juels 0 ;2, Ahmed Kosba 
0 ;3, Andrew ...





8MB is most definitely not safe today.



Whether it is unsafe or impossible is the topic, since Wang Chun proposed 
making the block size limit 32MiB.





Wang Chun,

Can you specify what meeting you are talking about?  You seem to have not 
replied on that point.  Who were the participants and what was the purpose of 
this meeting?



-Alphonse



On Tue, Mar 28, 2017 at 12:33 PM, Juan Garavaglia 
> wrote:

Alphonse,



In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on 2016 and 32MB 
limit valid in next halving, from network, storage and CPU perspective or 1MB 
was too high in 2010 what is possible or 1MB is to low today.



If is unsafe or impossible to raise the blocksize is a different topic.



Regards



Juan





From: 
bitcoin-dev-boun...@lists.linuxfoundation.org
 
[mailto:bitcoin-dev-boun...@lists.linuxfoundation.org]
 On Behalf Of Alphonse Pace via bitcoin-dev
Sent: Tuesday, March 28, 2017 2:24 PM
To: Wang Chun <1240...@gmail.com>; Bitcoin Protocol 
Discussion 
>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting



What meeting are you referring to?  Who were the participants?



Removing the limit but relying on the p2p protocol is not really a true 32MiB 
limit, but a limit of whatever transport methods provide.  This can lead to 
differing consensus if alternative layers for relaying are used.  What you seem 
to be asking for is an unbound block size (or at least determined by whatever 
miners produce).  This has the possibility (and even likelihood) 

Re: [bitcoin-dev] Encouraging good miners

[Juan Garavaglia via bitcoin-dev]

If a miner try to hurt the network mining just empty blocks at some time the 
rest will start rejecting their blocks and will be orphans so will loss the 
reward incentive and that miner will join the behavior of the rest of the 
miners, if that miner has 51% of hashrate there the smallest problem are the 
empty blocks.

-Original Message-
From: bitcoin-dev-boun...@lists.linuxfoundation.org 
[mailto:bitcoin-dev-boun...@lists.linuxfoundation.org] On Behalf Of Stian 
Ellingsen via bitcoin-dev
Sent: Monday, March 27, 2017 2:50 PM
To: Btc Ideas ; Bitcoin Protocol Discussion 

Subject: Re: [bitcoin-dev] Encouraging good miners

On 27/03/17 18:12, Btc Ideas via bitcoin-dev wrote:

> Add a preference for mined blocks to be the one with more 
> transactions. This comes into play when 2 blocks of the same height 
> are found. The first good block mined would be orphaned if it had less 
> transactions than another. Optionally, have this rule apply to the 
> current block and the previous one.

This would encourage miners to make their own tiny junk transactions to fill up 
their blocks, perhaps leaving larger, more space-efficient transactions in the 
mempool.

> This increases incentive for full blocks because a miner thinking the 
> faster propagation of a smaller block will win him the reward, but 
> that would no longer be a good assumption.

> I read some miners could attack a chain by mining small or empty 
> blocks. This makes that a little more difficult, but they can still 
> attack the chain many ways.

"Good" miners should probably build upon the block with a set of transactions 
more similar to what they themselves would include based on their mempool at 
the time.  However, miners don't have an incentive to do so today.  Instead, 
they may be better off building upon the block that leaves the most valuable 
transactions in the mempool, e.g. a small or empty block, and maybe leave some 
valuable transactions in the mempool for the next miner.[1]  This issue could 
possibly be addressed by a soft-fork that requires miners to pay a portion of 
their fees to future miners.

[1]
https://freedom-to-tinker.com/2016/10/21/bitcoin-is-unstable-without-the-block-reward/

--
Stian


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

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Juan Garavaglia via bitcoin-dev]

Alphonse,

Even when several of the experts involved in the document you refer has my 
respect and admiration, I do not agree with some of their conclusions some of 
their estimations are not accurate other changed like Bootstrap Time, Cost per 
Confirmed Transaction they consider a network of 450,000,00 GH and today is 
3.594.236.966 GH, the energy consumption per GH is old, the cost of electricity 
is wrong even when the document was made and is hard to find any parameter used 
that is valid for an analysis today.

Again with all respect to the experts involved in that analysis is not valid 
today.

I tend to believe more in Moore’s law, Butters' Law of Photonics and Kryder’s 
Law all has been verified for many years and support that 32 MB in 2020 are 
possible and equals or less than 1 MB in 2010.

Again may be is not possible Johnson Lau and LukeJr invested a significant 
amount of time investigating ways to do a safe HF, and may be not possible to 
do a safe HF today but from processing power, bandwidth and storage is totally 
valid and Wang Chung proposal has solid grounds.

Regards

Juan


From: Alphonse Pace [mailto:alp.bitc...@gmail.com]
Sent: Tuesday, March 28, 2017 2:53 PM
To: Juan Garavaglia ; Wang Chun <1240...@gmail.com>
Cc: Bitcoin Protocol Discussion 
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Juan,

I suggest you take a look at this paper: 
http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf  It may help you form opinions 
based in science rather than what appears to be nothing more than a hunch.  It 
shows that even 4MB is unsafe.  SegWit provides up to this limit.

8MB is most definitely not safe today.

Whether it is unsafe or impossible is the topic, since Wang Chun proposed 
making the block size limit 32MiB.


Wang Chun,

Can you specify what meeting you are talking about?  You seem to have not 
replied on that point.  Who were the participants and what was the purpose of 
this meeting?

-Alphonse

On Tue, Mar 28, 2017 at 12:33 PM, Juan Garavaglia 
> wrote:
Alphonse,

In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on 2016 and 32MB 
limit valid in next halving, from network, storage and CPU perspective or 1MB 
was too high in 2010 what is possible or 1MB is to low today.

If is unsafe or impossible to raise the blocksize is a different topic.

Regards

Juan


From: 
bitcoin-dev-boun...@lists.linuxfoundation.org
 
[mailto:bitcoin-dev-boun...@lists.linuxfoundation.org]
 On Behalf Of Alphonse Pace via bitcoin-dev
Sent: Tuesday, March 28, 2017 2:24 PM
To: Wang Chun <1240...@gmail.com>; Bitcoin Protocol 
Discussion 
>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting

What meeting are you referring to?  Who were the participants?

Removing the limit but relying on the p2p protocol is not really a true 32MiB 
limit, but a limit of whatever transport methods provide.  This can lead to 
differing consensus if alternative layers for relaying are used.  What you seem 
to be asking for is an unbound block size (or at least determined by whatever 
miners produce).  This has the possibility (and even likelihood) of removing 
many participants from the network, including many small miners.

32MB in less than 3 years also appears to be far beyond limits of safety which 
are known to exist far sooner, and we cannot expect hardware and networking 
layers to improve by those amounts in that time.

It also seems like it would be much better to wait until SegWit activates in 
order to truly measure the effects on the network from this increased capacity 
before committing to any additional increases.

-Alphonse



On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev 
>
 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 

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Luke Dashjr via bitcoin-dev]

On Tuesday, March 28, 2017 8:53:30 PM Alphonse Pace via bitcoin-dev wrote:
> His demand (not suggestion) allows it without any safeguards.
> 
> >This patch must be in the immediate next release of Bitcoin Core.
> 
> That is not a suggestion.

I think it was probably a design requirement more than a demand. It makes 
sense: if we're aiming to have a long lead time for a possible hardfork, we 
want to get the lead time started ASAP. (It could perhaps have been 
communicated clearer, but let's not read hostility into things when 
unnecessary.)

Meta-topic: Can we try a little harder to avoid sequences of multiple brief 
replies in a matter of minutes? Combine them to a single reply.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Juan Garavaglia via bitcoin-dev]

Alphonse,

In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on 2016 and 32MB 
limit valid in next halving, from network, storage and CPU perspective or 1MB 
was too high in 2010 what is possible or 1MB is to low today.

If is unsafe or impossible to raise the blocksize is a different topic.

Regards

Juan


From: bitcoin-dev-boun...@lists.linuxfoundation.org 
[mailto:bitcoin-dev-boun...@lists.linuxfoundation.org] On Behalf Of Alphonse 
Pace via bitcoin-dev
Sent: Tuesday, March 28, 2017 2:24 PM
To: Wang Chun <1240...@gmail.com>; Bitcoin Protocol Discussion 

Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting

What meeting are you referring to?  Who were the participants?

Removing the limit but relying on the p2p protocol is not really a true 32MiB 
limit, but a limit of whatever transport methods provide.  This can lead to 
differing consensus if alternative layers for relaying are used.  What you seem 
to be asking for is an unbound block size (or at least determined by whatever 
miners produce).  This has the possibility (and even likelihood) of removing 
many participants from the network, including many small miners.

32MB in less than 3 years also appears to be far beyond limits of safety which 
are known to exist far sooner, and we cannot expect hardware and networking 
layers to improve by those amounts in that time.

It also seems like it would be much better to wait until SegWit activates in 
order to truly measure the effects on the network from this increased capacity 
before committing to any additional increases.

-Alphonse



On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev 
>
 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Tom Zander via bitcoin-dev]

On Tuesday, 28 March 2017 19:34:23 CEST Johnson Lau via bitcoin-dev wrote:
> So if we really want to get prepared for a potential HF with unknown
> parameters,

That was not suggested.

Maybe you can comment on the very specific suggestion instead?

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Tom Zander via bitcoin-dev]

On Tuesday, 28 March 2017 18:59:32 CEST Wang Chun via bitcoin-dev wrote:
> 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.
...
> 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.

I think that is a very smart idea, thank you for making it.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Pieter Wuille via bitcoin-dev]

On Tue, Mar 28, 2017 at 12:56 PM, Paul Iverson via bitcoin-dev
 wrote:
> 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.

Bitcoin Core's (nor any other software's) maintainers can already not
decide on a hard fork, and I keep being confused by the focus on Core
in this topic. Even if a hard forking change (or lack thereof) was
included into a new release, it is still up to the community to choose
to run the new software. Bitcoin Core has very intentionally no
auto-update feature, as the choice for what network rules to implement
must come from node operators, not developers. Ask yourself this: if a
new Bitcoin Core release would include a new rule that blacklists
's coins. What do you think would happen? I hope
that people would refuse to update, and choose to run different full
node software.

Core is not special. It is one of many pieces of software that
implement today's Bitcoin consensus rules. If a hardfork is to take
place in a way that does not result in two currencies, it must be
clear that the entire ecosystem will adopt it. Bitcoin Core will not
merge any consensus changes that do not clearly satisfy that
criterion.

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Paul Iverson via bitcoin-dev]

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Douglas Roark via bitcoin-dev]

On 2017/3/28 10:31, Wang Chun via bitcoin-dev wrote:
> The basic idea is, let's stop the debate for whether we should upgrade
> to 2MB, 8MB or 32MiB. 32MiB is well above any proposals' upper limit,
> so any final decision would be a soft fork to this already deployed
> release. If by 2020, we still agree 1MB is enough, it can be changed
> back to 1MB limit and it would also a soft fork on top of that.

While I think this idea isn't bad in and of itself, there is an
assumption being made that the community would come to consensus
regarding a future soft fork. This, IMO, is a dangerous assumption.
Failure would potentially leave the network at a hard fork well past any
current proposal. It would also potentially lead to miners becoming
hostile players and making political demands. ("Soft fork down to X MB
or I'll shut down 15% of the network hashrate and work to shut down more
elsewhere.") I'd hope we can all agree that such a scenario would be
terrible.

I do agree that the idea of giving everybody plenty of time to plan is
critical. (Telecom providers need months, if not years, to plan for even
simple upgrades, which often are not as simple as they look on paper.) I
just think this proposal, while well-meaning, comes across as a bit of a
trojan horse as-is. I can't get behind it, although it could potentially
be molded into something else that's interesting, e.g., Johnson Lau's
Spoonnet. Fork-to-minimum, while introducing its own potential problems,
would put much less pressure on full nodes, and on the ecosphere as a
whole if the max needed to be soft forked down.

(I'd also like to see SegWit go live so that we can get an idea of how
much pressure there really is on the network, thereby giving us a better
idea of how high we can go. I still think we're flying a bit blind in
that regard.)

-- 
---
Douglas Roark
Cryptocurrency, network security, travel, and art.
https://onename.com/droark
joro...@vt.edu
PGP key ID: 26623924



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Luke Dashjr via bitcoin-dev]

On Tuesday, March 28, 2017 5:34:23 PM Johnson Lau via bitcoin-dev wrote:
> You are probably not the first one nor last one with such idea. Actually,
> Luke wrote up a BIP with similar idea in mind:
> 
> https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki
> 
> 
> Instead of just lifting the block size limit, he also suggested to remove
> many other rules. I think he has given up this idea because it’s just too
> complicated.
> ...
> So if we really want to get prepared for a potential HF with unknown
> parameters, I’d suggest to set a time bomb in the client, which will stop
> processing of transactions with big warning in GUI. The user may still
> have an option to continue with old rules at their own risks.

Indeed, actually implementing hfprep proved to be overly complicated.

I like the idea of a time bomb that just shuts down the client after it 
determine it's stale and refuses to start without an explicit override.
That should work no matter what the hardfork is, and gives us a good 
expectation for hardfork timeframes.

> Or, instead of increasing the block size, we make a softfork to decrease
> the block size to 1kB and block reward to 0, activating far in the future.
> This is similar to the difficulty bomb in ETH, which will freeze the
> network.

I don't like this idea. It leaves the node open to attack from blocks actually 
meeting the criteria. Maybe the absolute minimum as Jeremy suggested.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Johnson Lau via bitcoin-dev]

You are probably not the first one nor last one with such idea. Actually, Luke 
wrote up a BIP with similar idea in mind:

https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki 


Instead of just lifting the block size limit, he also suggested to remove many 
other rules. I think he has given up this idea because it’s just too 
complicated.

If we really want to prepare for a hardfork, we probably want to do more than 
simply increasing the size limit. For example, my spoonnet proposal:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
 


In a HF, we may want to relocate the witness commitment to a better place. We 
may also want to fix Satoshi's sighash bug. These are much more than simple 
size increase.

So if we really want to get prepared for a potential HF with unknown 
parameters, I’d suggest to set a time bomb in the client, which will stop 
processing of transactions with big warning in GUI. The user may still have an 
option to continue with old rules at their own risks.

Or, instead of increasing the block size, we make a softfork to decrease the 
block size to 1kB and block reward to 0, activating far in the future. This is 
similar to the difficulty bomb in ETH, which will freeze the network.

> On 29 Mar 2017, at 00:59, Wang Chun via bitcoin-dev 
>  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
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Jeremy via bitcoin-dev]

I think it's probably safer to have a fork-to-minumum (e.g. minimal
coinbase+header) after a certain date than to fork up at a certain date. At
least in that case, the default isn't breaking consensus, but you still get
the same pressure to fork to a permanent solution.

I don't endorse the above proposal, but remarked for the sake of guiding
the argument you are making.


--
@JeremyRubin 


On Tue, Mar 28, 2017 at 1:31 PM, Wang Chun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The basic idea is, let's stop the debate for whether we should upgrade
> to 2MB, 8MB or 32MiB. 32MiB is well above any proposals' upper limit,
> so any final decision would be a soft fork to this already deployed
> release. If by 2020, we still agree 1MB is enough, it can be changed
> back to 1MB limit and it would also a soft fork on top of that.
>
> On Wed, Mar 29, 2017 at 1:23 AM, Alphonse Pace 
> wrote:
> > What meeting are you referring to?  Who were the participants?
> >
> > Removing the limit but relying on the p2p protocol is not really a true
> > 32MiB limit, but a limit of whatever transport methods provide.  This can
> > lead to differing consensus if alternative layers for relaying are used.
> > What you seem to be asking for is an unbound block size (or at least
> > determined by whatever miners produce).  This has the possibility (and
> even
> > likelihood) of removing many participants from the network, including
> many
> > small miners.
> >
> > 32MB in less than 3 years also appears to be far beyond limits of safety
> > which are known to exist far sooner, and we cannot expect hardware and
> > networking layers to improve by those amounts in that time.
> >
> > It also seems like it would be much better to wait until SegWit
> activates in
> > order to truly measure the effects on the network from this increased
> > capacity before committing to any additional increases.
> >
> > -Alphonse
> >
> >
> >
> > On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev
> >  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
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Wang Chun via bitcoin-dev]

The basic idea is, let's stop the debate for whether we should upgrade
to 2MB, 8MB or 32MiB. 32MiB is well above any proposals' upper limit,
so any final decision would be a soft fork to this already deployed
release. If by 2020, we still agree 1MB is enough, it can be changed
back to 1MB limit and it would also a soft fork on top of that.

On Wed, Mar 29, 2017 at 1:23 AM, Alphonse Pace  wrote:
> What meeting are you referring to?  Who were the participants?
>
> Removing the limit but relying on the p2p protocol is not really a true
> 32MiB limit, but a limit of whatever transport methods provide.  This can
> lead to differing consensus if alternative layers for relaying are used.
> What you seem to be asking for is an unbound block size (or at least
> determined by whatever miners produce).  This has the possibility (and even
> likelihood) of removing many participants from the network, including many
> small miners.
>
> 32MB in less than 3 years also appears to be far beyond limits of safety
> which are known to exist far sooner, and we cannot expect hardware and
> networking layers to improve by those amounts in that time.
>
> It also seems like it would be much better to wait until SegWit activates in
> order to truly measure the effects on the network from this increased
> capacity before committing to any additional increases.
>
> -Alphonse
>
>
>
> On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev
>  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
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Alphonse Pace via bitcoin-dev]

What meeting are you referring to?  Who were the participants?

Removing the limit but relying on the p2p protocol is not really a true
32MiB limit, but a limit of whatever transport methods provide.  This can
lead to differing consensus if alternative layers for relaying are used.
What you seem to be asking for is an unbound block size (or at least
determined by whatever miners produce).  This has the possibility (and even
likelihood) of removing many participants from the network, including many
small miners.

32MB in less than 3 years also appears to be far beyond limits of safety
which are known to exist far sooner, and we cannot expect hardware and
networking layers to improve by those amounts in that time.

It also seems like it would be much better to wait until SegWit activates
in order to truly measure the effects on the network from this increased
capacity before committing to any additional increases.

-Alphonse



On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev <
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
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Inquiry: Transaction Tiering

[Martin Stolze via bitcoin-dev]

> [...] we don't need to implement any kind of special bloated transaction that 
> is only mine-able by some explicit set of miners...  No fork or compatibility 
> problems are necessary, can be completely implemented as an added feature.

Yes, absolutely. It would still be helpful if it is somewhat
standardized on the Client level.

> Re: "Miners": I don't really like calling them "transaction processors" 
> because in bitcoin, every synchronizing node that verifies signatures is a 
> transaction processor.

I agree and I really appreciate the explanation! Transaction Processor
is not optimal, I brought up BSA: Block Space Authority before to
slice the pie in terms of it legitimate power structure instead of its
functionality. I maintain that this is better for higher level
discourse. Maybe something like "Consensus Space Sovereign" would be
more suitable.

> What sets them apart from full relay nodes is they create "blocks", which are 
> "ledger change candidates" that included transactions and proof-of-work (PoW: 
> deterministic diffusion puzzle solutions).

Functionally, a node can moderate the network in the following way:
1. Relay transactions (mempool) and the global memory (blockchain)
2. Construct block headers (PoW: deterministic diffusion puzzle
solutions) and write to the global memory (create "blocks", which are
"ledger change candidates")
3. Read, verify and accept changes to the global memory

> Given the above definition of a "block", I would be happy calling them "Block 
> Producers"... which does not imply that they do all of the necessary 
> "transaction processing": that all users should be fine with running Electrum 
> wallets or even SPV clients.  They produce blocks, but its still up to other 
> users in the network to do "transaction processing": decide for themselves if 
> they want to accept particular blocks.

"Block Generator" (ala Satoshi) may be better but let's look at the
power structure analog to the functionality:
1. Authority to propose a change
2. Authority to approve a change
3. Authority to reject a change

This can easily be understood in current political terms. In Spain a:
1. Citizen can propose to engage in a business (voice)
2. (Special) Citizen (the King) can disapprove of the business (sovereign)
3. Citizen can leave Spain (exit)

Likewise, citizens can engage with the sovereign in order to change
some regulation, say average transaction tax. The question is simply
what legitimate authority a node has. We can map that quite neatly
onto the terminology of 'Politics'.

That does also away with naive 51% attack scenarios and the like. They
are akin to aliens invading earth. Surely it is not impossible that
aliens invade and in Bitcoin land, it is currently conceivable, but
most conflicts are not brought about by a single devilish aggressor
but a special interest group that wants to concentrate benefits and
diffuse costs.
- Transaction Tiering could be a great basis for decentralized negotiations.

Regards
Martin


On Sat, Mar 25, 2017 at 10:30 PM, praxeology_guy
 wrote:
> Martin:
>
> Re: Miners not relaying unconfirmed txs...  I was saying that this was a
> good thing from your perspective in wanting to give users the choice on
> which miners would get to confirm the tx.  So then like we don't need to
> implement any kind of special bloated transaction that is only mine-able by
> some explicit set of miners...  No fork or compatibility problems are
> necessary, can be completely implemented as an added feature.
>
> Re: "Miners": I don't really like calling them "transaction processors"
> because in bitcoin, every synchronizing node that verifies signatures is a
> transaction processor.  What sets them apart from full relay nodes is they
> create "blocks", which are "ledger change candidates" that included
> transactions and proof-of-work (PoW: deterministic diffusion puzzle
> solutions).  They help create confidence that transactions in blocks will
> never by double spent by requiring that double spending would need lots of
> economic resources for someone else to re-perform the PoW.
>
> Given the above definition of a "block", I would be happy calling them
> "Block Producers"... which does not imply that they do all of the necessary
> "transaction processing": that all users should be fine with running
> Electrum wallets or even SPV clients.  They produce blocks, but its still up
> to other users in the network to do "transaction processing": decide for
> themselves if they want to accept particular blocks.
>
> Cheers,
> Praxeology Guy
>
>  Original Message 
> Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
> Local Time: March 25, 2017 12:15 PM
> UTC Time: March 25, 2017 5:15 PM
> From: mar...@stolze.cc
> To: praxeology_guy 
> bitcoin-dev@lists.linuxfoundation.org
>
> Thanks, those are valid concerns.
>
>> Potentially miners could create their own private communication
>> 

Re: [bitcoin-dev] Encouraging good miners

[Stian Ellingsen via bitcoin-dev]

On 27/03/17 18:12, Btc Ideas via bitcoin-dev wrote:

> Add a preference for mined blocks to be the one with more
> transactions. This comes into play when 2 blocks of the same height
> are found. The first good block mined would be orphaned if it had
> less transactions than another. Optionally, have this rule apply to
> the current block and the previous one.

This would encourage miners to make their own tiny junk transactions
to fill up their blocks, perhaps leaving larger, more space-efficient
transactions in the mempool.

> This increases incentive for full blocks because a miner thinking
> the faster propagation of a smaller block will win him the reward,
> but that would no longer be a good assumption.

> I read some miners could attack a chain by mining small or empty
> blocks. This makes that a little more difficult, but they can still
> attack the chain many ways.

"Good" miners should probably build upon the block with a set of
transactions more similar to what they themselves would include based
on their mempool at the time.  However, miners don't have an incentive
to do so today.  Instead, they may be better off building upon the
block that leaves the most valuable transactions in the mempool,
e.g. a small or empty block, and maybe leave some valuable
transactions in the mempool for the next miner.[1]  This issue could
possibly be addressed by a soft-fork that requires miners to pay a
portion of their fees to future miners.

[1]
https://freedom-to-tinker.com/2016/10/21/bitcoin-is-unstable-without-the-block-reward/

-- 
Stian


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