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

There is alot going on in this thread so I'll reply more broadly. The original post and the assorted limit proposals---lead me to something I think is worth reiterating: assuming Bitcoin adoption continues to grow at similar or accelerating rates, then eventually the mempool is going to be

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

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

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

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

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

I think at least the three following things have to be done before the block size can be increased by any significant amount: 1. A network protocol defined UTXO snapshot format be defined, UTXO snapshots being created automatically in a deterministic periodic and low-cost fashion. Ability to

[bitcoin-dev] Request for Comments: Mastering Bitcoin 2nd Edition

I'm requesting feedback and corrections for the second edition of "Mastering Bitcoin". Apologies if this is considered off-topic - it is only my second message to this list in 4 years and I think it is relevant because this book is the first source of information for many new bitcoin developers.

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

Le 29/03/2017 à 11:16, Jared Lee Richardson via bitcoin-dev a écrit : > Nodes process transactions and are paid nothing to do so, and their > costs are 100x more relevant to the blocksize debate than a paper > about miner costs. > > Miners are rewarded with fees; nodes are rewarded only by

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

> On 29 Mar 2017, at 14:24, Emin Gün Sirer via bitcoin-dev > wrote: > > >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 > > I'm one of the co-authors of

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

>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 I'm one of the co-authors of that study. I'd be the first to agree with your conclusion and argue that the 4MB size suggested in that paper should not

Re: [bitcoin-dev] Inquiry: Transaction Tiering

On Wednesday, 29 March 2017 14:48:42 CEST Martin Stolze wrote: > Your > conception holds under the presupposition that all action of > hash-power is motivated by 'rational' economic interest. This shows you didn't think this through, instead, the concept holds true when there is even a small

Re: [bitcoin-dev] Inquiry: Transaction Tiering

Sure it will be somewhat controversial initially, however, "miners", will have additional incentive to listen to the network in order to get transactions. It's not taking away from your personal choice, it's adding additional choice to those that are disenfranchised by hash-power centralization.

Re: [bitcoin-dev] Inquiry: Transaction Tiering

Ignoring your contradiction of the political and economical. Your conception holds under the presupposition that all action of hash-power is motivated by 'rational' economic interest. Specifically a very strict distinction between the profitable and the unprofitable; namely to include transactions

Re: [bitcoin-dev] Inquiry: Transaction Tiering

On Monday, 20 March 2017 21:12:36 CEST Martin Stolze via bitcoin-dev wrote: > Background: The current protocol enables two parties to transact > freely, however, transaction processors (block generators) have the > authority to discriminate participants arbitrarily. Nag; they don’t have any

Re: [bitcoin-dev] Requirement for pseudonymous BIP submissions

On Saturday, 18 March 2017 16:23:16 CEST Chris Stewart via bitcoin-dev wrote: > As everyone in the Bitcoin space knows, there is a massive scaling debate > going on. One side wants to increase the block size via segwit, while the > other side wants to increase via hard fork. I have strong

Re: [bitcoin-dev] Inquiry: Transaction Tiering

As I alluded to before, certain language lends itself to simple conclusions. You say that "miner" have simple profit motives and compete only in their respective domains. But what is "mining"? It is the process of acquiring a part of the block space. He who acquires that space can decide over

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

> 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. I find this paper wholly

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] A BIP proposal for segwit addresses

On 03/21/2017 08:14 PM, Peter Todd via bitcoin-dev wrote: > On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via bitcoin-dev > wrote: >> Why use Base 32 when the QR code alphanumeric mode allows 44 characters? >> In Bitcoin Wallet, I use Base 43 (alphabet: >>

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] Strong Anti-Replay via Coinbase Transactions

On Saturday, March 25, 2017 3:30:22 AM Cameron Garnham via bitcoin-dev wrote: > ==Definitions== It's blank? > ==Specification== > > Upon activation of the soft-fork (activation methodology undefined in this > proposal), the following new rules become activated on the Bitcoin > Network. The

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