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

> 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

> 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] High fees / centralization

> Further, we are very far from the point (in my appraisal) where fees are high enough to block home users from using the network. This depends entirely on the usecase entirely. Most likely even without a blocksize increase, home purchases will be large enough to fit on the blocksize in the

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

> 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

> I’m confident that we could work with the miners who we have good relationships with to start including the root hash of the (lagging) UTXO set in their coinbase transactions, in order to begin transforming this idea into reality. By itself, this wouldn't work without a way for a new node to

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

> 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

> 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

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

> 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] High fees / centralization

t…. > > > > On Mar 30, 2017, at 5:52 PM, Jared Lee Richardson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > Further, we are very far from the point (in my appraisal) where fees > are high enough to block home users from using the network

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] Segwit2Mb - combined soft/hard fork - Request For Comments

> Remember that the "hashpower required to secure bitcoin" is determined > as a percentage of total Bitcoins transacted on-chain in each block Can you explain this statement a little better? What do you mean by that? What does the total bitcoins transacted have to do with hashpower required?

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] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

> We are not going to invalidate covert asicboost without a fight. And we are > working with a system that actively (and is demonstrably very effective at > doing it) resists changes which are contentious. This is definitely a > contentious change, because an important part of the community

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

To me, all of these miss the main objection. If a miner found an optimization and kept it for themselves, that's their prerogative. But if that optimization also happens to directly discourage the growth and improvement of the protocol in many unforseen ways, and it also encourages the miner to

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

> Just checking to see if I understand this optimization correctly. In order to > find merkle roots in which the rightmost 32 bits are identical (i.e. partial > hash collisions), we want to compute as many merkle root hashes as quickly as > possible. The fastest way to do this is to take the

Re: [bitcoin-dev] A Small Modification to Segwit

I can speak from personal experience regarding another very prominent altcoin that attempted to utilize an asic-resistant proof of work algorithm, it is only a matter of time before the "asic resistant" algorithm gets its own Asics. The more complicated the algorithm, the more secretive the asic

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] Compatibility-Oriented Omnibus Proposal

> The above decision may quickly become very controversial. I don't think it's what most users had/have in mind when they discuss a "2MB+SegWit" solution. > With the current 1MB+SegWit, testing has shown us that normal usage results in ~2 or 2.1MB blocks. > I think most users will expect a linear

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

> Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has > quadratic hashing risks, and maybe James' 10KB is too ambitious; but even if > so, a simple 1MB tx size limit would clearly do the trick. The broader point > is that quadratic hashing is not a compelling reason to keep

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

> There are 2 primary factors involved here, economic support and hashpower either of which is enough to make a permanent chain split unlikely, miners will mine whichever chain is most profitable(see ETH/ETC hashpower profitability equilibrium for an example of how this works in practice) That's

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

Could this risk mitigation measure be an optional flag? And if so, could it+BIP91 signal on a different bit than bit4? The reason being, if for some reason the segwit2x activation cannot take place in time, it would be preferable for miners to have a more standard approach to activation that

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

I think this BIP represents a gamble, and the gamble may not be a good one. The gamble here is that if the segwit2x changes are rolled out on time, and if the signatories accept the bit4 + bit1 signaling proposals within BIP91, the launch will go smoother, as intended. But conversely, if either

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

> Keep in mind that this is only temporary until segwit has locked in, after that happens it becomes optional for miners again. I missed that, that does effectively address that concern. It appears that BIP148 implements the same rule as would be required to prevent a later chainsplit as well,

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

> This is, by far, the safest way for miners to quickly defend against a chain > split, much better than a -bip148 option. This allows miners to defend > themselves, with very little risk, since the defense is only activated if the > majority of miners do so. I would move for a very rapid

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

> Not really, there are a few relatively simple techniques such as RBF > which can be leveraged to get confirmations on on-side before double > spending on another. Once a transaction is confirmed on the non-BIP148 > chain then the high fee transactions can be made on only the BIP148 > side of the

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

> BIP148 however is a consensus change that can > be rectified if it gets more work, this would act as an additional > incentive for mine the BIP148 side since there would be no wipeout > risk there. This statement is misleading. Wipeout risks don't apply to any consensus changes; It is a

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

> If you're looking for hard numbers at this point you aren't likely to > find them because not everything is easy to measure directly. There's quite a few hard numbers that are available that are of varying use. Mining commitments are a major one because of the stalled chain problem. Node

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

> Wallet nodes being able to fully validate and choose whether or not to accept a particular chain is an important part of bitcoins security model. What you're describing is effectively the same as BU. Nodes follow chains, they do not decide the victor. The average user follows the default of

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

> and allows for resource requirements > that are too high for many users to validate. The block size settings > there are effectively placebo controls. Right, but that's my point. Any level of control the fullnodes believe they have is effectively a placebo, unless the opposition to the miners