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

Jared Lee Richardson via bitcoin-dev schreef op wo 29-03-2017 om 12:10 [-0700]: > The proportion of users believing in microtransactions for all is also > larger than 5%, In order to evaluate this statement the definition of microtransaction has to be defined. I guess there will also be no

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

Jared Lee Richardson via bitcoin-dev schreef op wo 29-03-2017 om 12:07 [-0700]: > > It is all very unhealthy for Bitcoin. Both sides need to accept that > microtransactions from all humans cannot go on-chain, and that never > increasing the blocksize doesn't mean millions of home users will run

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

That's a quoted general statement that is highly subjective, not a description of an attack. If you can't articulate a specific attack vector that we're defending against, such a defense has no value. On Apr 1, 2017 12:41 AM, "Eric Voskuil" wrote: -BEGIN PGP SIGNED

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

s solid grounds. > > > > Regards > > > > Juan > > > > > > *From:* Alphonse Pace [mailto:alp.bitc...@gmail.com] > *Sent:* Tuesday, March 28, 2017 2:53 PM > *To:* Juan Garavaglia <j...@112bit.com>; Wang Chun <1240...@gmail.com> > *Cc:* Bitc

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

Den 1 apr. 2017 16:35 skrev "Eric Voskuil via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/31/2017 11:18 PM, Jared Lee Richardson wrote: >> If a typical personal computer cannot run a node there is no >> security. > > If you can't

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

> If a typical personal computer cannot run a node > there is no security. If you can't describe an attack that is made possible when typical personal computers can't run nodes, this kind of logic has no place in this discussion. On Fri, Mar 31, 2017 at 4:13 PM, Eric Voskuil via bitcoin-dev

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

> So your cluster isn't going to need to plan to handle 15k transactions per > second, you're really looking at more like 200k or even 500k transactions per > second to handle peak-volumes. And if it can't, you're still going to see > full blocks. When I first began to enter the blocksize

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/31/2017 11:18 PM, Jared Lee Richardson wrote: >> If a typical personal computer cannot run a node there is no >> security. > > If you can't describe an attack that is made possible when typical > personal computers can't run nodes, this kind

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

Den 1 apr. 2017 01:13 skrev "Eric Voskuil via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/31/2017 02:23 PM, Rodney Morris via bitcoin-dev wrote: > If the obsession with every personal computer being able to run a > fill node

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

I didn't say typical, I said every. Currently a raspberry pi on shitty adsl can run a full node. What's wrong with needing a high end pc and good connectivity to run a full node? People that want to, can. People that don't want to, won't, no matter how low spec the machine you need. If nobody

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/31/2017 02:23 PM, Rodney Morris via bitcoin-dev wrote: > 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, The cause of the block size debate is

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

ed Lee Richardson <jared...@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_5vuk73z5yrjdxesodvkdjqsrhbgghc...@mail.gmail.com> Content-Type: te

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

As an independently verifiable, decentralized store of public information, the Bitcoin block tree and transaction DAG do have an advantage over systems such as Visa. The store is just a cache. There is no need to implement reliability in storage or in communications. It is sufficient to be able

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

Sure, your math is pretty much entirely irrelevant because scaling systems to massive sizes doesn't work that way. At 400B transactions per year we're looking at block sizes of 4.5 GB, and a database size of petabytes. How much RAM do you need to process blocks like that? Can you fit that much

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

I guess I should caveat, a rounding error is a bit of exaggeration - mostly because I previously assumed that it would take 14 years for the network to reach such a level, something I didn't say and that you might not grant me. I don't know why paypal has multiple datacenters, but I'm guessing it

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

> Peter Todd has demonstrated this on mainstream SPV wallets, > https://www.linkedin.com/pulse/peter-todds-fraud-proofs-talk-mit-bitcoin-expo-2016-mark-morris Correct me if I'm wrong, but nothing possible if the client software was electrum-like and used two independent sources for verification.

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

No one is suggesting anything like this. The cost of running a node that could handle 300% of the 2015 worldwide nonbitcoin transaction volume today would be a rounding error for most exchanges even if prices didn't rise. Then explain why PayPal has multiple datacenters. And why Visa has

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

> Err, no, that's what happens when you double click the Ethereum icon instead of the Bitcoin icon. Just because you run "Bitcoin SPV" instead of "Bitcoin Verify Everyone's Else's Crap" doesn't mean you're somehow going to get Ethereum payments. Your verification is just different and the risks

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

> Node operation is making a stand on what money you will accept. > Ie Your local store will only accept US Dollars and not Japanese Yen. Without > being able to run a node, you have no way to independently determine what you > are receiving, you could be paid Zimbawe Dollars and wouldn't know

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

> Nodes don't do politics. People do, and politics is a lot larger with a lot > more moving parts than just node operation. Node operation is making a stand on what money you will accept. Ie Your local store will only accept US Dollars and not Japanese Yen. Without being able to run a node,

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

> The block size itself should be set based on the amount of fees being paid to miners to make a block. There's a formula to this as well, though going from that to a blocksize number will be very difficult. Miner fees need to be sufficient to maintain economic protection against attackers.

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

> What we want is a true fee-market where the miner can decide to make a block > smaller to get people to pay more fees, because if we were to go to 16MB > blocks in one go, the cost of the miner would go up, but his reward based on > fees will go down! > A block so big that 100% of the

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

>> If home users are not running their own full nodes, then home users have to >> trust and rely on other, more powerful nodes to represent them. Of course, >> the more powerful nodes, simply by nature of having more power, are going to >> have different opinions and objectives from the users.

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

...@lists.linuxfoundation.org [bitcoin-dev-boun...@lists.linuxfoundation.org] on behalf of Aymeric Vitte via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] Sent: Wednesday, March 29, 2017 6:33 PM To: Jared Lee Richardson; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Hard fork proposal from last

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

I have heard such theory before, it's a complete mistake to think that others would run full nodes to protect their business and then yours, unless it is proven that they are decentralized and independent Running a full node is trivial and not expensive for people who know how to do it, even with

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

Message: 5 > Date: Wed, 29 Mar 2017 16:41:29 + > From: Andrew Johnson <andrew.johnso...@gmail.com> > To: David Vorick <david.vor...@gmail.com> > Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> > Subject: Re: [bitcoin-dev] Hard fork proposal from last w

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

> 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. Default configurations aren't a big enough deal to factor into the critical discussion of node costs versus transaction fee cost. Default

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

> Perhaps you are fortunate to have a home computer that has more than a single 512GB SSD. Lots of consumer hardware has that little storage. That's very poor logic, sorry. Restricted-space SSD's are not a cost-effective hardware option for running a node. Keeping blocksizes small has

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

d, 29 Mar 2017 16:41:29 + > From: Andrew Johnson <andrew.johnso...@gmail.com > <mailto:andrew.johnso...@gmail.com>> > To: David Vorick <david.vor...@gmail.com <mailto:david.vor...@gmail.com>> > Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org > <ma

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

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

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

> When considering what block size is acceptable, the impact of running bitcoin in the background on affordable, non-dedicated home-hardware should be a top consideration. Why is that a given? Is there math that outlines what the risk levels are for various configurations of node distributions,

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

on synchronizing node drop out due to other reasons such as network bandwidth, memory, and CPU usage. Without doing the above, scheduling to increasing the block size would be wreckless. Cheers, Praxeology Guy Original Message Subject: Re: [bitcoin-dev] Hard fork proposal from last week's

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

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

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

> While Segwit's change from 1 mb size limit to 4 mb weight limit seems to be controversial among some users [..] I don't think it's very interesting to discuss further size increases. I think the reason for this is largely because SegWit as a blocksize increase isn't very satisfying. It

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

Well it's not going off-topic since the btc folks need now to find a way to counter the attack The disk space story is know to be a non issue, because encouraging people to run nodes while they don't know how to dedicate the right storage space that is trivial and not expensive to get today is

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

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

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

What's stopping these users from running a pruned node? Not every node needs to store a complete copy of the blockchain. On Wed, Mar 29, 2017 at 11:18 AM David Vorick via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Perhaps you are fortunate to have a home computer that has

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

On Mar 29, 2017 12:20 PM, "Andrew Johnson" 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

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

Perhaps you are fortunate to have a home computer that has more than a single 512GB SSD. Lots of consumer hardware has that little storage. Throw on top of it standard consumer usage, and you're often left with less than 200 GB of free space. Bitcoin consumes more than half of that, which feels

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

Le 29/03/2017 à 17:57, David Vorick via bitcoin-dev a écrit : > It's too expensive for a home user to run a full node, and user-run > full nodes are what provide the strongest defence against political > manuveuring. Yes but what makes you think that "It's too expensive for a home user to run a

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

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

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

On Mar 29, 2017 9:50 AM, "Martin Lízner via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: Im tending to believe, that HF is necessary evil now. I will firmly disagree. We know how to do a soft-fork blocksize increase. If it is decided that a block size increase is justified, we

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

gt; > Juan > > > > > > From: bitcoin-dev-boun...@lists.linuxfoundation.org > <mailto:bitcoin-dev-boun...@lists.linuxfoundation.org> > [mailto:bitcoin-dev-boun...@lists.linuxfoundation.org > <mailto:bitcoin-dev-boun...@lists.linuxfoundation.org>] O

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

e Pace [mailto:alp.bitc...@gmail.com] > *Sent:* Tuesday, March 28, 2017 2:53 PM > *To:* Juan Garavaglia <j...@112bit.com>; Wang Chun <1240...@gmail.com> > *Cc:* Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> > > *Subject:* Re: [bitcoin-dev] Hard fork propo

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

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

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

; >> >> *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 Protoco

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

> That said, for that to be alleviated we could simply do something based on historical transaction growth (which is somewhat linear, with a few inflection points), Where do you get this? Transaction growth for the last 4 years averages to +65% per year and the last 2 is +80% per year. That's

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

While Segwit's change from 1 mb size limit to 4 mb weight limit seems to be controversial among some users (I find that very often it is because they have been confused about what segwit does or even outright lied about it) I don't think it's very interesting to discuss further size increases. I

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

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

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

> 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. >

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

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

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

:53 PM To: Juan Garavaglia <j...@112bit.com>; Wang Chun <1240...@gmail.com> Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting Juan, I suggest you take a look at this paper: http://fc

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

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

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

tcoin-dev@lists.linuxfoundation.org> 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 provid

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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