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

2017-03-28 Thread Bram Cohen via bitcoin-dev
On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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. > Much as it may be appealing to repeal the block size limit n

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

2017-03-28 Thread 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 commen

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

2017-03-28 Thread 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

Re: [bitcoin-dev] Encouraging good miners

2017-03-28 Thread 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

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

2017-03-28 Thread 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,

Re: [bitcoin-dev] Fraud proofs for block size/weight

2017-03-28 Thread Matt Corallo via bitcoin-dev
I dont think thats true? Sure, you have to assume the block is valid aside from a too-large size, but it seems sane. You don't strictly need to show that a leaf is a parseable transaction, as long as you can assume that the block is valid and that you cannot forge a SHA256 midstate which, when com

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

2017-03-28 Thread 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

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

2017-03-28 Thread Alphonse Pace via bitcoin-dev
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. Wang - still waiting on the details of this meeting. In the spirit of openness, I think you ought to share with the community what kind of s

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

2017-03-28 Thread 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 topi

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

2017-03-28 Thread 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 Vlo

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

2017-03-28 Thread 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.

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

2017-03-28 Thread Tom Zander via bitcoin-dev
On Tuesday, 28 March 2017 21:56:49 CEST Paul Iverson via bitcoin-dev wrote: > 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 agains

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

2017-03-28 Thread 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 contro

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

2017-03-28 Thread 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

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

2017-03-28 Thread 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

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

2017-03-28 Thread Alphonse Pace via bitcoin-dev
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 s

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

2017-03-28 Thread 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 >

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

2017-03-28 Thread 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

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

2017-03-28 Thread 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 p

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

2017-03-28 Thread 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

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

2017-03-28 Thread 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

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

2017-03-28 Thread Matt Corallo via bitcoin-dev
Not sure what "last week's meeting" is in reference to? Agreed that the hard fork should be well-prepared, but I think its dangerous to think that a hard fork as agreed upon would be a simple relaxation of the block size. For example, Johnson Lau's previous proposal, Spoonnet, which I think is pro

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

2017-03-28 Thread Wang Chun via 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

[bitcoin-dev] Inquiry: Transaction Tiering

2017-03-28 Thread Martin Stolze via bitcoin-dev
Hi AJ, That's outstanding. I am glad to see that there is actually somebody who has made some progress. > "miners as service providers." Great idea! Block space as a resource is under-analyzed. > miner/pool's political positions, their consensus ideology, physical location > (yes some people wou

Re: [bitcoin-dev] Inquiry: Transaction Tiering

2017-03-28 Thread 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 somewha

Re: [bitcoin-dev] Encouraging good miners

2017-03-28 Thread 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, ha

Re: [bitcoin-dev] Encouraging good miners

2017-03-28 Thread Btc Ideas via bitcoin-dev
I know miners can do that, but it is not meant to primarily stop a malicious miner, but just to keep the blocks full. I think it is good to convince greedy miners not to mine empty blocks for a speed advantage. Sent with [ProtonMail](https://protonmail.com) Secure Email. Original Messa

Re: [bitcoin-dev] Inquiry: Transaction Tiering

2017-03-28 Thread praxeology_guy via bitcoin-dev
Martin: Re: Block Space Authority, or "authority": in general An authority dictates policy. Authority arises in 4 cases off the top of my head: - Authority because entity threats violence/dominance - Authority because entity's claim to property is respected to maintain friendship/benefits of sp