What is a Block Header in Bitcoin? CryptoCompare.com
What is a Block Header in Bitcoin? CryptoCompare.com
Block Header - How Does Bitcoin Work?
mining theory - Calculate hash of block header - Bitcoin ...
Block hashing algorithm – BitcoinWiki
Block header - Bitcoin Wiki
Finding SHA256 partial collisions via the Bitcoin blockchain
This is not a cryptocurrency post, per se. I used Bitcoin's blockchain as a vehicle by which to study SHA256. The phrase "partial collision" is sometimes used to describe a pair of hashes that are "close" to one another. One notion of closeness is that the two hashes should agree on a large number of total bits. Another is that they should agree on a large number of specific (perhaps contiguous) bits. The goal in Bitcoin mining is essentially (slight simplification here) to find a block header which, when hashed twice with SHA256, has a large number of trailing zeros. (If you have some familiarity with Bitcoin, you may be wondering: doesn't the protocol demand a large number of leading zeros? It does, kind of, but the Bitcoin protocol reverses the normal byte order of SHA256. Perhaps Satoshi interpreted SHA256 output as a byte stream in little endian order. If so, then this is a slightly unfortunate choice, given that SHA256 explicitly uses big endian byte order in its padding scheme.) Because Bitcoin block header hashes must all have a large number of trailing zeros, they must all agree on a large number of trailing bits. Agreement or disagreement on earlier bits should, heuristically, appear independent and uniform at random. Thus, I figured it should be possible to get some nice SHA256 partial collisions by comparing block header hashes. First, I looked for hashes that agree on a large number of trailing bits. At present, block header hashes must have about 75 trailing zeros. There are a little over 2^19 blocks in total right now, so we expect to get a further ~38 bits of agreement via a birthday attack. Although this suggests we may find a hash pair agreeing on 75 + 38 = 113 trailing bits, this should be interpreted as a generous upper bound, since early Bitcoin hashes had fewer trailing zeros (as few as 32 at the outset). Still, this gave me a good enough guess to find some partial collisions without being overwhelmed by them. The best result was a hash pair agreeing on their final 108 bits. Hex encodings of the corresponding SHA256 inputs are as follows: 23ca73454a1b981fe51cad0dbd05f4e696795ba67abb28c61aea1a024e5bbeca a16a8141361ae9834ad171ec28961fc8a951ff1bfc3a9ce0dc2fcdbdfa2ccd35 (I will emphasize that these are hex encodings of the inputs, and are not the inputs themselves.) There were a further 11 hash pairs agreeing on at least 104 trailing bits. Next, I searched for hashes that agree on a large number of total bits. (In other words, hash pairs with low Hamming distance.) With a little over 2^19 blocks, we have around (2^19 choose 2) ~= 2^37 block pairs. Using binomial distribution statistics, I estimated that it should be possible to find hash pairs that agree on more than 205 bits, but probably not more than 210. Lo and behold, the best result here was a hash pair agreeing on 208 total bits. Hex encodings of the corresponding SHA256 inputs are as follows: dd9591ff114e8c07be30f0a7998cf09c351d19097766f15a32500ee4f291e7e3 c387edae394b3b9b7becdddcd829c8ed159a32879c156f2e23db73365fde4a94 There were 8 other hash pairs agreeing on at least 206 total bits. So how interesting are these results, really? One way to assess this is to estimate how difficult it would be to get equivalent results by conventional means. I'm not aware of any clever tricks that find SHA256 collisions (partial or full) faster than brute force. As far as I know, birthday attacks are the best known approach. To find a hash pair agreeing on their final 108 bits, a birthday attack would require 2^54 time and memory heuristically. Each SHA256 hash consists of 2^5 bytes, so 2^59 is probably a more realistic figure. This is "feasible", but would probably require you to rent outside resources at great expense. Writing code to perform this attack on your PC would be inadvisable. Your computer probably doesn't have the requisite ~600 petabytes of memory, anyway. The hash pair agreeing on 208 of 256 bits is somewhat more remarkable. By reference to binomial distribution CDFs, a random SHA256 hash pair should agree on at least 208 bits with probability about 2^-81. A birthday attack will cut down on the memory requirement by the normal square root factor - among ~2^41 hashes, you expect that there will be such a pair. But in this case, it is probably necessary to actually compare all hash pairs. The problem of finding the minimum Hamming distance among a set doesn't have obvious shortcuts in general. Thus, a birthday attack performed from scratch would heuristically require about 2^81 hash comparisons, and this is likely not feasible for any entity on Earth right now. I don't think these results carry any practical implications for SHA256. These partial collisions are in line with what one would expect without exploiting any "weaknesses" of SHA256. If anything, these results are a testament to just how much total work has been put into the Bitcoin blockchain. Realistically, the Bitcoin blockchain will never actually exhibit a SHA256 full collision. Still, I thought these were fun curiosities that were worth sharing.
https://github.com/gridcoin-community/Gridcoin-Research/releases/tag/188.8.131.52 Finally! After over ten months of development and testing, "Fern" has arrived! This is a whopper. 240 pull requests merged. Essentially a complete rewrite that was started with the scraper (the "neural net" rewrite) in "Denise" has now been completed. Practically the ENTIRE Gridcoin specific codebase resting on top of the vanilla Bitcoin/Peercoin/Blackcoin vanilla PoS code has been rewritten. This removes the team requirement at last (see below), although there are many other important improvements besides that. Fern was a monumental undertaking. We had to encode all of the old rules active for the v10 block protocol in new code and ensure that the new code was 100% compatible. This had to be done in such a way as to clear out all of the old spaghetti and ring-fence it with tightly controlled class implementations. We then wrote an entirely new, simplified ruleset for research rewards and reengineered contracts (which includes beacon management, polls, and voting) using properly classed code. The fundamentals of Gridcoin with this release are now on a very sound and maintainable footing, and the developers believe the codebase as updated here will serve as the fundamental basis for Gridcoin's future roadmap. We have been testing this for MONTHS on testnet in various stages. The v10 (legacy) compatibility code has been running on testnet continuously as it was developed to ensure compatibility with existing nodes. During the last few months, we have done two private testnet forks and then the full public testnet testing for v11 code (the new protocol which is what Fern implements). The developers have also been running non-staking "sentinel" nodes on mainnet with this code to verify that the consensus rules are problem-free for the legacy compatibility code on the broader mainnet. We believe this amount of testing is going to result in a smooth rollout. Given the amount of changes in Fern, I am presenting TWO changelogs below. One is high level, which summarizes the most significant changes in the protocol. The second changelog is the detailed one in the usual format, and gives you an inkling of the size of this release.
Note that the protocol changes will not become active until we cross the hard-fork transition height to v11, which has been set at 2053000. Given current average block spacing, this should happen around October 4, about one month from now. Note that to get all of the beacons in the network on the new protocol, we are requiring ALL beacons to be validated. A two week (14 day) grace period is provided by the code, starting at the time of the transition height, for people currently holding a beacon to validate the beacon and prevent it from expiring. That means that EVERY CRUNCHER must advertise and validate their beacon AFTER the v11 transition (around Oct 4th) and BEFORE October 18th (or more precisely, 14 days from the actual date of the v11 transition). If you do not advertise and validate your beacon by this time, your beacon will expire and you will stop earning research rewards until you advertise and validate a new beacon. This process has been made much easier by a brand new beacon "wizard" that helps manage beacon advertisements and renewals. Once a beacon has been validated and is a v11 protocol beacon, the normal 180 day expiration rules apply. Note, however, that the 180 day expiration on research rewards has been removed with the Fern update. This means that while your beacon might expire after 180 days, your earned research rewards will be retained and can be claimed by advertising a beacon with the same CPID and going through the validation process again. In other words, you do not lose any earned research rewards if you do not stake a block within 180 days and keep your beacon up-to-date. The transition height is also when the team requirement will be relaxed for the network.
Besides the beacon wizard, there are a number of improvements to the GUI, including new UI transaction types (and icons) for staking the superblock, sidestake sends, beacon advertisement, voting, poll creation, and transactions with a message. The main screen has been revamped with a better summary section, and better status icons. Several changes under the hood have improved GUI performance. And finally, the diagnostics have been revamped.
The wallet sync speed has been DRASTICALLY improved. A decent machine with a good network connection should be able to sync the entire mainnet blockchain in less than 4 hours. A fast machine with a really fast network connection and a good SSD can do it in about 2.5 hours. One of our goals was to reduce or eliminate the reliance on snapshots for mainnet, and I think we have accomplished that goal with the new sync speed. We have also streamlined the in-memory structures for the blockchain which shaves some memory use. There are so many goodies here it is hard to summarize them all. I would like to thank all of the contributors to this release, but especially thank @cyrossignol, whose incredible contributions formed the backbone of this release. I would also like to pay special thanks to @barton2526, @caraka, and @Quezacoatl1, who tirelessly helped during the testing and polishing phase on testnet with testing and repeated builds for all architectures. The developers are proud to present this release to the community and we believe this represents the starting point for a true renaissance for Gridcoin!
Most significantly, nodes calculate research rewards directly from the magnitudes in EACH superblock between stakes instead of using a two- or three- point average based on a CPID's current magnitude and the magnitude for the CPID when it last staked. For those long-timers in the community, this has been referred to as "Superblock Windows," and was first done in proof-of-concept form by @denravonska.
Network magnitude unit pinned to a static value of 0.25
Max research reward allowed per block raised to 16384 GRC (from 12750 GRC)
New CPIDs begin accruing research rewards from the first superblock that contains the CPID instead of from the time of the beacon advertisement
500 GRC research reward limit for a CPID's first stake
6-month expiration for unclaimed rewards
10-block spacing requirement between research reward claims
Rolling 5-day payment-per-day limit
Legacy tolerances for floating-point error and time drift
The need to include a valid copy of a CPID's magnitude in a claim
10-block emission adjustment interval for the magnitude unit
One-time beacon activation requires that participants temporarily change their usernames to a verification code at one whitelisted BOINC project
Verification codes of pending beacons expire after 3 days
Self-service beacon removal
Burn fee for beacon advertisement increased from 0.00001 GRC to 0.5 GRC
Rain addresses derived from beacon keys instead of a default wallet address
Beacon expiration determined as of the current block instead of the previous block
The ability for developers to remove beacons
The ability to sign research reward claims with non-current but unexpired beacons
As a reminder:
Beacons expire after 6 months pass (180 days)
Beacons can be renewed after 5 months pass (150 days)
Renewed beacons must be signed with the same key as the original beacon
Magnitudes less than 1 include two fractional places
Magnitudes greater than or equal to 1 but less than 10 include one fractional place
A valid superblock must match a scraper convergence
Superblock popularity election mechanics
Yes/no/abstain and single-choice response types (no user-facing support yet)
To create a poll, a maximum of 250 UTXOs for a single address must add up to 100000 GRC. These are selected from the largest downwards.
Burn fee for creating polls scaled by the number of UTXOs claimed
50 GRC for a poll contract
0.001 GRC per claimed UTXO
Burn fee for casting votes scaled by the number of UTXOs claimed
0.01 GRC for a vote contract
0.01 GRC to claim magnitude
0.01 GRC per claimed address
0.001 GRC per claimed UTXO
Maximum length of a poll title: 80 characters
Maximum length of a poll question: 100 characters
Maximum length of a poll discussion website URL: 100 characters
Maximum number of poll choices: 20
Maximum length of a poll choice label: 100 characters
Magnitude, CPID count, and participant count poll weight types
The ability for developers to remove polls and votes
[184.108.40.206] 2020-09-03, mandatory, "Fern"
Backport newer uint256 types from Bitcoin #1570 (@cyrossignol)
Implement project level rain for rainbymagnitude #1580 (@jamescowens)
Upgrade utilities (Update checker and snapshot downloadeapplication) #1576 (@iFoggz)
Provide fees collected in the block by the miner #1601 (@iFoggz)
Add support for generating legacy superblocks from scraper stats #1603 (@cyrossignol)
Port of the Bitcoin Logger to Gridcoin #1600 (@jamescowens)
Implement zapwallettxes #1605 (@jamescowens)
Implements a global event filter to suppress help question mark #1609 (@jamescowens)
Add next target difficulty to RPC output #1615 (@cyrossignol)
Add caching for block hashes to CBlock #1624 (@cyrossignol)
Make toolbars and tray icon red for testnet #1637 (@jamescowens)
Add an rpc call convergencereport #1643 (@jamescowens)
Implement newline filter on config file read in #1645 (@jamescowens)
Implement beacon status icon/button #1646 (@jamescowens)
Add gridcointestnet.png #1649 (@caraka)
Add precision to support magnitudes less than 1 #1651 (@cyrossignol)
Replace research accrual calculations with superblock snapshots #1657 (@cyrossignol)
Publish example gridcoinresearch.conf as a md document to the doc directory #1662 (@jamescowens)
Add options checkbox to disable transaction notifications #1666 (@jamescowens)
Add support for self-service beacon deletion #1695 (@cyrossignol)
Add support for type-specific contract fee amounts #1698 (@cyrossignol)
Add verifiedbeaconreport and pendingbeaconreport #1696 (@jamescowens)
Add preliminary testing option for block v11 height on testnet #1706 (@cyrossignol)
Add verified beacons manifest part to superblock validator #1711 (@cyrossignol)
Implement beacon, vote, and superblock display categories/icons in UI transaction model #1717 (@jamescowens)
I've failed... My dreams of confirming a low fee TXN won't come true this month.
For a bit of fun, I created a low fee TXN (493 s/kB) to see if pool would confirm below 1000 s/kB. Seems the answer is usually "very very unlikely". My economic game theory went something like this...
Given the option to mine no TXNs or to mine TXNs below 1000 s/kB, miners would always choose anything over nothing
The cost of including a TXN, is practical nothing in comparison to the cost of hashing a block. The TXNs are just included in the root of the block header, so not really a heavy expense. Perhaps I'm overthinking it. Maybe most miners just use the default settings and don't waste a moments thought on anything beyond it. Maybe there is an economic factor I'm missing. Ohh well. At least PR #13990 is staying active... Guess I'm just impatient.
Taproot! Everybody wants to have it, somebody wants to make it, nobody knows how to get it! (If you are asking why everybody wants it, see: Technical: Taproot: Why Activate?) (Pedants: I mostly elide over lockin times) Briefly, Taproot is that neat new thing that gets us:
Multisignatures (n-of-n, k-of-n) that are just 1 signature (1-of-1) in length!! (MuSig/Schnorr)
Better privacy!! If all contract participants can agree, just use a multisignature. If there is a dispute, show the contract publicly and have the Bitcoin network resolve it (Taproot/MAST).
Activation lets devs work get back to work on the even newer stuff like!!!
Cross-input signature aggregation!! (transaction with multiple inputs can have a single signature for all inputs) --- needs Schnorr, but some more work needed to ensure that the interactions with SCRIPT are okay.
Block validation - Schnorr signatures for all taproot spends in a block can be validated in a single operation instead of for each transaction!! Speed up validation and maybe we can actually afford to increase block sizes (maybe)!!
SIGHASH_ANYPREVOUT - you know, for Decker-Russell-Osuntokun ("eltoo") magic!!!
OP_CHECKTEMPLATEVERIFY - vaulty vaults without requiring storing signatures, just transaction details!!
So yes, let's activate taproot!
The SegWit Wars
The biggest problem with activating Taproot is PTSD from the previous softfork, SegWit. Pieter Wuille, one of the authors of the current Taproot proposal, has consistently held the position that he will not discuss activation, and will accept whatever activation process is imposed on Taproot. Other developers have expressed similar opinions. So what happened with SegWit activation that was so traumatic? SegWit used the BIP9 activation method. Let's dive into BIP9!
bit - A field in the block header, the nVersion, has a number of bits. By setting a particular bit, the miner making the block indicates that it has upgraded its software to support a particular soft fork. The bit parameter for a BIP9 activation is which bit in this nVersion is used to indicate that the miner has upgraded software for a particular soft fork.
timeout - a time limit, expressed as an end date. If this timeout is reached without sufficient number of miners signaling that they upgraded, then the activation fails and Bitcoin Core goes back to the drawing board.
Now there are other parameters (name, starttime) but they are not anywhere near as important as the above two. A number that is not a parameter, is 95%. Basically, activation of a BIP9 softfork is considered as actually succeeding if at least 95% of blocks in the last 2 weeks had the specified bit in the nVersion set. If less than 95% had this bit set before the timeout, then the upgrade fails and never goes into the network. This is not a parameter: it is a constant defined by BIP9, and developers using BIP9 activation cannot change this. So, first some simple questions and their answers:
Why not just set a day when everyone starts imposing the new rules of the softfork?
This was done classically (in the days when Satoshi was still among us). But this might argued to put too much power to developers, since there would be no way to reject an upgrade without possible bad consequences. For example, developers might package an upgrade that the users do not want, together with vital security bugfixes. Either you live without vital security bugfixes and hire some other developers to fix it for you (which can be difficult, presumably the best developers are already the ones working on the codebase) or you get the vital security bugfixes and implicitly support the upgrade you might not want.
Sure, you could fork the code yourself (the ultimate threat in the FOSS world) and hire another set of developers who aren't assholes to do the dreary maintenance work of fixing security bugs, but Bitcoin needs strong bug-for-bug compatibility so everyone should really congregate around a single codebase.
Basically: even the devs do not want this power, because they fear being coerced into putting "upgrades" that are detrimental to users. Satoshi got a pass because nobody knew who he was and how to coerce him.
Suppose the threshold were lower, like 51%. If so, after activation, somebody can disrupt the Bitcoin network by creating a transaction that is valid under the pre-softfork rules, but are invalid under the post-softfork rules. Upgraded nodes would reject it, but 49% of miners would accept it and include it in a block (which makes the block invalid) And then the same 49% would accept the invalid block and build on top of that, possibly creating a short chain of doomed invalid blocks that confirm an invalid spend. This can confuse SPV wallets, who might see multiple confirmations of a transaction and accept the funds, but later find that in fact it is invalid under the now-activated softfork rules.
Thus, a very high threshold was imposed. 95% is considered safe. 50% is definitely not safe. Due to variance in the mining process, 80% could also be potentially unsafe (i.e. 80% of blocks signaling might have a good chance of coming from only 60% of miners), so a threshold of 95% was considered "safe enough for Bitcoin work".
Why have a timeout that disables the upgrade?
Before BIP9, what was used was either flag day or BIP34. BIP34 had no flag day of activation or a bit, instead, it was just a 95% threshold to signal an nVersion value greater than a specific value. Actually, it was two thresholds: at 75%, blocks with the new nVersion would have the new softfork rules imposed, but at 95% blocks with the old nVersion would be rejected (and only the new blocks, with the new softfork rules, were accepted). For one, between 75% and 95%, there was a situation where the softfork was only "partially imposed", only blocks signaling the new rules would actually have those rules, but blocks with the old rules were still valid. This was fine for BIP34, which only added rules for miners with negligible use for non-miners.
The reasons miners signalled support was because they felt they were being pressured to signal support. So they signalled support, with plans to actually upgrade later, but because of the widespread signalling, the new BIP66 version locked in before upgrade plans were finished. Thus, the timeout that disables the upgrade was added in BIP9 to allow miners an escape hatch.
The Great Battles of the SegWit Wars
SegWit not only fixed transaction malleability, it also created a practical softforkable blocksize increase that also rebalanced weights so that the cost of spending a UTXO is about the same as the cost of creating UTXOs (and spending UTXOs is "better" since it limits the size of the UTXO set that every fullnode has to maintain). So SegWit was written, the activation was decided to be BIP9, and then.... miner signalling stalled at below 75%. Thus were the Great SegWit Wars started.
BIP9 Feature Hostage
If you are a miner with at least 5% global hashpower, you can hold a BIP9-activated softfork hostage. You might even secretly want the softfork to actually push through. But you might want to extract concession from the users and the developers. Like removing the halvening. Or raising or even removing the block size caps (which helps larger miners more than smaller miners, making it easier to become a bigger fish that eats all the smaller fishes). Or whatever. With BIP9, you can hold the softfork hostage. You just hold out and refuse to signal. You tell everyone you will signal, if and only if certain concessions are given to you. This ability by miners to hold a feature hostage was enabled because of the miner-exit allowed by the timeout on BIP9. Prior to that, miners were considered little more than expendable security guards, paid for the risk they take to secure the network, but not special in the grand scheme of Bitcoin.
ASICBoost was a novel way of optimizing SHA256 mining, by taking advantage of the structure of the 80-byte header that is hashed in order to perform proof-of-work. The details of ASICBoost are out-of-scope here but you can read about it elsewhere Here is a short summary of the two types of ASICBoost, relevant to the activation discussion.
Overt ASICBoost - Manipulates the unused bits in nVersion to reduce power consumption in mining.
Covert ASICBoost - Manipulates the order of transactions in the block to reduce power consumption in mining.
Now, "overt" means "obvious", while "covert" means hidden. Overt ASICBoost is obvious because nVersion bits that are not currently in use for BIP9 activations are usually 0 by default, so setting those bits to 1 makes it obvious that you are doing something weird (namely, Overt ASICBoost). Covert ASICBoost is non-obvious because the order of transactions in a block are up to the miner anyway, so the miner rearranging the transactions in order to get lower power consumption is not going to be detected. Unfortunately, while Overt ASICBoost was compatible with SegWit, Covert ASICBoost was not. This is because, pre-SegWit, only the block header Merkle tree committed to the transaction ordering. However, with SegWit, another Merkle tree exists, which commits to transaction ordering as well. Covert ASICBoost would require more computation to manipulate two Merkle trees, obviating the power benefits of Covert ASICBoost anyway. Now, miners want to use ASICBoost (indeed, about 60->70% of current miners probably use the Overt ASICBoost nowadays; if you have a Bitcoin fullnode running you will see the logs with lots of "60 of last 100 blocks had unexpected versions" which is exactly what you would see with the nVersion manipulation that Overt ASICBoost does). But remember: ASICBoost was, at around the time, a novel improvement. Not all miners had ASICBoost hardware. Those who did, did not want it known that they had ASICBoost hardware, and wanted to do Covert ASICBoost! But Covert ASICBoost is incompatible with SegWit, because SegWit actually has two Merkle trees of transaction data, and Covert ASICBoost works by fudging around with transaction ordering in a block, and recomputing two Merkle Trees is more expensive than recomputing just one (and loses the ASICBoost advantage). Of course, those miners that wanted Covert ASICBoost did not want to openly admit that they had ASICBoost hardware, they wanted to keep their advantage secret because miners are strongly competitive in a very tight market. And doing ASICBoost Covertly was just the ticket, but they could not work post-SegWit. Fortunately, due to the BIP9 activation process, they could hold SegWit hostage while covertly taking advantage of Covert ASICBoost!
UASF: BIP148 and BIP8
When the incompatibility between Covert ASICBoost and SegWit was realized, still, activation of SegWit stalled, and miners were still not openly claiming that ASICBoost was related to non-activation of SegWit. Eventually, a new proposal was created: BIP148. With this rule, 3 months before the end of the SegWit timeout, nodes would reject blocks that did not signal SegWit. Thus, 3 months before SegWit timeout, BIP148 would force activation of SegWit. This proposal was not accepted by Bitcoin Core, due to the shortening of the timeout (it effectively times out 3 months before the initial SegWit timeout). Instead, a fork of Bitcoin Core was created which added the patch to comply with BIP148. This was claimed as a User Activated Soft Fork, UASF, since users could freely download the alternate fork rather than sticking with the developers of Bitcoin Core. Now, BIP148 effectively is just a BIP9 activation, except at its (earlier) timeout, the new rules would be activated anyway (instead of the BIP9-mandated behavior that the upgrade is cancelled at the end of the timeout). BIP148 was actually inspired by the BIP8 proposal (the link here is a historical version; BIP8 has been updated recently, precisely in preparation for Taproot activation). BIP8 is basically BIP9, but at the end of timeout, the softfork is activated anyway rather than cancelled. This removed the ability of miners to hold the softfork hostage. At best, they can delay the activation, but not stop it entirely by holding out as in BIP9. Of course, this implies risk that not all miners have upgraded before activation, leading to possible losses for SPV users, as well as again re-pressuring miners to signal activation, possibly without the miners actually upgrading their software to properly impose the new softfork rules.
BIP91, SegWit2X, and The Aftermath
BIP148 inspired countermeasures, possibly from the Covert ASiCBoost miners, possibly from concerned users who wanted to offer concessions to miners. To this day, the common name for BIP148 - UASF - remains an emotionally-charged rallying cry for parts of the Bitcoin community. One of these was SegWit2X. This was brokered in a deal between some Bitcoin personalities at a conference in New York, and thus part of the so-called "New York Agreement" or NYA, another emotionally-charged acronym. The text of the NYA was basically:
Set up a new activation threshold at 80% signalled at bit 4 (vs bit 1 for SegWit).
When this 80% signalling was reached, miners would require that bit 1 for SegWit be signalled to achive the 95% activation needed for SegWit.
If the bit 4 signalling reached 80%, increase the block weight limit from the SegWit 4000000 to the SegWit2X 8000000, 6 months after bit 1 activation.
The first item above was coded in BIP91. Unfortunately, if you read the BIP91, independently of NYA, you might come to the conclusion that BIP91 was only about lowering the threshold to 80%. In particular, BIP91 never mentions anything about the second point above, it never mentions that bit 4 80% threshold would also signal for a later hardfork increase in weight limit. Because of this, even though there are claims that NYA (SegWit2X) reached 80% dominance, a close reading of BIP91 shows that the 80% dominance was only for SegWit activation, without necessarily a later 2x capacity hardfork (SegWit2X). This ambiguity of bit 4 (NYA says it includes a 2x capacity hardfork, BIP91 says it does not) has continued to be a thorn in blocksize debates later. Economically speaking, Bitcoin futures between SegWit and SegWit2X showed strong economic dominance in favor of SegWit (SegWit2X futures were traded at a fraction in value of SegWit futures: I personally made a tidy but small amount of money betting against SegWit2X in the futures market), so suggesting that NYA achieved 80% dominance even in mining is laughable, but the NYA text that ties bit 4 to SegWit2X still exists. Historically, BIP91 triggered which caused SegWit to activate before the BIP148 shorter timeout. BIP148 proponents continue to hold this day that it was the BIP148 shorter timeout and no-compromises-activate-on-August-1 that made miners flock to BIP91 as a face-saving tactic that actually removed the second clause of NYA. NYA supporters keep pointing to the bit 4 text in the NYA and the historical activation of BIP91 as a failed promise by Bitcoin developers.
We have discussed BIP8: roughly, it has bit and timeout, if 95% of miners signal bit it activates, at the end of timeout it activates. (EDIT: BIP8 has had recent updates: at the end of timeout it can now activate or fail. For the most part, in the below text "BIP8", means BIP8-and-activate-at-timeout, and "BIP9" means BIP8-and-fail-at-timeout) So let's take a look at Modern Softfork Activation!
Modern Softfork Activation
This is a more complex activation method, composed of BIP9 and BIP8 as supcomponents.
First have a 12-month BIP9 (fail at timeout).
If the above fails to activate, have a 6-month discussion period during which users and developers and miners discuss whether to continue to step 3.
Have a 24-month BIP8 (activate at timeout).
The total above is 42 months, if you are counting: 3.5 years worst-case activation. The logic here is that if there are no problems, BIP9 will work just fine anyway. And if there are problems, the 6-month period should weed it out. Finally, miners cannot hold the feature hostage since the 24-month BIP8 period will exist anyway.
PSA: Being Resilient to Upgrades
Software is very birttle. Anyone who has been using software for a long time has experienced something like this:
You hear a new version of your favorite software has a nice new feature.
Excited, you install the new version.
You find that the new version has subtle incompatibilities with your current workflow.
You are sad and downgrade to the older version.
You find out that the new version has changed your files in incompatible ways that the old version cannot work with anymore.
You tearfully reinstall the newer version and figure out how to get your lost productivity now that you have to adapt to a new workflow
If you are a technically-competent user, you might codify your workflow into a bunch of programs. And then you upgrade one of the external pieces of software you are using, and find that it has a subtle incompatibility with your current workflow which is based on a bunch of simple programs you wrote yourself. And if those simple programs are used as the basis of some important production system, you hve just screwed up because you upgraded software on an important production system. And well, one of the issues with new softfork activation is that if not enough people (users and miners) upgrade to the newest Bitcoin software, the security of the new softfork rules are at risk. Upgrading software of any kind is always a risk, and the more software you build on top of the software-being-upgraded, the greater you risk your tower of software collapsing while you change its foundations. So if you have some complex Bitcoin-manipulating system with Bitcoin somewhere at the foundations, consider running two Bitcoin nodes:
One is a "stable-version" Bitcoin node. Once it has synced, set it up to connect=x.x.x.x to the second node below (so that your ISP bandwidth is only spent on the second node). Use this node to run all your software: it's a stable version that you don't change for long periods of time. Enable txiindex, disable pruning, whatever your software needs.
The other is an "always-up-to-date" Bitcoin Node. Keep its stoarge down with pruning (initially sync it off the "stable-version" node). You can't use blocksonly if your "stable-version" node needs to send transactions, but otherwise this "always-up-to-date" Bitcoin node can be kept as a low-resource node, so you can run both nodes in the same machine.
When a new Bitcoin version comes up, you just upgrade the "always-up-to-date" Bitcoin node. This protects you if a future softfork activates, you will only receive valid Bitcoin blocks and transactions. Since this node has nothing running on top of it, it is just a special peer of the "stable-version" node, any software incompatibilities with your system software do not exist. Your "stable-version" Bitcoin node remains the same version until you are ready to actually upgrade this node and are prepared to rewrite most of the software you have running on top of it due to version compatibility problems. When upgrading the "always-up-to-date", you can bring it down safely and then start it later. Your "stable-version" wil keep running, disconnected from the network, but otherwise still available for whatever queries. You do need some system to stop the "always-up-to-date" node if for any reason the "stable-version" goes down (otherwisee if the "always-up-to-date" advances its pruning window past what your "stable-version" has, the "stable-version" cannot sync afterwards), but if you are technically competent enough that you need to do this, you are technically competent enough to write such a trivial monitor program (EDIT: gmax notes you can adjust the pruning window by RPC commands to help with this as well). This recommendation is from gmaxwell on IRC, by the way.
Topic originally posted in Bitcoin by almkglor [link]
This is a follow-up on https://old.reddit.com/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/ Taproot! Everybody wants it!! But... you might ask yourself: sure, everybody else wants it, but why would I, sovereign Bitcoin HODLer, want it? Surely I can be better than everybody else because I swapped XXX fiat for Bitcoin unlike all those nocoiners? And it is important for you to know the reasons why you, o sovereign Bitcoiner, would want Taproot activated. After all, your nodes (or the nodes your wallets use, which if you are SPV, you hopefully can pester to your wallet vendoimplementor about) need to be upgraded in order for Taproot activation to actually succeed instead of becoming a hot sticky mess. First, let's consider some principles of Bitcoin.
You the HODLer should be the one who controls where your money goes. Your keys, your coins.
You the HODLer should be able to coordinate and make contracts with other people regarding your funds.
You the HODLer should be able to do the above without anyone watching over your shoulder and judging you.
I'm sure most of us here would agree that the above are very important principles of Bitcoin and that these are principles we would not be willing to remove. If anything, we would want those principles strengthened (especially the last one, financial privacy, which current Bitcoin is only sporadically strong with: you can get privacy, it just requires effort to do so). So, how does Taproot affect those principles?
Taproot and Your /Coins
Most HODLers probably HODL their coins in singlesig addresses. Sadly, switching to Taproot would do very little for you (it gives a mild discount at spend time, at the cost of a mild increase in fee at receive time (paid by whoever sends to you, so if it's a self-send from a P2PKH or bech32 address, you pay for this); mostly a wash). (technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash, so the Taproot output spends 12 bytes more; spending from a P2WPKH requires revealing a 32-byte public key later, which is not needed with Taproot, and Taproot signatures are about 9 bytes smaller than P2WPKH signatures, but the 32 bytes plus 9 bytes is divided by 4 because of the witness discount, so it saves about 11 bytes; mostly a wash, it increases blockweight by about 1 virtual byte, 4 weight for each Taproot-output-input, compared to P2WPKH-output-input). However, as your HODLings grow in value, you might start wondering if multisignature k-of-n setups might be better for the security of your savings. And it is in multisignature that Taproot starts to give benefits! Taproot switches to using Schnorr signing scheme. Schnorr makes key aggregation -- constructing a single public key from multiple public keys -- almost as trivial as adding numbers together. "Almost" because it involves some fairly advanced math instead of simple boring number adding, but hey when was the last time you added up your grocery list prices by hand huh? With current P2SH and P2WSH multisignature schemes, if you have a 2-of-3 setup, then to spend, you need to provide two different signatures from two different public keys. With Taproot, you can create, using special moon math, a single public key that represents your 2-of-3 setup. Then you just put two of your devices together, have them communicate to each other (this can be done airgapped, in theory, by sending QR codes: the software to do this is not even being built yet, but that's because Taproot hasn't activated yet!), and they will make a single signature to authorize any spend from your 2-of-3 address. That's 73 witness bytes -- 18.25 virtual bytes -- of signatures you save! And if you decide that your current setup with 1-of-1 P2PKH / P2WPKH addresses is just fine as-is: well, that's the whole point of a softfork: backwards-compatibility; you can receive from Taproot users just fine, and once your wallet is updated for Taproot-sending support, you can send to Taproot users just fine as well! (P2WPKH and P2WSH -- SegWit v0 -- addresses start with bc1q; Taproot -- SegWit v1 --- addresses start with bc1p, in case you wanted to know the difference; in bech32 q is 0, p is 1) Now how about HODLers who keep all, or some, of their coins on custodial services? Well, any custodial service worth its salt would be doing at least 2-of-3, or probably something even bigger, like 11-of-15. So your custodial service, if it switched to using Taproot internally, could save a lot more (imagine an 11-of-15 getting reduced from 11 signatures to just 1!), which --- we can only hope! --- should translate to lower fees and better customer service from your custodial service! So I think we can say, very accurately, that the Bitcoin principle --- that YOU are in control of your money --- can only be helped by Taproot (if you are doing multisignature), and, because P2PKH and P2WPKH remain validly-usable addresses in a Taproot future, will not be harmed by Taproot. Its benefit to this principle might be small (it mostly only benefits multisignature users) but since it has no drawbacks with this (i.e. singlesig users can continue to use P2WPKH and P2PKH still) this is still a nice, tidy win! (even singlesig users get a minor benefit, in that multisig users will now reduce their blockchain space footprint, so that fees can be kept low for everybody; so for example even if you have your single set of private keys engraved on titanium plates sealed in an airtight box stored in a safe buried in a desert protected by angry nomads riding giant sandworms because you're the frickin' Kwisatz Haderach, you still gain some benefit from Taproot) And here's the important part: if P2PKH/P2WPKH is working perfectly fine with you and you decide to never use Taproot yourself, Taproot will not affect you detrimentally. First do no harm!
Taproot and Your Contracts
No one is an island, no one lives alone. Give and you shall receive. You know: by trading with other people, you can gain expertise in some obscure little necessity of the world (and greatly increase your productivity in that little field), and then trade the products of your expertise for necessities other people have created, all of you thereby gaining gains from trade. So, contracts, which are basically enforceable agreements that facilitate trading with people who you do not personally know and therefore might not trust. Let's start with a simple example. You want to buy some gewgaws from somebody. But you don't know them personally. The seller wants the money, you want their gewgaws, but because of the lack of trust (you don't know them!! what if they're scammers??) neither of you can benefit from gains from trade. However, suppose both of you know of some entity that both of you trust. That entity can act as a trusted escrow. The entity provides you security: this enables the trade, allowing both of you to get gains from trade. In Bitcoin-land, this can be implemented as a 2-of-3 multisignature. The three signatories in the multisgnature would be you, the gewgaw seller, and the escrow. You put the payment for the gewgaws into this 2-of-3 multisignature address. Now, suppose it turns out neither of you are scammers (whaaaat!). You receive the gewgaws just fine and you're willing to pay up for them. Then you and the gewgaw seller just sign a transaction --- you and the gewgaw seller are 2, sufficient to trigger the 2-of-3 --- that spends from the 2-of-3 address to a singlesig the gewgaw seller wants (or whatever address the gewgaw seller wants). But suppose some problem arises. The seller gave you gawgews instead of gewgaws. Or you decided to keep the gewgaws but not sign the transaction to release the funds to the seller. In either case, the escrow is notified, and if it can sign with you to refund the funds back to you (if the seller was a scammer) or it can sign with the seller to forward the funds to the seller (if you were a scammer). Taproot helps with this: like mentioned above, it allows multisignature setups to produce only one signature, reducing blockchain space usage, and thus making contracts --- which require multiple people, by definition, you don't make contracts with yourself --- is made cheaper (which we hope enables more of these setups to happen for more gains from trade for everyone, also, moon and lambos). (technology-wise, it's easier to make an n-of-n than a k-of-n, making a k-of-n would require a complex setup involving a long ritual with many communication rounds between the n participants, but an n-of-n can be done trivially with some moon math. You can, however, make what is effectively a 2-of-3 by using a three-branch SCRIPT: either 2-of-2 of you and seller, OR 2-of-2 of you and escrow, OR 2-of-2 of escrow and seller. Fortunately, Taproot adds a facility to embed a SCRIPT inside a public key, so you can have a 2-of-2 Taprooted address (between you and seller) with a SCRIPT branch that can instead be spent with 2-of-2 (you + escrow) OR 2-of-2 (seller + escrow), which implements the three-branched SCRIPT above. If neither of you are scammers (hopefully the common case) then you both sign using your keys and never have to contact the escrow, since you are just using the escrow public key without coordinating with them (because n-of-n is trivial but k-of-n requires setup with communication rounds), so in the "best case" where both of you are honest traders, you also get a privacy boost, in that the escrow never learns you have been trading on gewgaws, I mean ewww, gawgews are much better than gewgaws and therefore I now judge you for being a gewgaw enthusiast, you filthy gewgawer).
Taproot and Your Contracts, Part 2: Cryptographic Boogaloo
Now suppose you want to buy some data instead of things. For example, maybe you have some closed-source software in trial mode installed, and want to pay the developer for the full version. You want to pay for an activation code. This can be done, today, by using an HTLC. The developer tells you the hash of the activation code. You pay to an HTLC, paying out to the developer if it reveals the preimage (the activation code), or refunding the money back to you after a pre-agreed timeout. If the developer claims the funds, it has to reveal the preimage, which is the activation code, and you can now activate your software. If the developer does not claim the funds by the timeout, you get refunded. And you can do that, with HTLCs, today. Of course, HTLCs do have problems:
Privacy. Everyone scraping the Bitcoin blockchain can see any HTLCs, and preimages used to claim them.
This can be mitigated by using offchain techniques so HTLCs are never published onchain in the happy case. Lightning would probably in practice be the easiest way to do this offchain. Of course, there are practical limits to what you can pay on Lightning. If you are buying something expensive, then Lightning might not be practical. For example, the "software" you are activating is really the firmware of a car, and what you are buying is not the software really but the car itself (with the activation of the car firmware being equivalent to getting the car keys).
Even offchain techniques need an onchain escape hatch in case of unresponsiveness! This means that, if something bad happens during payment, the HTLC might end up being published onchain anyway, revealing the fact that some special contract occurred.
And an HTLC that is claimed with a preimage onchain will also publicly reveal the preimage onchain. If that preimage is really the activation key of a software than it can now be pirated. If that preimage is really the activation key for your newly-bought cryptographic car --- well, not your keys, not your car!
Trust requirement. You are trusting the developer that it gives you the hash of an actual valid activation key, without any way to validate that the activation key hidden by the hash is actually valid.
Fortunately, with Schnorr (which is enabled by Taproot), we can now use the Scriptless Script constuction by Andrew Poelstra. This Scriptless Script allows a new construction, the PTLC or Pointlocked Timelocked Contract. Instead of hashes and preimages, just replace "hash" with "point" and "preimage" with "scalar". Or as you might know them: "point" is really "public key" and "scalar" is really a "private key". What a PTLC does is that, given a particular public key, the pointlocked branch can be spent only if the spender reveals the private key of the given private key to you. Another nice thing with PTLCs is that they are deniable. What appears onchain is just a single 2-of-2 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige). (Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key). So:
Privacy: PTLCs are private even if done onchain. Nobody else can learn what the private key behind the public key is, except you who knows the adaptor signature that when combined with the complete onchain signature lets you know what the private key of the activation key is. Somebody scraping the blockchain will not learn the same information even if all PTLCs are done onchain!
Lightning is still useful for reducing onchain use, and will also get PTLCs soon after Taproot is activated, but even if something bad happens and a PTLC has to go onchain, it doesn't reveal anything!
Trust issues can be proven more easily with a public-private keypair than with a hash-preimage pair.
For example, the developer of the software you are buying could provide a signature signing a message saying "unlock access to the full version for 1 day". You can check if feeding this message and signature to the program will indeed unlock full-version access for 1 day. Then you can check if the signature is valid for the purported pubkey whose private key you will pay for. If so, you can now believe that getting the private key (by paying for it in a PTLC) would let you generate any number of "unlock access to the full version for 1 day" message+signatures, which is equivalent to getting full access to the software indefinitely.
For the car, the manufacturer can show that signing a message "start the engine" and feeding the signature to the car's fimrware will indeed start the engine, and maybe even let you have a small test drive. You can then check if the signature is valid for the purported pubkey whose privkey you will pay for. If so, you can now believe that gaining knowledge of the privkey will let you start the car engine at any time you want.
(pedantry: the signatures need to be unique else they could be replayed, this can be done with a challenge-response sequence for the car, where the car gathers entropy somehow (it's a car, it probably has a bunch of sensors nowadays so it can get entropy for free) and uses the gathered entropy to challenge you to sign a random number and only start if you are able to sign the random number; for the software, it could record previous signatures somewhere in the developer's cloud server and refuse to run if you try to replay a previously-seen signature.)
Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script. (technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 2-of-2 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.)
Now if you were really paying attention, you might have noticed this parenthetical:
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash...)
So wait, Taproot uses raw 32-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable?? Well, in theory yes. In practice, they probably are not. It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from a P2WPKH/P2PKH pay-to-public-key-hash. When you spend from a P2PKH / P2WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key. So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key. (public keys should be public, that's why they're called public keys, LOL) And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions. So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort. Further, if you have ever, in the past, spent from the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers. For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two.
Current quantum computers can barely crack prime factorization problem for primes of 5 bits.
The 256-bit elliptic curve use by Bitcoin is, by my (possibly wrong) understanding, equivalent to 4096-bit primes, so you can see a pretty big gap between now (5 bit primes) and what is needed (4096 bit primes).
A lot of financial non-Bitcoin systems use the equivalent of 3072-bit primes or less, and are probably easier targets to crack than the equivalent-to-4096-bit-primes Bitcoin.
Quantum computers capable of cracking Bitcoin are still far off.
Pay-to-public-key-hash is not as protective as you might think.
We will probably see banks get cracked before Bitcoin, so the banking system is a useful canary-in-a-coal-mine to see whether we should panic about being quantum vulnerable.
For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 1 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages).
If you are a singlesig HODL-only Bitcoin user, Taproot will not affect you positively or negatively. Importantly: Taproot does no harm!
If you use or intend to use multisig, Taproot will be a positive for you.
If you transact onchain regularly using typical P2PKH/P2WPKH addresses, you get a minor reduction in feerates since multisig users will likely switch to Taproot to get smaller tx sizes, freeing up blockspace for yours.
If you are using multiparticipant setups for special systems of trade, Taproot will be a positive for you.
Remember: Lightning channels are multipartiicpiant setups for special systems of lightning-fast offchain trades!
I Wanna Be The Taprooter!
So, do you want to help activate Taproot? Here's what you, mister sovereign Bitcoin HODLer, can do!
If you have developer experience especially in C, C++, or related languages
Review the Taproot code! There is one pull request in Bitcoin Core, and one in libsecp256k1. I deliberately am not putting links here, to avoid brigades of nontechnical but enthusiastic people leaving pointless reviews, but if you are qualified you know how to find them!
But I am not a cryptographeBitcoin Core contributomathematician/someone as awesome as Pieter Wuille
That's perfectly fine! The cryptographers have been over the code already and agree the math is right and the implementation is right. What is wanted is the dreary dreary dreary software engineering: are the comments comprehensive and understandable? no misspellings in the comments? variable names understandable? reasonable function naming convention? misleading coding style? off-by-one errors in loops? conditions not covered by tests? accidental mixups of variables with the same types? missing frees? read-before-init? better test coverage of suspicious-looking code? missing or mismatching header guards? portability issues? consistent coding style? you know, stuff any coder with a few years of experience in coding anything might be able to catch. With enough eyes all bugs are shallow!
If you are running a mining pool/mining operation/exchange/custodial service/SPV server
Be prepared to upgrade!
One of the typical issues with upgrading software is that subtle incompatibilities with your current custom programs tend to arise, disrupting operations and potentially losing income due to downtime. If so, consider moving to the two-node setup suggested by gmax, which is in the last section of my previous post. With this, you have an up-to-date "public" node and a fixed-version "private" node, with the public node protecting the private node from any invalid chainsplits or invalid transactions. Moving to this setup from a typical one-node setup should be smooth and should not disrupt operations (too much).
If you are running your own fullnode for fun or for your own wallet
Be prepared to upgrade! The more nodes validating the new rules (even if you are a non-mining node!), the safer every softfork will be!
If you are using an SPV wallet or custodial wallet/service (including hardware wallets using the software of the wallet provider)
Contact your wallet provider / SPV server and ask for a statement on whether they support Taproot, and whether they are prepared to upgrade for Taproot! Make it known to them that Taproot is something you want!
But I Hate Taproot!!
Raise your objections to Taproot now, or forever hold your peace! Maybe you can raise them here and some of the devs (probably nullc, he goes everywhere, even in rbtc!) might be able to see your objections! Or if your objections are very technical, head over to the appropriate pull request and object away!
Maybe you simply misunderstand something, and we can clarify it here!
Or maybe you do have a good objection, and we can make Taproot better by finding a solution for it!
almkglor your post has been copied because one or more comments in this topic have been removed. This copy will preserve unmoderated topic. If you would like to opt-out, please send a message using [this link].
Only 20% of the computing power is required to attack BTC? Selfish mining author proposes new BDoS scheme sparks controversy
Researchers at Cornell University and IC3 Group have announced that they have discovered a denial-of-service attack against the "Satoshi Consensus Protocol Blockchain" and call it BDoS, which is much cheaper than previous DoS attacks Much more (only 20% of the computing power). The researchers showed how attackers induced rational miners to stop mining and proposed a mitigation measure. This research has also attracted the attention of the crypto community, which was recognized by the founder of Ethereum, vitalik, and independent blockchain security auditor Sergio Demian Lerner said the research was interesting. He mentioned that RSK can provide additional incentives. In order to reduce the problem of miners, it is not affected by this attack.
You can have a market for blockspace without full blocks
In a recent comment, an bitcoin mod claimed that you need full blocks for a fee market. That is simply not true. Over a year ago I estimated the marginal cost of Bitcoin BCH/BSV transactions. I got a number of about 2 cents/kB: a number greater than 0, mostly dominated by bandwidth costs. What the Core developers are doing with their "fee market" is gaming the metric. By artificially restricting the supply of blockspace, they made the supply of blockspace inelastic. Goods with inelastic supply tend to have very volatile prices in response to small changes in demand. Wildly varying fees are not a quality you want in a payments system. But it is even worse than that. Note in my analysis that I list POW as a fixed cost. The reason is that due to the nature of hashing, each block header can represent an arbitrary number of transactions for almost no additional work. The asymptotic growth rate of POW with more transactions is O(1). That makes the overhead of processing transactions rounding error for miners. BTC on the other hand, makes POW a marginal cost of transactions. The POW becomes O(n): increasing with the number of transactions processed. The way the BTC "fee market" works: users can bribe miners to spin up more hash-power by spending at least $50/kB (at current prices) to get their transaction in the next block. However, even such a bribe still only provides temporary relief. If too many people do it: the difficulty adjustment algorithm will kick in and re-reduce the supply of blockspace after 2 weeks. Note: this comment was originally a PM to the mod in question. I removed identifying information and link to the other sub.
Full node stopped synching: ERROR: AcceptBlockHeader: block 00... is marked invalid
A full node was synching normally until it started to repeatedly printing the error 2020-06-30T23:17:03Z ERROR: AcceptBlockHeader: block 0000000000000000000a6a56cf649eaa2f39d8ba47880c2a1856c5d5c597826e is marked invalid
+☎ 𝟖𝟖𝟖̲-𝟖𝟔̳𝟏-𝟗𝟕𝟒𝟐̳☎ Blockchain technical support number ~ BlockChain CusTomEr Service Usa
+☎ 𝟖𝟖𝟖̲-𝟖𝟔̳𝟏-𝟗𝟕𝟒𝟐̳☎ Blockchain technical support number ~ BlockChain CusTomEr Service Usa +☎ 𝟖𝟖𝟖̲-𝟖𝟔̳𝟏-𝟗𝟕𝟒𝟐̳☎ Blockchain technical support number ~ BlockChain CusTomEr Service Usa +☎ 𝟖𝟖𝟖̲-𝟖𝟔̳𝟏-𝟗𝟕𝟒𝟐̳☎ Blockchain technical support number ~ BlockChain CusTomEr Service Usa +☎ 𝟖𝟖𝟖̲-𝟖𝟔̳𝟏-𝟗𝟕𝟒𝟐̳☎ Blockchain is a sort of conveyed record for keeping up a perpetual and sealed record of conditional information. A blockchain capacities as a decentralized information base that is overseen by PCs having a place with a distributed (P2P) organize. Every one of the PCs in the disseminated arrange keeps up a duplicate of the record to forestall a solitary purpose of disappointment (SPOF) and all duplicates are refreshed and approved at the same time. Before, blockchains were regularly connected with computerized monetary standards, for example, Bitcoin, or substitute variants of Bitcoin like Bitcoin Cash. Today, blockchain applications are being investigated in numerous businesses as a protected and practical approach to make and deal with a disseminated information base and keep up records for advanced exchanges of various types. Blockchain wallet customer service Blockchain wallet support number Blockchain technical support number Blockchain contact number Contact number for Blockchain Contact wallet Blockchain number How blockchain functions A blockchain record comprises of two kinds of records, singular exchanges and squares. The main square comprises of a header and information that relates to exchanges occurring inside a set timespan. The square's timestamp is utilized to help make an alphanumeric string called a hash. After the main square has been made, each resulting hinder in the record utilizes the past square's hash to compute its own hash. Before another square can be added to the chain, its genuineness must be checked by a computational cycle called approval or agreement. Now in the blockchain cycle, a greater part of hubs in the system must concur the new square's hash has been determined accurately. Agreement guarantees that all duplicates of the appropriated record share a similar state. When a square has been included, it very well may be referred to in resulting squares, however it can't be changed. In the event that somebody endeavors to trade out a square, the hashes for past and resulting squares will likewise change and upset the record's shared state. At the point when agreement is not, at this point conceivable, different PCs in the system know that an issue has happened and no new squares will be added to the chain until the issue is fathomed. Regularly, the square causing the mistake will be disposed of and the agreement cycle will be rehashed. Blockchain stages Blockchain stages can be either consent less or permissioned . In an open, permissionless blockchain like Bitcoin, each hub in the system can lead exchanges and exchange charges and take an interest in the agreement cycle. In a private, permissioned chain like Multichain, each hub may have the option to perform exchanges, however cooperation in the agreement cycle is confined to a predetermined number of affirmed hub. Blockchain agreement/approval calculations Picking which agreement calculation to utilize is maybe the most urgent part of choosing a blockchain stage. There are four standard techniques blockchain and other circulated information base stages use to show up at an agreement. By and large, open stages pick calculations like Proof of Work since they require a ton of handling capacity to figure, and are simple for other system hubs to confirm. Verification of-work calculation (PoW) Functional byzantine adaptation to internal failure calculation (PBFT) Verification of-stake calculation (PoS) Appointed verification of-stake calculation ( DPoS ) Blockchain wallet customer service Blockchain wallet support number Blockchain technical support number Blockchain contact number Contact number for Blockchain Contact wallet Blockchain number
I want to educate myself on bitcoin and the benefits and disadvantages it yields, especially in the future. I don’t know where to get started, and would greatly appreciate couple articles or other credible sources to help me out.
How do pools coordinate their miners so that no one wastes work?
Hello, I am trying to understand how a pool operator makes sure that miners do not check the same nonce and hence waste time and work. In my head I have the following analogy: I have a bookshelf with 30 books. One of the books has a $10 bill (the reward). A friend and I are checking each book. If we just check the books at random, my friend could check a book I have already opened. So it would be best to coordinate: I start from the left end, he starts from the right end. And we save time. Is there any such coordination by pool operators, or does every miner check nonces at random? Is there latency in communicating the coordination, or is it something that is set once and forever? If so, what happens when new miners join the pool or old one's leave the pool? Thanks a lot in advance!
The king of crypto.... the "pretender" that works better for now.... and the newcomer that obliterates both.... The Bitcoin argument in short is, that Bitcoin is not good enough long term, and a second layer will save the day (lightning network) The Bitcoin Cash argument is that the old Bitcoin was fine, and internet infrastructure will allow it to work in the future... The Nano argument is that it is a newer, smarter, more scalable design, and internet infrastructure will allow it to work in the future... I like the last one.
The main process for the network is the transaction process, which is technically related to the addition of a new block to the ledger. Adding a block is carried out according to a certain consistent algorithm - the consensus algorithm. At the same time, consensus is ensured by constancy: each network node reaches the same state after processing each transaction and each block. That is, the consensus algorithm ensures that all nodes of the network always have the same version of the blockchain and eliminates conflicts between nodes. The most popular of these are two varieties: Proof of Work and Proof of Stake. The Proof of Work (PoW) algorithm requires the author of a new block to solve a mathematical problem, and this problem is solved only by direct enumeration of the value. The classic option is to find a special value for the hash of the block header containing a link to the previous block implemented in Bitcoin. The task is solved by all applicants for the addition of the block, and the chance to solve it faster than others and, accordingly, receive a reward depends on the amount of available computing power. The greater the processing power of the node - the higher the chance. The necessary speed at the same time is provided by the selection of the complexity of the problem to be solved, depending on the aggregate power of the network nodes. Proof of Stake (PoS) is an alternative to PoW and a solution to the problem of high electricity costs for Bitcoin mining. However, the idea of PoS was mentioned back in 2011 at the Bitcointalk forum. Instead of mining in PoS, network participants freeze a certain number of tokens in wallets. After that, the algorithm selects among the participants the next block producer, depending on the size of the bet. In this way, participants reinforce good faith not with the cost of computing, but directly with assets within the network. In PZM Cash, we abandoned the delegated Proof of Stake and applied the significantly improved “classic” PoS algorithm. Due to this, the opportunity to participate in the work of the network (and receive remuneration) has received a very wide circle of users - there are no significant restrictions or any significant barriers to this. POS is also subject to centralization, however, buying coins is much easier than buying equipment and setting up mining (as in POW), which provides an internal mechanism that restrains monopolization due to the large number of coin purchasers and owners. https://preview.redd.it/ydkjylyf43q41.png?width=1200&format=png&auto=webp&s=f485f43b210318f8b2ae7580c75cf884a1271311
Trouble understanding proof of work as validation.
Hello, I'm just starting to look into how Bitcoin actually works. I was looking at videos explaining it and im not understanding why it's considered valid. Here is the example in seeing. Say I am a dishonest person and want to take down Bitcoin. Since all of the transactions are verified by blocks with a crypto hash as a signature to be proof of work. What exactly is to stop me from going to the first step in the chain, create a fork from that, and make a bunch of blocks with 0 transactions and sign the last one with a transaction for all the Bitcoin going to me. It seems to be that if there are no transactions the hash would be easy to solve because it's the same one over and over again.
Review and Prospect of Crypto Economy-Development and Evolution of Consensus Mechanism (2)
https://preview.redd.it/a51zsja94db51.png?width=567&format=png&auto=webp&s=99e8080c9e9b1fb5e11cbd70f915f9cb37188f81 Foreword The consensus mechanism is one of the important elements of the blockchain and the core rule of the normal operation of the distributed ledger. It is mainly used to solve the trust problem between people and determine who is responsible for generating new blocks and maintaining the effective unification of the system in the blockchain system. Thus, it has become an everlasting research hot topic in blockchain. This article starts with the concept and role of the consensus mechanism. First, it enables the reader to have a preliminary understanding of the consensus mechanism as a whole; then starting with the two armies and the Byzantine general problem, the evolution of the consensus mechanism is introduced in the order of the time when the consensus mechanism is proposed; Then, it briefly introduces the current mainstream consensus mechanism from three aspects of concept, working principle and representative project, and compares the advantages and disadvantages of the mainstream consensus mechanism; finally, it gives suggestions on how to choose a consensus mechanism for blockchain projects and pointed out the possibility of the future development of the consensus mechanism. Contents First, concept and function of the consensus mechanism 1.1 Concept: The core rules for the normal operation of distributed ledgers 1.2 Role: Solve the trust problem and decide the generation and maintenance of new blocks 1.2.1 Used to solve the trust problem between people 1.2.2 Used to decide who is responsible for generating new blocks and maintaining effective unity in the blockchain system 1.3 Mainstream model of consensus algorithm Second, the origin of the consensus mechanism 2.1 The two armies and the Byzantine generals 2.1.1 The two armies problem 2.1.2 The Byzantine generals problem 2.2 Development history of consensus mechanism 2.2.1 Classification of consensus mechanism 2.2.2 Development frontier of consensus mechanism Third, Common Consensus System Fourth, Selection of consensus mechanism and summary of current situation 4.1 How to choose a consensus mechanism that suits you 4.1.1 Determine whether the final result is important 4.1.2 Determine how fast the application process needs to be 4.1.2 Determining the degree to which the application requires for decentralization 4.1.3 Determine whether the system can be terminated 4.1.4 Select a suitable consensus algorithm after weighing the advantages and disadvantages 4.2 Future development of consensus mechanism Last lecture review: Chapter 1 Concept and Function of Consensus Mechanism plus Chapter 2 Origin of Consensus Mechanism Chapter 3 Common Consensus Mechanisms (Part 1) Figure 6 Summary of relatively mainstream consensus mechanisms 📷 https://preview.redd.it/9r7q3xra4db51.png?width=567&format=png&auto=webp&s=bae5554a596feaac948fae22dffafee98c4318a7 Source: Hasib Anwar, "Consensus Algorithms: The Root Of The Blockchain Technology" The picture above shows 14 relatively mainstream consensus mechanisms summarized by a geek Hasib Anwar, including PoW (Proof of Work), PoS (Proof of Stake), DPoS (Delegated Proof of Stake), LPoS (Lease Proof of Stake), PoET ( Proof of Elapsed Time), PBFT (Practical Byzantine Fault Tolerance), SBFT (Simple Byzantine Fault Tolerance), DBFT (Delegated Byzantine Fault Tolerance), DAG (Directed Acyclic Graph), Proof-of-Activity (Proof of Activity), Proof-of- Importance (Proof of Importance), Proof-of-Capacity (Proof of Capacity), Proof-of-Burn ( Proof of Burn), Proof-of-Weight (Proof of Weight). Next, we will mainly introduce and analyze the top ten consensus mechanisms of the current blockchain. 》POW -Concept: Work proof mechanism. That is, the proof of work means that it takes a certain amount of computer time to confirm the work. -Principle: Figure 7 PoW work proof principle 📷 https://preview.redd.it/xupacdfc4db51.png?width=554&format=png&auto=webp&s=3b6994641f5890804d93dfed9ecfd29308c8e0cc The PoW represented by Bitcoin uses the SHA-256 algorithm function, which is a 256-bit hash algorithm in the password hash function family: Proof of work output = SHA256 (SHA256 (block header)); if (output of proof of work if (output of proof of work >= target value), change the random number, recursive i logic, continue to compare with the target value. New difficulty value = old difficulty value* (time spent by last 2016 blocks /20160 minutes) Target value = maximum target value / difficulty value The maximum target value is a fixed number. If the last 2016 blocks took less than 20160 minutes, then this coefficient will be small, and the target value will be adjusted bigger, if not, the target value will be adjusted smaller. Bitcoin mining difficulty and block generation speed will be inversely proportional to the appropriate adjustment of block generation speed. -Representative applications: BTC, etc. 》POS -Concept: Proof of stake. That is, a mechanism for reaching consensus based on the holding currency. The longer the currency is held, the greater the probability of getting a reward. -Principle: PoS implementation algorithm formula: hash(block_header) = Coin age calculation formula: coinage = number of coins * remaining usage time of coins Among them, coinage means coin age, which means that the older the coin age, the easier it is to get answers. The calculation of the coin age is obtained by multiplying the coins owned by the miner by the remaining usage time of each coin, which also means that the more coins you have, the easier it is to get answers. In this way, pos solves the problem of wasting resources in pow, and miners cannot own 51% coins from the entire network, so it also solves the problem of 51% attacks. -Representative applications: ETH, etc. 》DPoS -Concept: Delegated proof of stake. That is, currency holding investors select super nodes by voting to operate the entire network , similar to the people's congress system. -Principle: The DPOS algorithm is divided into two parts. Elect a group of block producers and schedule production. Election: Only permanent nodes with the right to be elected can be elected, and ultimately only the top N witnesses can be elected. These N individuals must obtain more than 50% of the votes to be successfully elected. In addition, this list will be re-elected at regular intervals. Scheduled production: Under normal circumstances, block producers take turns to generate a block every 3 seconds. Assuming that no producer misses his order, then the chain they produce is bound to be the longest chain. When a witness produces a block, a block needs to be generated every 2s. If the specified time is exceeded, the current witness will lose the right to produce and the right will be transferred to the next witness. Then the witness is not only unpaid, but also may lose his identity. -Representative applications: EOS, etc. 》DPoW -Concept: Delayed proof of work. A new-generation consensus mechanism based on PoB and DPoS. Miners use their own computing power, through the hash algorithm, and finally prove their work, get the corresponding wood, wood is not tradable. After the wood has accumulated to a certain amount, you can go to the burning site to burn the wood. This can achieve a balance between computing power and mining rights. -Principle: In the DPoW-based blockchain, miners are no longer rewarded tokens, but "wood" that can be burned, burning wood. Miners use their own computing power, through the hash algorithm, and finally prove their work, get the corresponding wood, wood is not tradable. After the wood has accumulated to a certain amount, you can go to the burning site to burn the wood. Through a set of algorithms, people who burn more wood or BP or a group of BP can obtain the right to generate blocks in the next event segment, and get rewards (tokens) after successful block generation. Since more than one person may burn wood in a time period, the probability of producing blocks in the next time period is determined by the amount of wood burned by oneself. The more it is burned, the higher the probability of obtaining block rights in the next period. Two node types: notary node and normal node. The 64 notary nodes are elected by the stakeholders of the dPoW blockchain, and the notarized confirmed blocks can be added from the dPoW blockchain to the attached PoW blockchain. Once a block is added, the hash value of the block will be added to the Bitcoin transaction signed by 33 notary nodes, and a hash will be created to the dPow block record of the Bitcoin blockchain. This record has been notarized by most notary nodes in the network. In order to avoid wars on mining between notary nodes, and thereby reduce the efficiency of the network, Komodo designed a mining method that uses a polling mechanism. This method has two operating modes. In the "No Notary" (No Notary) mode, all network nodes can participate in mining, which is similar to the traditional PoW consensus mechanism. In the "Notaries Active" mode, network notaries use a significantly reduced network difficulty rate to mine. In the "Notary Public Activation" mode, each notary public is allowed to mine a block with its current difficulty, while other notary public nodes must use 10 times the difficulty of mining, and all normal nodes use 100 times the difficulty of the notary public node. Figure 8 DPoW operation process without a notary node 📷 https://preview.redd.it/3yuzpemd4db51.png?width=500&format=png&auto=webp&s=f3bc2a1c97b13cb861414d3eb23a312b42ea6547 -Representative applications: CelesOS, Komodo, etc. CelesOS Research Institute丨DPoW consensus mechanism-combustible mining and voting 》PBFT -Concept: Practical Byzantine fault tolerance algorithm. That is, the complexity of the algorithm is reduced from exponential to polynomial level, making the Byzantine fault-tolerant algorithm feasible in practical system applications. -Principle: Figure 9 PBFT algorithm principle 📷 https://preview.redd.it/8as7rgre4db51.png?width=567&format=png&auto=webp&s=372be730af428f991375146efedd5315926af1ca First, the client sends a request to the master node to call the service operation, and then the master node broadcasts other copies of the request. All copies execute the request and send the result back to the client. The client needs to wait for f+1 different replica nodes to return the same result as the final result of the entire operation. Two qualifications: 1. All nodes must be deterministic. That is to say, the results of the operation must be the same under the same conditions and parameters. 2. All nodes must start from the same status. Under these two limited qualifications, even if there are failed replica nodes, the PBFT algorithm agrees on the total order of execution of all non-failed replica nodes, thereby ensuring security. -Representative applications: Tendermint Consensus, etc. Next Lecture: Chapter 3 Common Consensus Mechanisms (Part 2) + Chapter 4 Consensus Mechanism Selection and Status Summary CelesOS As the first DPOW financial blockchain operating system, CelesOS adopts consensus mechanism 3.0 to break through the "impossible triangle", which can provide high TPS while also allowing for decentralization. Committed to creating a financial blockchain operating system that embraces supervision, providing services for financial institutions and the development of applications on the supervision chain, and formulating a role and consensus ecological supervision layer agreement for supervision. The CelesOS team is dedicated to building a bridge between blockchain and regulatory agencies/financial industry. We believe that only blockchain technology that cooperates with regulators will have a real future. We believe in and contribute to achieving this goal. 📷Website https://www.celesos.com/ 📷Telegram https://t.me/celeschain 📷Twitter https://twitter.com/CelesChain 📷Reddit https://www.reddit.com/useCelesOS 📷Medium https://medium.com/@celesos 📷Facebook https://www.facebook.com/CelesOS1 📷Youtube https://www.youtube.com/channel/UC1Xsd8wU957D-R8RQVZPfGA
Hi, im new to blockchain tech and had a question. I understood that in bitcoin miners try and create a hash that Is less than some difficulty. so why can't the miner always choose the number 0? Im sure that my question is dumb and im missing some aspects but I cannot seem to understand them. can someone please fill me in to what im missing? thanks!
I don't even see communication or data reaching the Trezor device after the call. Do I need to add the coin inside other configuration file? Are configurations enough in order to support the coin or I need to implement some features?
The block header is the first piece of information propagated by a node when it finds a valid block solution. Other nodes on the network can validate the node's hash solution and determine whether the proposed block warrants the further checking required to secure its place as the top-most link in the longest chain of valid proof of work. Bitcoin miners commonly make use of two nonce fields: The Nonce field which is included in the block header; The extraNonce field which is part of the Coinbase transaction; Each field includes a counter parameter that is relatively small (32-bits). The hash function cycles through all values of the Nonce field, testing each outcome of the hash ... The version is wrong: I have 02000000 . But the one that appears on the block is . Version 0x20000000 Doing the formatting: 00000020 Calculating the hash of the block: learn me a bitcoin. By Greg Walker. Home; Beginners ; Technical; Explorer; $11,311.19/BTC Buy. Subscribe. Tools. Hash256. Hash160. Reverse Bytes. Hexadecimal. Satoshis. Block Hash. The hash of a block header. A Block Hash is basically a reference number for a block in the blockchain. How do you get a Block Hash? You get a Block Hash by hashing the block header through SHA256 twice. Example ... Previous block header hash: 32 bytes; Merkle root: 32 bytes; Timestamp: 4 bytes; Bits: 4 bytes; Nonce: 4 bytes; The merkle tree hashes all the transactions in the block, the bits field is used to compute the target hash for the header, finally, the nonce is used as a counter to generate new block headers from a given merkle tree.
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube. Nicolas Courtois On Hash Rate 51 and Protection Against Double Spending In Bitcoin and Other Crypto Hash là gì? SHA 256 là gì? Tất cả sẽ được giải đáp trong video này. Để biết thêm chi tiết, vui lòng truy cập https://pinkblockchain.com Blockchain/Bitcoin for beginners 7: Blockchain header: ... Hashing Algorithms and Security - Computerphile - Duration: 8:12. Computerphile 918,796 views. 8:12. Dissecting a P2PKH Bitcoin ... In this video we introduce the basic concepts behind how new blocks are created in the Bitcoin blockchain. We start by taking another look at the blockchain.info website to see some sample blocks ...