> 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 i
> 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 th
> 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 signa
> 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
> 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 consens
> 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 n
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 requ
> 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, no
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 t
> 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 depl
> 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 i
> 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
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 t
> 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 top
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 in
> 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 (the
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 MESSAGE-
Hash: SHA256
> 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?
On
> 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
wrot
> 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 debat
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
> 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.
> 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 a
sight….
>
>
>
> 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 ne
> 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 forse
> There have been attacks demonstrated where a malicious miner with
sufficient hashrate can leverage large blocks to exacerbate selfish mining.
Can you give me a link to this? Having done a lot of mining, I really
really doubt this. I'm assuming the theory relies upon propagation times
and focus
> 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!
I agree in concept with everything you've sa
> You are only looking at technical aspects and missing the political
aspect.
Nodes don't do politics. People do, and politics is a lot larger with a
lot more moving parts than just node operation.
> full nodes protect the user from the change of any properties of Bitcoin
which they do not agree
> 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. Ther
> 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 dif
> It's a political assessment. Full nodes are the ultimate arbiters of
consensus.
That's not true unless miners are thought of as the identical to nodes,
which is has not been true for nearly 4 years now. Nodes arbitrating a
consensus the BU theory - that nodes can restrain miners - but it doesn'
> 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
configur
> 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 significan
> 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, v
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 5%,
> 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 resolves
> 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 unconvi
> 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 ve
38 matches
Mail list logo