Re: [bitcoin-dev] Three hardfork-related BIPs

Eric Voskuil via bitcoin-dev schreef op zo 29-01-2017 om 11:37 [-0800]: > > On Jan 29, 2017, at 11:15 AM, Tom Harding via bitcoin-dev > > wrote: > > > >> On 1/28/2017 10:29 AM, Peter Todd via bitcoin-dev wrote: > >> a world of nodes in large datacenters is

Re: [bitcoin-dev] Three hardfork-related BIPs

On 27.01.2017 20:03, Luke Dashjr via bitcoin-dev wrote: Assume as a premise (despite your apparent disagreement below) that for Bitcoin to function, a supermajority of economic activity needs to be verified using full nodes operated by the recipient. Evidence suggests that at this current

Re: [bitcoin-dev] Three hardfork-related BIPs

> On Jan 29, 2017, at 11:15 AM, Tom Harding via bitcoin-dev > wrote: > >> On 1/28/2017 10:29 AM, Peter Todd via bitcoin-dev wrote: >> a world of nodes in large datacenters is a world where it's very easy >> to force the few Bitcoin nodes remaining to

Re: [bitcoin-dev] Three hardfork-related BIPs

On Jan 29, 2017 2:28 PM, "Tom Harding via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: If that's true, why haven't we already seen AML/KYC required of mining pools? That would be comparatively trivial. Some regulators are already looking into it. Even at this point you'd

Re: [bitcoin-dev] Three hardfork-related BIPs

On 1/28/2017 10:29 AM, Peter Todd via bitcoin-dev wrote: > a world of nodes in large datacenters is a world where it's very easy > to force the few Bitcoin nodes remaining to follow AML/KYC rules If that's true, why haven't we already seen AML/KYC required of mining pools? That would be

Re: [bitcoin-dev] Three hardfork-related BIPs

On Sat, Jan 28, 2017 at 07:43:48PM +, Luke Dashjr via bitcoin-dev wrote: > On Saturday, January 28, 2017 10:36:16 AM Natanael wrote: > > There aren't all that many cases where fraud proofs are unreasonably large > > for a networked system like in Bitcoin. If Zero-knowledge proofs can be > >

Re: [bitcoin-dev] Three hardfork-related BIPs

On Saturday, January 28, 2017 10:36:16 AM Natanael wrote: > Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org>: > > Satoshi envisioned a system where full nodes could publish proofs of > > invalid blocks that would be automatically verified by SPV

Re: [bitcoin-dev] Three hardfork-related BIPs

On 27 January 2017 15:53:02 GMT-08:00, Andrew Johnson via bitcoin-dev wrote: >I'd also like to point out to Luke that Satoshi envisioned most full >nodes >running in data centers in the white paper, not every single user needs >to >run a full node to use

Re: [bitcoin-dev] Three hardfork-related BIPs

On 28 January 2017 02:36:16 GMT-08:00, Natanael via bitcoin-dev wrote: >Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" < >bitcoin-dev@lists.linuxfoundation.org>: > >Satoshi envisioned a system where full nodes could publish proofs of >invalid

Re: [bitcoin-dev] Three hardfork-related BIPs

On Friday, January 27, 2017 11:53:02 PM Andrew Johnson via bitcoin-dev wrote: > I don't think that the 17% yearly increase is too far off base considering > current global trends(although I still don't particularly like the idea of > centrally planning the limit, especially not that far into the

Re: [bitcoin-dev] Three hardfork-related BIPs

On Fri, Jan 27, 2017 at 03:47:20PM -0500, Greg Sanders via bitcoin-dev wrote: > Note that the 4MB number comes from a single network metric. > > Quotes directly from the paper in question: > http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf > > >Our results hinge on the key metric of effective

Re: [bitcoin-dev] Three hardfork-related BIPs

Note that the 4MB number comes from a single network metric. Quotes directly from the paper in question: http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf >Our results hinge on the key metric of effective throughput in the overlay network, which we define here as which blocks propagate within an

Re: [bitcoin-dev] Three hardfork-related BIPs

On Jan 27, 2017 03:03, "Andrew Johnson via bitcoin-dev" wrote: Other researchers have come to the conservative conclusion that we could handle 4MB blocks today. I believe this is a mischaracterization of the research conclusions. The actual conclusion

Re: [bitcoin-dev] Three hardfork-related BIPs

Regarding #1, I agree with Johnson Lau and others who have responded since then—this proposal is not appropriate and should not be adopted for the following reasons: 1. Miners will view it as way too little, delivered way too late. And as soon as you say 300kb blocks, you've lost them all. 2.

Re: [bitcoin-dev] Three hardfork-related BIPs

Your BIP implementation should stress the capacity to softfork the rate of blocksize increase if necessary. You briefly mention that: *If over time, this growth factor is beyond what the actual technology offers, the intention should be to soft fork a tighter limit.* However this can work both

Re: [bitcoin-dev] Three hardfork-related BIPs

On Jan 26, 2017 10:15 PM, "Luke Dashjr" wrote: On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote: > Comment on #1. You're dropping the blocksize limit to 300KB and only > reaching the limit that we have in place today 7 years later? The limit only drops all the way

Re: [bitcoin-dev] Three hardfork-related BIPs

Comment on #1. You're dropping the blocksize limit to 300KB and only reaching the limit that we have in place today 7 years later? We're already at capacity today, surely you're not serious with this proposal? When you promised code for a hard forking block size increase in the HK agreement I

Re: [bitcoin-dev] Three hardfork-related BIPs

I can’t recommend your first 2 proposals. But I only have the time to talk about the first one for now. There are 2 different views on this topic: 1. “The block size is too small and people can’t buy a coffee with an on-chain transaction. Let’s just remove the limit” 2. “The block size is too

Re: [bitcoin-dev] Three hardfork-related BIPs

On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote: > Comment on #1. You're dropping the blocksize limit to 300KB and only > reaching the limit that we have in place today 7 years later? The limit only drops all the way to 300k if it activates before 2017 April. Considering that this

[bitcoin-dev] Three hardfork-related BIPs

I've put together three hardfork-related BIPs. This is parallel to the ongoing research into the MMHF/SHF WIP BIP, which might still be best long-term. 1) The first is a block size limit protocol change. It also addresses three criticisms of segwit: 1) segwit increases the block size limit