The ideal solution is one that doesn't create a blocksize too large for full nodes to cope with, but at the same time, one that doesn't force a large number of people off chain. Even doubling to 2MB in one go is quite high when you think about it, so we should aim to increase (or decrease) in smaller increments more often, if needed.
Fortunately, both BIP100 and BIP101 are very smooth already; not even close to suddenly doubling or halving. I reject the whole "if needed" approach. If demand were high and supply were low then we'd effectively have to choose between small blocks (hundreds of competing payment processors) and large blocks (one payment processor, the majority miner). Even with 1MB blocks it's possible to cheaply process many more transactions than would be required for the hundreds of competing payment processors scenario. This seems like the best solution to me. I don't think it's fair that miners have as much influence over the price as proposed by BIP100. At least with this proposal the interests of bitcoin users are taken into account.
I don't see how "fairness" enters into the debate. I'm much more interested in finding something which works and is robust. |
|
|
|
For block 00000000000000000be983a81043933c38008010b849fd6a35d5dd2d57f929bd: - version = 3, encoded as '03000000' (4-byte little-endian);
- previous_hash = 'b6ae559e0678bbb2c926c78838c027ce925b0834e35d1f050000000000000000';
- merkle_root = 'dba85df5822bbf6b3fb409d410d54848510b5b0d49563ab2ee87abecd318dbf4';
- time = 1442663985, encoded as '314efd55' (4-byte little-endian);
- bits = '181287ba', stored as 'ba871218';
- nonce = 3548193207, encoded as 'b7217dd3' (4-byte little-endian).
With these changes, your Python 2 code becomes: import hashlib
header_hex = '03000000b6ae559e0678bbb2c926c78838c027ce925b0834e35d1f050000000000000000dba85df5822bbf6b3fb409d410d54848510b5b0d49563ab2ee87abecd318dbf4314efd55ba871218b7217dd3'
header_bin = header_hex.decode('hex')
hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
print hash[::-1].encode('hex_codec')
which yields 00000000000000000be983a81043933c38008010b849fd6a35d5dd2d57f929bd as required. |
|
|
|
The Nonce of the block is: 70755497
Converted to hex it is: 4a7a43 ---> 6 Bytes instead of 8
Something's gone wobbly here. The nonce of 70755497 is stored in the block header as "a9a43704" (4 bytes). This is precisely the 4-byte big-endian little-endian representation of the nonce. My quick Python 3 check: >>> (70755497).to_bytes(4, byteorder='little')
b'\xa9\xa47\x04'
>>> ''.join(format(byte, '02x') for byte in _)
'a9a43704'
If I now try to double SHA this kind of block with only 6 Bytes for the nonce I don't get a correct result for the block hash.
If've tried to put "00" bevor and behind the digits, but that doesn't solve the problem.
In this big-endian little-endian form you'll get the correct block hash. import hashlib
def sha256(message):
return hashlib.sha256(message).digest()
version = '03000000'
previous_hash = 'e63b16136d61d94bcda2b6609fad58c217dd9a73be7310050000000000000000'
merkle_root = '213f7741f14eb9b972b44402647b20f1e2705c73416dfb35d5f0b6fca86eb8e9'
time = '098d0656'
bits = 'ba871218'
nonce = 'a9a43704'
header = ''.join([version, previous_hash, merkle_root, time, bits, nonce])
hash_bytes = sha256(sha256(bytes.fromhex(header)))
print(''.join(format(byte, '02x') for byte in reversed(hash_bytes)))
returns 000000000000000007a9aef4df0b3782c31b713ebc573685cdce376d7308e5b0. Edit: Corrected big-endian to little-endian throughout. Cheers Danny. |
|
|
|
can someone explain to me why some blocks have small size despite of the huge number of transactions waiting in the mempool?
Block generators are free to choose which transactions to include in their blocks. Among other things, their motivations to include a given transaction are influenced by: - Its fee.
- Its orphan cost (related to its size as data).
- The effect on Bitcoin's reputation.
- For mining pools, their reputation among potential users.
Today, the block subsidy is so high and fees are so low that some block generators consider it profitable to produce empty blocks, minimising the possibility that their block will be orphaned and avoiding the cost of running a full node. Assuming appropriate difficulty adjustments, this increases the average time to first confirmation for all Bitcoin users. |
|
|
|
|
Relatively good news. Any honourable party would pay to be taught. The state, in contrast, is threatening Mr. Reid to obtain his services for free (in fact are changing him $500 to cover their costs).
This is seen as good news only because we concede that violence is the only thing the police understand. This is the best outcome one could hope for.
|
|
|
|
Thanks for answering me Teukon!
You're most welcome. If BIP100 uses the 20% percentile I would guess it would be coded so 1mb is still the minimum limit - so that takes care of the 20% attack setting it to 0mb.
Can anyone confirm that or is it just common sense?
The original PDF (published 2015-06-14) doesn't mention a lower limit at all. This more active equivalent explicitly states: 7. Limit may not decrease below 1MB, nor exceed 32MB.
and includes a short rationale section for this (all added earlier this month). Note: Now that the upper 32MB limit is explictly part of the specification, the upper bound really is 32MB and not Bitcoin's message limit of 32MiB. |
|
|
|
I agree that one question cannot provide anything like a nuanced assessment of your political outlook. However, in many countries, including the countries most likely to provide respondents to the survey, that single question is very predictive of eventual voting.
Precisely. The question assumes that the person is a voter. The question assumes that the person approves of central authority in principle. The block size debate is firmly about how best to protect Bitcoin against the possible emergence of central authority. I don't doubt this question's predictive power regarding election outcomes. The survey neatly ignores conscientious non-voters exactly as an election itself does. If none of those options represents you you could pick moderate. It'd be a pity not to fill out the rest just because of that. It's hard to be perfectly inclusive in forms when it comes to the political spectrum, participants just pick the closest.
It is as though the question: "Which of the following best describes your diet: beef-eater; pork-eater; chicken-eater; general meat-eater" was lifted from PorkFest and asked to a group with a relatively large number of vegetarians. There really isn't a sensible closest option. |
|
|
|
|
I'll pass on this survey but only because of the political orientation question (I had filled out the rest).
|
|
|
|
Relax, no move are going to happen soon. BIP100 is not even coded even less tested. They can't make a move without going in an agreement with the industry that support BIP101 or it could go really messy.
History will slowly unfold.
maybe we should just add 2 MB blocks to win some more time (like Jeff said a few months ago) At the end, this just might be a solution. I am afraid though, that in this case, we would just prolong this block size agony. On the other side, the fast gaining traction BIP100 just shows us that people might be just a bit tired of all of this debate. I mean nothing is coded in BIP100, no client, but such a support. I am also afraid that we are rushing a bit in a solution with this BIP. It seems to me that many people don't even understand about what this BIP100 is all about. But I guess that's what you get once people fed up of drama. If we do this we can rest easy for a short while. Eventually, 2MB may become just as worrisome as 1MB is today. More work will have been done but still there will be no perfect solution. The notion of simply kicking the can to 4MB will surface with the extra argument of "we've done it before" to support the usual "it needs to be raised now" and "drama is bad for business". Anyone else notice the parallel with the many US Debt Ceiling debates? |
|
|
|
Just want to add my 2 cents/ask if I got it right. This I believe is the central core of BIP100, copied from the documentation: Miners vote by encoding BV+BlockSizeRequestValue into coinbase scriptSig, e.g. /BV8000000/ to vote for 8M. Votes are evaluated by dropping bottom 20% and top 20%, and then the most common floor (minimum) is chosen. ( link) The way I understand it, it means this: 1. The 20% lowest and highest votes from miners are dropped. 2. "The most common floor is chosen" - a floor function converts decimals to integers, so a vote for 8.9 mb becomes a 8 mb vote. (Is that correct?) 3. In the case that there are equal votes for say 7mb and 8mb the lowest (minimum) floor is chosen - so 7mb. Honestly I think that sentence is pretty unclear. What if there are floors 9, 10, 11, 12, 13 with all "one" vote each and I come in with 20-30% of mining power and vote twice for 0? Under that definition my floor of 0 would win right? Can someone spell it out for me? Jeff clarified this on the bitcoin-dev mailing list: I have been reading the pdf and one thing I can't figure out is what you mean by "most common floor". Is that the smallest block size that has a vote or the block size with the most votes or something else?
20th percentile, though there is some argument to take the 'mode' of several tranches Alternative understanding:
Block size is set to be the lowest 21 percentile vote - not safe!
I think a better implementation/description would be:
"50 percentile median of votes - done". (not average - MEDIAN)
That way if its broken, well you are already under 51% attack and need to do something anyway.
There are other problems with taking the median though. For this to be effective we'd need to assume that a majority of the blocks mined will vote for a limit deemed good for Bitcoin's long-term health. However, a miner's financial incentives are not particularly well-aligned with that goal. 51%-honesty assumptions doesn't really make sense unless mining is "incentive compatible" (incentive in the broadest sense, altruism accounted for). Companies are good at seeking profits and I doubt Bitcoin can function long-term on the assumption that more than 50% of an entire industry will regularly act against this most fundamental business instinct. If a vote were intimately tied to a long-term financial interest in Bitcoin then I'd be more comfortable with this 50% idea. Something like: "have the coinbase be unspendable for 4 years (rather than just 100 blocks)", but this doesn't quite work. |
|
|
|
I'm still thinking... What if I change the meaning of R R = the number of full block we (statistically) accept for the next 2 weeks I'm looking for a csv file with the values of the block size for several months to make some tests. Can somebody give me a link to such a file ? I'm not sure exactly how you mean this to differ from your first notion. My original query remains. Why would we want to restrict block size at all? Why should we throttle transactions some of the time when we could just not throttle them at all? What I'm getting at is that your proposal has no "Motivation" section. It achieves the goal of raising or lowering the block size limit depending on "user traffic" but it does not explain why this is desired. |
|
|
|
It's true that sending to OP_TRUE may be used also as an out-of-band fee channel.
But what would that "significant advantage" be?
That's the question I'm interested in. I don't have the best grasp of DECOR+ but for any proposal that moves chunks of block rewards around my first question is always "do out-of-bound fees upset the incentives". Regarding the situation described in your DECOR+ blog entry, what if Bob creates his block first and Alice intentionally sets about attacking it? She would need to make her coinbase larger than Bob's to have everyone (except Bob) switch to her block. Beyond that, she would prefer not to share her transaction fees out or have them burnt. Alice would have to share her coinbase but could keep her out-of-band fees for herself. It makes a transaction a bit larger, so users must pay more out-of-band fees than the normal case. Also the transaction would not propagate through the network, as it does not have "official" fees.
Also there is no benefit for the client wallet, because those transactions would be understood by a minority of the miners, slowing down confirmation.
All valid points in my eyes. A client wallet could in many cases create two, mutually incompatible transactions, one paying the fee in the normal way and the other paying a slightly lower overall fee using an OP_TRUE (including standard minrelaytxfee). If there's just one miner that wants to capitalise on the OP_TRUE output then this is still a gain for the user. And it still requires a modified miner software (a miner must prepare his software to enter an orphaning war in case a high OP_TRUE output is found).
I grant all of these drawbacks, but I can imagine a large enough profit incentive overcoming them. Hopefully there is no strong incentive of this type in DECOR+. |
|
|
|
Sorry if this was asked but I missed it or if its somehow obvious and I just dont get it, but what is keeping me from
#1 vote
#2 send coins to newly generated address
#3 vote again
#4 goto #1
Vote weight is calculated proportional to current balance of the address associated with the vote. So if you move your coins the vote will be revoked.
|
|
|
|
|
Can I take a step back and ask why we might want a blocksize limit at all? Can you give a simple reason for why we might prefer R = 1% to R = 0%?
|
|
|
|
I hate these stress tests. it doesn't even have any benefit for anyone.
The "stress test" functions as a vaccine. There are short-term costs and long-term benefits. Some wallets will develop features to help their users more easily manage/avoid stuck transactions in a bid for more users. Some exchanges will do a good job of riding the wave and attract more customers. |
|
|
|
By chopping up, passing around, and burning parts of the coinbase, will we not be promoting out-of-band fees?
Out-of-band fees require coordination between the sender and the miner. It's a private agreement. There is no way to prevent that. Competing miners cannot share out-of-band fees, but out-of-band (private) fees cannot generate contention, so there will be no competition in case a large out-of-band fee appears in a transaction. There could be the case that the sender sends double-spend transactions to each different miner, using out-of-band fees tailored for each one. This requires that the sender knows a bitcoin address of each miner, and miners are prepared to treat those out-of-band payments as fees, and that miners accept transactions over a communication channel other than the Bitcoin network (which will never forward more than 1 double-spend). So the whole thing looks like an attack more than a real possibility arising from normal usage. In this rare case DECOR+ will fall back to a normal orphaning war. However the subsidy is still shared, and while the subsidy is higher than the rare huge out-of-band fee, no orphaning war will occur. What if a sender, instead of including a fee in the standard way, includes an extra standard output, sending the fee to an address for which a corresponding private key is publicly known? Miners could easily claim these fees while the protocol itself would be left in the dark. If there is a significant advantage to senders, I could imagine wallets and clients with "stealth-fee support" arising quite naturally and gaining some popularity. I guess that the Bitcoin-harming stigma attached to such a "feature" would make it much less popular than something like Adblock Plus, but I don't think it's a stretch to imagine 5-10% of all fees being paid in this way. Do you consider this a real possibility? If so (and assuming a low subsidy), can the constants of DECOR+ be set so as to endure a bit of this abuse? (so that the essential relationships are maintained). |
|
|
|
Block size increase in itself is not going to increase the number of TPS because of the orphan risk.
To compete on a global scale with just Paypal f.i., bitcoin would need to go from 7 TPS to something like 700 TPS, or 100 MB block size, at which point propagation becomes problematic, and the risk of a block getting orphaned would be very high.
We already see many blocks that are not full, even blocks with just 1 tx or a couple hundred tx.
One way to reduce the orphan block risk could be to allow 1-block fork merging: a block could be allowed to have multiple previous blocks. This way if two blocks come at the same time, rather than one orphaning the other, the next block could accept both.
This sounds a lot like GHOST ... Currently if block B & C are mined based on block A, then only B or C will be accepted by block D being mined on either B or C.
The proposal would be that D could accept both B & C, half the B & C rewards would be lost (so the total reward is unchanged), duplicate transactions in a merge would be ignored/pruned. And probably that part of B & C reward+fee could go to D, to incentivize the merging.
... and DECOR. |
|
|
|
What exactly does "fees are stable" mean in this context?
I meant that the rate of tx fees being generated by users is constant and you are not dealing with a surge of transactions (or one transaction with massive fees). It would also occur when there is a backlog that is large enough so that any one block worth of transactions doesn't affect the total fees available for the next block by much. Thanks for clarifying. This is what I imagined but didn't want to guess. I'm also not sure about a strategy of taking "the average fee per block in fees" given variable block discovery times. I was thinking of a strategy of taking some fraction y of the total fees in the mempool (maybe y = h% / (1 + h%) where h% is the hashrate of the largest miner).
As the backlog increases, consuming a single block worth of transactions makes less difference to the next set of transactions. If there is two to three blocks worth of transactions that pays x per kB, then there is no point in risking orphaning a block. You can create a new block that pays the same as what you could get by attempting a fork and with much less risk. This is still worth it if the new block pays slightly less than x per kB, since there is much lower risk. Certainly, when there is a healthy backlog, the difference between taking an absolute fee based on an average of past blocks will seem very similar to taking a ratio of the existing mempool. However, I think the average-based strategy will empty the mempool infinitely often and this is where natural incentives most clearly lead to intentional forks. With a ratio, the mempool will never be emptied and the value in undermining a block will stay tied to the value of extending it. I think the use of a ratio (possibly based on an average of past observations) would go a long way to generalising your example strategy beyond the need for the "fees are stable" assumptions. |
|
|
|
I've now read through some of the GHOST and DECOR work, thanks for the links. Unfortunately, this is going to take some time for me to fully absorb. In a nutshell DECOR+ stipulates that all competing blocks receive a share of the reward. For instance, if A finds a block with a 10 BTC fee, and B finds a competing block, then A gets 5, and B gets 5 (- some small amount that is burnt and some small amount that is paid to the miner that includes the uncle header).
In practice, we can soft-fork so that the coinbase transactions pays to OP_TRUE, and specify an additional payload of a bitcoin address. Also the coinbase field can include a reference to an uncle header: UNCLE:<version,parent-height,time,merkle-root,nonce> (48 bytes). Or this can be embedded in an OP_RETURN <data>. 100 bocks later (when the coinbase matures), the miner must split the reward between all competing miners by spending the 100-block old coinbase that was paid to OP_TRUE. If he does not, then the block becomes invalid.
By chopping up, passing around, and burning parts of the coinbase, will we not be promoting out-of-band fees? |
|
|
|
You could model the rest of the miners as x% on the longest chain and (1-x)% on one block back and then find x so that it is stable. When the fees are stable, then x will be pretty much 100%.
What exactly does "fees are stable" mean in this context? I'm also not sure about a strategy of taking "the average fee per block in fees" given variable block discovery times. I was thinking of a strategy of taking some fraction y of the total fees in the mempool (maybe y = h% / (1 + h%) where h% is the hashrate of the largest miner). |
|
|
|
|
Show Posts
