Jeffrey Epstein Confidant Ghislaine Maxwell’s Last Reddit
User:Gmaxwell/features - Bitcoin Wiki
User:Gmaxwell/namecoin that sucks less - Bitcoin Wiki
Technical: The Path to Taproot Activation
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.
Newbs might not know this, but bitcoin recently came out of an intense internal drama. Between July 2015 and August 2017 bitcoin was attacked by external forces who were hoping to destroy the very properties that made bitcoin valuable in the first place. This culminated in the creation of segwit and the UASF (user activated soft fork) movement. The UASF was successful, segwit was added to bitcoin and with that the anti-decentralization side left bitcoin altogether and created their own altcoin called bcash. Bitcoin's price was $2500, soon after segwit was activated the price doubled to $5000 and continued rising until a top of $20000 before correcting to where we are today. During this drama, I took time away from writing open source code to help educate and argue on reddit, twitter and other social media. I came up with a reading list for quickly copypasting things. It may be interesting today for newbs or anyone who wants a history lesson on what exactly happened during those two years when bitcoin's very existence as a decentralized low-trust currency was questioned. Now the fight has essentially been won, I try not to comment on reddit that much anymore. There's nothing left to do except wait for Lightning and similar tech to become mature (or better yet, help code it and test it) In this thread you can learn about block sizes, latency, decentralization, segwit, ASICBOOST, lightning network and all the other issues that were debated endlessly for over two years. So when someone tries to get you to invest in bcash, remind them of the time they supported Bitcoin Unlimited. For more threads like this see UASF
Scaling is coming, ignore the FUD. The most important thing for Bitcoin now is for its main chain to keep its main attributes: Antifragility and Immutability, that's what gives it the status as a safe store of value. To use it to buy a cup of coffee it's not a priority (but we will get there later), just like the Internet, built on a solid base and adding all the needed and desired functionalities with second layer apps. Also, Note the massive amount of qualified devs working on Bitcoin and those second layer apps vs the few crappy devs on the roger-coin. Which project do you think has more value in the medium and long term? Edit: Formatting
Scaling is coming, ignore the FUD. The most important thing for Bitcoin now is for its main chain to keep its main attributes: Antifragility and Immutability, that's what gives it the status as a safe store of value. To use it to buy a cup of coffee it's not a priority (but we will get there later), just like the Internet, built on a solid base and adding all the needed and desired functionalities with second layer apps. Also, Note the massive amount of qualified devs working on Bitcoin and those second layer apps vs the few crappy devs on the roger-coin. Which project do you think has more value in the medium and long term?
A politically-charged false dichotomy between SegWit and BU has poisoned the Bitcoin community. This choice divides us unnecessarily. On Sept 9, 2016 gmaxwell proposed that Bitcoin Unlimited support SegWit. I agree with the proposal. Let the Bitcoin Unlimited value proposition rest on the user-defined acceptable block size logic, rather than on "we're not Core." One proposition is technical and market-driven. The other is political and should hold no weight here. No, I don't believe the spin about "SegWit is an immediate block size increase," and I'm not making that argument here. Yes, I know there are dubious economic incentives build into the "block weight" accounting. Yes, I understand the Core devs promised a block size increase but failed to deliver. That's what BU should be all about: block size. Yes, I understand the mods of /bitcoin used censorship to stifle information about competing clients, but that doesn't diminish the technical merits of the Core team's code. Censorship sucks, and it led to the growth of this sub. But moving to parallel conversations polarized us politically. Based on Johnny & Trace vs Ver & Jake debate, you can tell that the Core team is really proud of SegWit and their own technical prowess. Why not put them to the test? Activate SegWit and if fails to deliver on its promised goals, then the case for a hard fork away from the Core team's direction grows stronger. They were demeaning Unlimited's development effort and holding up Core's code as superior. Well if you merge Core's recent code work, then you take that argument off the table (and get tons of bugfixes and performance increases for free). There are too many angles to this debate, and I believe that most of them are just distraction. Let's make the debate about one thing: block size. My personal theory is that if the blocks had filled up one year from now instead of a few months ago, then we'd already have activated SegWit and moved on. We could see how businesses were using the new tech with real users. Instead we get derailed into this huge mess.
Someone asked me why I oppose Segwit recently, and here's what I told them: Largely out of technical objections, and political ones also. I see Segwit as a crudely-designed kludge, and an unnecessary complication to the protocol. Open Transactions was working on a sidechain implementation years ago that didn't require Segwit, it only required deterministic ordering of UTXOs when creating new tx, which still doesn't have a BIP and it's a damn shame because that was a great idea. SegWit introduces a large amount of complexity, technical debt that will make it harder for others to contribute, locking in the "core" devs. This is something that I see a lot in older coders who are afraid of becoming irrelevant and try to "lock in" their relevancy by becoming maintainers of a critical but obscure infrastructure, I saw that at national labs a lot in grad-school and during post-docs. Plus SegWit really is not a soft-fork, but a hard-fork, since you can't run an older node anymore and still even participate in validating transactions, all old nodes become obsolete. You won't have any choice over whether you want to accept "anyonecanspend" tx without signatures included unless you literally run a full node on the old repo tag, and even then your node won't actually be participating in the network anymore except as a relay, not a validator. It's a major technical change, introducing a large new attack surface, and I don't think it's prudent to force it through this way in a $10B economy. It reeks of centralized control, and I especially don't trust would-be economists and religious zealots like GMaxwell and Luke Jr. to have that control, nobody should, it's supposed to be peer-to-peer Satoshi consensus. I don't really agree that those people should have ever been the "core". Satoshi stopped talking to all of them once Gavin went to a little meeting with the CIA, remember? I don't trust any of them. "Trust no-one" used to be a motto for bitcoin, now it's "Trust Lightning Network brought to you by R3!". I also think that if a sidechain implementation does come out, it should be from a team that doesn't have the conflicting interest of also being the maintainers of the "core", especially if that group is holding the blocksize down for the business interests of a large banking collaborative who pays their salary. To me, this represents undue control and influence of the banking community on bitcoin, and their interests are to make bitcoin into a settlement layer only, not a payment layer or a store of value for civilians. The bankers largely agree with the modern "helicopter money" theories of Bernanke, loosely based on Keynesian economic theory, as opposed to the Satoshi viewpoint of Austrian/Viennese economic theory. The bankers are aligned with the governments, they want people using fiat, they are literally opposed to any safe store of value as it negates their ability to "stimulate" people into spending by devaluing the currency, which is their excuse to keep printing money and essentially enslaving everyone else via that mechanism. The bankers and governments want people using fiat, and the "core" have even told people to use Visa instead of bitcoin! Finally, scaling itself. The whole scaling argument was ridiculous at first, and now it's turned sinister. Moore's law predicts a doubling of memory capacity on a given size of chip every 18 months, and Neilsen's law predicts a doubling of the fastest speeds achievable in a communication network every 12 months. Using these laws, we can extropolate that bitcoin would be just fine with an immediate increase to 8MB max blocksize, and a 30% geometric growth curve forever, and have a decreasing storage capacity signature and network propogation delay over time, forever. Therefore, the whole debate is meaningless, it's completely political. The bankers bought out the core, and now they are blocking scaling so they can try to force everyone to use Lightning Network instead of bitcoin. The core is literally trying to take all the transactions away from the miners and give it to their banking buddies, while crippling bitcoin to only be able to do banking settlements. They are destroying Satoshi's vision. SegwitCoin is Bankcoin, not bitcoin.
"The scaling argument was ridiculous at first, and now it's sinister. Core wants to take transactions away from miners to give to their banking buddies - crippling Bitcoin to only be able to do settlements. They are destroying Satoshi's vision. SegwitCoin is Bankcoin, not Bitcoin" ~ u/ZeroFucksG1v3n
SegWit introduces a large amount of complexity, technical debt that will make it harder for others to contribute, locking in the "Core" devs. This is something that I see a lot in older coders who are afraid of becoming irrelevant and try to "lock in" their relevancy by becoming maintainers of a critical but obscure infrastructure. Plus SegWit really is not a soft-fork, but a hard-fork, since you can't run an older node anymore and still even participate in validating transactions, all old nodes become obsolete. You won't have any choice over whether you want to accept "anyonecanspend" tx without signatures included unless you literally run a full node on the old repo tag, and even then your node won't actually be participating in the network anymore except as a relay, not a validator. It's a major technical change, introducing a large new attack surface, and I don't think it's prudent to force it through this way in a $10B $15B economy. It reeks of centralized control, and I especially don't trust would-be economists and religious zealots like GMaxwell and Luke Jr. to have that control. Nobody should, it's supposed to be peer-to-peer Satoshi consensus. I also think that if a sidechain implementation does come out, it should be from a team that doesn't have the conflicting interest of also being the maintainers of the "Core", especially if that group is holding the blocksize down for the business interests of a large banking collaborative who pays their salary. To me, this represents undue control and influence of the banking community on Bitcoin, and their interests are to make Bitcoin into a settlement layer only, not a payment layer or a store of value for civilians. The bankers largely agree with the modern "helicopter money" theories of Bernanke, loosely based on Keynesian economic theory, as opposed to the Satoshi viewpoint of Austrian/Viennese economic theory. The bankers are aligned with the governments, they want people using fiat, they are literally opposed to any safe store of value as it negates their ability to "stimulate" people into spending by devaluing the currency, which is their excuse to keep printing money and essentially enslaving everyone else via that mechanism. The bankers and governments want people using fiat, and the "Core" have even told people to use VISA instead of Bitcoin! Finally, scaling itself. The whole scaling argument was ridiculous at first, and now it's turned sinister. Moore's law predicts a doubling of memory capacity on a given size of chip every 18 months, and Neilsen's law predicts a doubling of the fastest speeds achievable in a communication network every 12 months. Using these laws, we can extrapolate that bitcoin would be just fine with an immediate increase to 8MB max blocksize, and a 30% geometric growth curve forever, and have a decreasing storage capacity signature and network propagation delay over time, forever. Therefore, the whole debate is meaningless, it's completely political. The bankers bought out Core, and now they are blocking scaling so they can try to force everyone to use Lightning Network instead of Bitcoin. Core is literally trying to take all the transactions away from the miners and give it to their banking buddies, while crippling Bitcoin to only be able to do banking settlements. They are destroying Satoshi's vision. SegwitCoin is Bankcoin, not Bitcoin.
Greg Maxwell u/nullc says "The next miner after them sets their minimum [fee] to some tiny value ... and clears out the backlog and collects a bunch of funds that the earlier miner omitted" - like it's a BAD THING. Greg is proposing a SUPPLY-LIMITING AND PRICE-FIXING CARTEL, like it's a GOOD THING.
He is now bad-mouthing Nakamoto Consensus, calling it:
"a majority hashpower cartel undermining the decentralization of the network" (?!?)
He doesn't see that the only one creating a cartel is Greg himself, in collusion with certain miners who want to induce artificially high fees by preventing more efficient / cheaper miners from entering the market, when he says:
"They can turn their nose up at fee paying transactions. Then the next miner after them sets their minimum to some tiny value 10nanobitcoin/byte, clears out the backlog and collects a bunch of funds that the earlier miner omitted."
This is the smoking gun where Greg proudly shows the world that he is anti-competition. This is why Greg's views are tolerated only on a (heavily) censored forum like r\bitcoin - while on a (lightly) censored forum like btc his views are considered repugnant by most sane people. Because:
Greg does not understand economics;
Greg has become the corrupt enabler of a cartel, artificially inflating fees by artificially limiting the supply of blockspace.
Greg (and the miners who support him) seized power by exploiting an accident of history. As we know, due to a series of unfortunate historical accidents, Greg (and the miners who support him) became a "de facto" centralized influence on a certain vital aspect of the world's emerging dominant cryptocurrency, Bitcoin - namely:
its money velocity
This has given Greg a weird kind of power, which he is relishing (perhaps unconsciously) for who-knows-what unsavory reasons. And so here we are, several years into the "blocksize debate"...
still arguing with Greg; and
still allowing Greg, one of the most economically ignorant dipshits the world has ever known, to centrally dictate Bitcoin's money velocity...
...via his unfair exploitation of certain accidental, temporary, "contingent", historical imperfections in Bitcoin's exising codebase and governance process. Satoshi would be ashamed of Greg. As the initial developer of Bitcoin, Satoshi certainly could have exploited (or even introduced) a bunch of "accidental, temporary, "contingent", historical imperfections in Bitcoin's codebase and governance process" - for his own advantage. But Satoshi made extra efforts to not exercise centralized influence over the economic aspects of Bitcoin. Satoshi made sure that the system he created was as minimal and clean as possible, confining itself to providing only what was needed:
a permissionless decentralized time-stamping (global sequentialization) service
based on a worldwide hashing competition for an economically valuable token.
Actually, as Greg pointed out at the time, such a system is indeed "mathematically impossible". That was the first historical example of Greg's economic ignorance. When Greg thought that Bitcoin would never work because he could prove that it was "mathematically impossible" - he was right - but only about the mathematics, not about the economics! Bitcoin works because of certain subtle and clever economic incentives which Satoshi built into the system - incentivizing miners to build on the longest valid chain, where the value of switching to another chain becomes stochastically, vanishingly small as more blocks are appended to the "main" chain. It is important to understand Greg's fundamental error there...
because it's also the same fundamental error which many centralized "banksters" commit when they misunderstand and inevitably mis-implement their "blockchain technology"...
when they just can't bring themselves to endow their "blockchain" with its own valuable token...
which is the essential thing providing the economic incentives for mining, which holds the whole system together...
because they just can't bring themselves to let go of the immense awesome Olympian power they get from being able to centrally print up unlimited quantities of their debt-based "fiat" currency.
Now, Greg just can't bring himself to let go of the immense awesome Olympian power he gets from being able to:
centrally control Bitcoin's minimum fees...
by centrally controlling its maximum blocksize...
by exercising "undue influence" over certain historical accidental imperfections in Bitcoin's codebase and governance.
It all comes down to the same thing: power corrupts.
Central bankers became corrupt due to certain historical accidents giving them undue influence over our "fiat" money supply.
Greg has become corrupt due to certain historical accidents sgiving him undue influence over our Bitcoin transaction supply.
It is also worth noting that it is an insurgent miner, u/ViaBTC, who is most outspoken in support of Bitcoin Unlimited, which decentralizes the decision about blocksize - away from would-be central planners like Greg, and away from any miners who run Greg's less-efficient code. https://np.reddit.com/btc/search?q=author%3Aviabtc&sort=top&restrict_sr=on https://np.reddit.com/btc/search?q=viabtc&restrict_sr=on&sort=top&t=all It's a good thing Satoshi and not Greg had control over Bitcoin's original codebase and governance and economics. Bitcoin will prosper much more when Greg no longer has control over Bitcoin's current codebase and governance and economics. Greg didn't understand the economics of Bitcoin when Satoshi first explained it to him - and he still doesn't understand certain key aspects of the economics of Bitcoin as explained these days by people such as JohnBlocke, ForkiusMaximus, awemany, tsontar, pecuniology, ferretinjapan, Capt Roger Murdock, jtoomim, Peter R - and the many, many others who have been repeating the same simple and well-known economic axiom for these past few years: The market determines demand (transactions), supply (blockspace), price (in CNY, USD, EUR etc.), and fees. Note, in the above scenario, that "supply" in this case corresponds to "blockspace" or "space on the blockchain" - ie, the supply of transactions, which is a commodity (a generic good or service) provided by miners, in return for fees and new coins. This number has grown continuously throughout the history of Bitcoin - determined in decentralized fashion, by the market - as miners make their own decisions on fees versus space, trying to maximize their profits and minimize their orphans. (Meanwhile, is has been observed that the square of Bitcoin's throughput or transactional supply - which could be taken as a rough proxy for adoption - has historically corresponded to the price - which may be an interesting instance of Metcalfe's law. Conversely, this would mean that suppressing the Bitcoin blocksize is a way of suppressing Bitcoin adoption, which in turn is a way of suppressing Bitcoin price.) The supply of space on the blockchain is the number Greg now wants to control by imposing his own artificial, arbitrary, centrally planned limit. It doesn't matter what the "specific" number is (currently it's 1 MB every 10 minutes) - what matters is that Greg wants to centrally limit this number - a number which should be set by the market, not by Greg. Central planning is damaging - making BitcoinCore vulnerable to competitors not limited by central planning. Attempting to centrally control Bitcoin's blocksize could lead to the following scenarios:
At the appropriate time (eg, a "Schelling point", perhaps motivated by one or more crisis events involving network congestion, transaction delays, unacceptably high fees, falling market cap), Bitcoin may fork to another implementation (such as Bitcoin Unlimited) where supply is determined by the market and not by Greg; or
An alt-coin could take over Bitcoin's market dominance.
In other words, "Bitcoin maximalism" could be threatened if we let Greg centrally control the blocksize, instead of letting the decentralized market control the blocksize. Yes, it really is that simple, folks. And, yes, Greg really is that stupid (about economics) to the point where he is now actually publicly and proudly declaring that he should be able to centrally impose a maximum on the supply of space on the blockchain - and thus also centrally impose a minimum on the fees for space on that blockchain. Plus he also has stated elsewhere that he recognizes that he is actively suppressing price and adoption - and he thinks it's ok for him to have have that power also!
Greg Maxwell has now publicly confessed that he is engaging in deliberate market manipulation to artificially suppress Bitcoin adoption and price. He could be doing this so that he and his associates can continue to accumulate while the price is still low (1 BTC = $570, ie 1 USD can buy 1750 "bits")
https://np.reddit.com/btc/comments/4wgq48/greg_maxwell_has_now_publicly_confessed_that_he/ Power corrupts - and absolute power corrupts absolutely. Whether it's a "constitutional blindspot" - or whether Greg is personally (perhaps unconsciously) relishing the vast power he now enjoys by being able to control the "transaction supply" (and the "transaction price") for the world's first major cryptocurrency - it's irrelevant. Greg should not have all this power. The market should have this power. If Greg continues to have this power, it could seriously hurt Bitcoin. Let the market decide. Of course, maximums for blocksizes - and minimums for fees - will inevitably be determined by somebody (or "somebodies). In this debate, we need to decide who that "somebody" should be:
Greg Maxwell, or
the users of Bitcoin
Economics is an area where Greg displays extreme ignorance. Greg is apparently ignorant about economics than the average person who has a cursory understanding of basic economic concepts such as markets, competition, supply, demand, pricing and elasticity. Greg does have a "constitutional gift" for understanding the mathematics of cryptography and the dynamics of C++ programs running on computers. But he also seems to have a "constitutional blindspot" when it comes to understanding the dynamics of free markets made up of real human beings competing in terms of supply and demand, price and fees. This is easy for anyone to see! You don't need a degree in Economics to understand economics better than Greg! This is why it can be said that Greg displays "extreme economic ignorance". And this is why he has become very unliked in the free parts of the Bitcoin ecosystem now: because of his "extreme economic ignorance" - and his general lack of empathy and self-awareness where he has actually come to think that he likes screwing over the "shreaking [sic] masses", whom he can then have the pleasure of ignoring.
GMaxwell in 2006, during his Wikipedia vandalism episode: "I feel great because I can still do what I want, and I don't have to worry what rude jerks think about me ... I can continue to do whatever I think is right without the burden of explaining myself to a shreaking [sic] mass of people."
People are starting to realize how toxic Gregory Maxwell is to Bitcoin, saying there are plenty of other coders who could do crypto and networking, and "he drives away more talent than he can attract." Plus, he has a 10-year record of damaging open-source projects, going back to Wikipedia in 2006.
Wikipedians on Greg Maxwell in 2006 (now CTO of Blockstream): "engaged in vandalism", "his behavior is outrageous", "on a rampage", "beyond the pale", "bullying", "calling people assholes", "full of sarcasm, threats, rude insults", "pretends to be an admin", "he seems to think he is above policy"…
https://np.reddit.com/btc/comments/5i0a40/john_blocke_bitcoin_economics_in_one_lesson/ Or some of the writings of guys like u/ForkiusMaximus - who understands the "market dynamics" of Bitcoin in a way which Greg will never be able to. Unfortunately, Greg seems to think that "economic stuff" is irrelevant - as it's based on stuff involving the "shreaking [sic] masses" - but that's just because Greg doesn't get stuff involving economics. Economics is largely a social science, an area where Greg's skills are woefully inadequate - to the point where the epithet "idiot savant" perhaps really does apply to him. In this latest display of his profound ignorance of market dynamics:
Greg is openly proposing a supply-limiting and price-fixing CARTEL.
And cartels are so frowned upon by people who understand society and economics that they are often made illegal. That statement from Greg linked at the start of this OP is seriously one of the most ignorant things ever publicly uttered in the history of economics. Greg has become so breathtakingly arrogant, so accustomed to "centrally planning" all the code for this cryptocurrency, that he has somehow fallen into believing that he should be able to centrally dictate parameters that depend on factors outside the code, in the marketplace. Greg is in an incredibly powerful position - due to his prominence, he really is able to exert a vast amount of (undue) influence over certain parameters of the world's emerging dominant cryptocurrency which should be market-based, not centrally planned. Satoshi would be ashamed of Greg's cartel creation and currency manipulation. Satoshi wisely understood that the role of the coder is merely to provide a certain minimal framework. Satoshi never specified any centrally planned blocksize that would override the market-based blocksize. Satoshi understood that the only function of the Bitcoin network was to provide:
a permissionless decentralized time-stamping (global sequentialization) service, based on a hashing contest for a valuable token
The system that Satoshi had designed was bigger than what Greg could wrap his mind around. Greg is "constitutionally gifted" to be able to understand things like:
the (deterministic) mathematics of cryptography
the (deterministic) behavior of a von Neumann architecture computer executing C++ programs
And Greg does possess enough "game theory" understanding to be able to understand:
the (largely non-deterministic) behavior of a peer-to-peer network running crytpocurrency mining and validating nodes under Nakamoto Consensus
But Greg is apparently "constitutionally blind" about certain other things too - and generally those are things involving more "social" sciences, including economics. A toxic feedback loop has developed between Greg's central planning and certain miners' natural greed for higher fees - and their natural tendency to desire to prevent additional, more efficient miners from competing with them by offering lower fees. Where we are now
Greg Maxwell is imposing a cartel and engaging in centralized artificial supply-limiting and price-fixing...
by imposing his own centrally planned, artificially high minimum price for fees...
by imposing his own centrally planned artificially low blocksize...
by unfairly taking advantage of a "random" (accidental) accident in Bitcoin's legacy code: the "friction" induced by a legacy, temporary 1 MB anti-spam kludge...
Central planner Greg Maxwell has colluded with the centralized mining cartel for so long, he now thinks that competition is a bad thing - and limiting supply and doing price-fixing is a good thing! He was already an economic idiot who knew nothing about markets - now as the corrupt enabler of a centralized cartel, Greg wants to prevent more-efficient miners from out-competing less-efficient ones. Please, for the sake of Bitcoin, Greg: Stick to mathematics and coding, which is what you do best. And let the market continue to do what it does best. The miners should determine the blocksize. Not Greg Maxwell.
Bitcoin dev IRC meeting in layman's terms (2015-11-12)
Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Note that I crosspost this to Voat, bitcoin.com and the bitcoin-discuss mailing list every week. I can't control what's being talking about in the meeting, if certain things come up I might not be able to post here because of "guidelines". Disclaimer Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit. link to this week logsMeeting minutes by meetbot Main topics discussed where: transaction priority for 0.12 Opt-in replace-by-fee Versionbits Chain limits transaction priority for 0.12
Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which currently makes some transactions free. This currently has a large amount of code, which makes it harder to maintain, and is not that optimal since you can't expect miners to include 0-fee transactions.
Most people seem fine with removing priority in the mempool, but people should be notified ahead of time this is coming. sdaftuar proposed a staggered approach, setting the default value for priority to 0, and remove it entirely in the next release. petertodd notes there will be a natural staggered process since not everyone will upgrade to 0.12 instantly and some implementations might not remove priority at all. Most wallet-software outside of bitcoin-core don't implement priority calculations. As fee estimation becomes more important and many wallet providers use the bitcoin-core fee estimation, improvements on that are welcome. Luke-Jr doesn't agree with removing priority, particularly with changing the mining code to use the priority a transaction has when it enters the mempool. Sipa has the idea to add a small fraction of bitcoin days destroyed divided by the average UTXO age to the fee, so that non-spam-attack transactions are viewed as if they have a larger fee. While most agree with the proposal to remove the current priority, there's still much debate on whether it needs to be replaced for 0.13, and if so, how.
Currently when a node sees a transaction that spends the same output it ignores it. With replace-by-fee it replaces the current transaction in the mempool if it has a higher fee. This allows for things like spending "stuck" transactions, adding more recipients to a transaction in order to prevent chaining, etc. Since there are people that accept 0-confirmation transactions and this would make it extremely easy to double spend them, this is made opt-in. The sender can choose to opt-in to replace-by-fee by changing an input in the nSequence field.
Peter Todd wrote some tools to use replace-by-fee. link It would be nice to have opt-in per output instead of the whole transaction, however that would be very hard to implement and would have some privacy concerns. Luke-Jr would like to see an option to toggle between first-seen-safe/full RBF and neveopt-in/always. Since there are possibly some objections with the "always" toggle it should be a separate pull-request.
review and merge nSequence-based Full-RBF opt-in Peter Todd will write a mail to the list to explain how it works and how people can not accept opt-in transactions. Versionbits
BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than Y the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.
There are 2 different implementations. One from Codeshark and one from Rusty jtimon thinks both implementations are more complicated than they need to be. There needs to be a minor revision namely a starting time for proposals. In general we'd like to get this in soon, but existing softforks need to complete first.
CodeShark adds a starting time to versionbits. Chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent malleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
Wumpus doesn't feel comfortable with merging it because there's some controversy from companies who exceed the limits (or could be/want to). jgarzik does feel comfortable with it, and many think it should be merged as it's easy to revert if needed. There's little choice as it's not safe from attacks without limits. We should communicate the replace-by-fee sendmany alternative to long chains (adding new recipients on existing non-confirmed transactions), although it won't show up in users wallet yet and block-explorers probably aren't ready to display it correctly. Emphasis on the fact it's a change in default values, not a consensus change, however default values have a lot of power. The final limits are 25 transactions and 101kb total size for both ancestor and descendant packages.
jgarzik will merge the pull-request. Morcos will mail the list once it's merged. Participants
BlueMatt Matt Corallo petertodd Peter Todd morcos Alex Morcos jgarzik Jeff Garzik gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan Luke-Jr Luke Dashjr jtimon Jorge Timón btcdrak btcdrak phantomcircuit Patrick Strateman sipa Pieter Wuille CodeShark Eric Lombrozo sdaftuar Suhas Daftuar jg_taxi jg_taxi gavinandresen Gavin Andresen cfields Cory Fields bsm1175321 Bob McElrath
19:53 sipa new topic? 19:53 wumpus any other topics? 19:53 petertodd 19:53 jgarzik did we cover jonas while I was in the taxi? 19:54 sdaftuar ? 19:54 jtimon ? 19:54 CodeShark not sure I want to know 19:54 jgarzik proposal for new GUI maintainer 19:54 CodeShark sounds kinky, though 19:54 petertodd CodeShark: GUI's are pretty kinky 19:56 BlueMatt ok, end meeting? 19:56 btcdrak if we can remember the command this week :-) 19:56 wumpus #meetingend 19:56 gmaxwell #destroymeeting 19:56 wumpus #endmeeting 19:56 Luke-Jr #endmeeting 19:56 lightningbot Meeting ended Thu Nov 12 19:56:42 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 19:56 BlueMatt #magicmeetbotincantation 19:57 petertodd #DoWhatIMean
Bitcoin dev IRC meeting in layman's terms (2015-10-15)
Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Disclaimer Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit. link to this week logsMeeting minutes by meetbot Main topics discussed where: Mempool limiting sendheaders BIP versionbits dev/discuss list policy CHECKSEQUENCEVERIFY Mempool limiting
When a transaction is relayed across the network it is held by the nodes in memory, until it gets into a block. All these transactions that sit in memory are called the memorypool or mempool for short. Like we could see during the spam-attack if there's a big back-log of transactions that couldn't make it in the blockchain this mempool can get pretty big resulting in nodes crashing. To stop this from happening devs are trying to find a way to limit this mempool, so a mechanism to reject and/or remove transactions from the mempool. The hard part here is to make it so nodes can't be attacked by abusing this mechanism. So far the devs are going with TheBlueMatt's proposal of throwing away the cheapest txn and setting the min relay fee to it
While testing, sipa encountered transactions that took 200ms to be accepted into the mempool. As it's the first time he has benchmarked this and the pull-request shouldn't make an impact on these times it likely doesn't have anything to do with this. However, such times are bad either way. The average time in sipa's tests is 4ms. (After the meeting Morcos did some benchmarking and confirmed it was not specific to this PR, and pointed out the outliers come from CheckInputs and HaveInputs (as you might guess, having to do with checking the inputs) Question on why we should revert the minrelay (minimum fee for nodes to relay a transaction) back to 1000 (it has been set to 5000 to quick-fix the mempool issues), sipa thinks it should be floating as well or the dust limit becomes ineffective.
send headers BIP Copy/paste from the BIP: Since the introduction of "headers-first" downloading of blocks in 0.10, blocks will not be processed unless they are able to connect to a (valid) headers chain. Consequently, block relay generally works as follows:
A node (N) announces the new tip with an "inv" message, containing the block hash
A peer (P) responds to the "inv" with a "getheaders" message (to request headers up to the new tip) and a "getdata" message for the new tip itself
N responds with a "headers" message (with the header for the new block along with any preceding headers unknown to P) and a "block" message containing the new block However, in the case where a new block is being announced that builds on the tip, it would be generally more efficient if the node N just announced the block header for the new block, rather than just the block hash, and saved the peer from generating and transmitting the getheaders message (and the required block locator).
Question on how to move forward. How to let the nodes know you want the blockheader instead of the blockhash. Options:
Send a "sendheaders" message early when connecting so the way peers want their block announcement is immediately known.
Send a "sendheaders" message at any time, changing the way peers want their block announcement from hashes to headers.
No one likes to extend the version message further. There's no strong advantage to have an "options" message over a "sendheaders" message. Having the message being sent early on might be too constraining. Possible usecase from morcos: "its entirely possible some future optimization may say, i want to send sendheaders to these peers b/c they announce a lot of new stuff to me and not these others b/c they don't". Most people like this to be enable-only, so no message to get back to receiving blockhashes. Which is how the BIP was drafted.
sdaftuar does a pull-request for the BIP to get a number assigned and proceeds with the BIP as drafted. versionbits
BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than Y the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.
copy/paste from IRC, since I don't know what this specifically means: CodeShark: so right now it's just a unit that implements the versionbits logic but does not demonstrate its usage I thought it would be better to actually integrate in a separate PR, but I can add a demonstration sipa: separate commit, same PR - i think we need something that's mergable as a whole, to be able to see whether the whole thing easily backports Codeshark (who's implementing versionbits) had some more remarks but no one present had seemed to reviewed it, so not much use in discussing things further.
The bitcoin-dev mailing list is intended for technical discussions only. There's things that don't belong there but need to be discussed anyway. Now this is done in bitcoin-dev, but the volume of this is getting too big. There's recently also an influx of really inappropriate posts, level kindergarden. For the things that don't belong on bitcoin-dev, but need to be discussed anyway there's a new list being created namely bitcoin-discuss as well as clear policies and moderation for both.
Bitcoin-discuss was created, but the admin password wasn't distributed to jgarzik who's willing to guide the moderation. Seperate moderation-proposals have been done meanwhile. People just want it to move on.
Since none of the people who proposed a moderation-scheme are present we'll let them discuss it among each other and post their decisions publicly. CHECKSEQUENCEVERIFY
CheckLockTimeVerify (CLTV) repurposes the nSequence field (nSequence are 4 bytes intended for sequencing time-locked transactions, but this never got used). However, there's no way use these values in a bitcoin script. CheckSequenceVerify (CSV) makes this field accessible to bitcoin scripts. EDIT: Turns out this is not entirely correct as it is relative locktime that repurposes the nSequence field.
CLTV is pretty much done. Check to see maaku moving one of the bits to allow for other implementations to have better granularity has any objections. As long as we're using as few bits as possible the exact semantics are less important for most people. sipa points out a possible bug that influences the wallet. CSV is not on target for the end of of the month, although a lot of work and progress has been made.
Review and ACK/NACK of 6312 BIP-68: Mempool-only sequence number constraint verification Review and ACK/NACK of 6566 BIP-113: Mempool-only median time-past as endpoint for lock-time calculations Participants wumpus Wladimir J. van der Laan sipa Pieter Wuille btcdrak btcdrak gmaxwell Gregory Maxwell morcos Alex Morcos maaku Mark Friedenbach CodeShark Eric Lombrozo BlueMatt Matt Corallo sdaftuar Suhas Daftuar warren Warren Togami GreenIsMyPepper Joseph Poon davec Dave Collins cfields Cory Fields jonasschnelli Jonas Schnelli Comic relief 19:21 sdaftuar it sounds like everyone is ok with the BIP as drafted then? 19:21 wumpus yes 19:21 gmaxwell I think so. 19:22 davec yes 19:22 sipa well, the only person with concerns was cfields, who doesn't seem to be here :) 19:22 gmaxwell sipa: he can raise concerns later too! 19:22 cfields dammit! 19:22 sipa cfields: too late! 19:22 gmaxwell ha 19:23 cfields did i really miss my third one of these in a row?
Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Disclaimer Please bare in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit. link to this week logslink to meeting minutes Main topics discussed this week where: Mempool limiting: chain limits Low-S change CLTV & CSV review Creation of bitcoin discuss mailing list off-topic but important notice This issue has made most JS bitcoin software vulnerable to generating incorrect public keys. "This is an ecosystem threat with the potential to cause millions of dollars in losses that needs higher visibility; though it's not a bitcoin core / bitcoin network issue. Common, critical, JS code is broken that may cause the generation of incorrect pubkeys (among other issues). Anyone who cares for a JS implementation should read that PR." Mempool limiting: chain limits
(c/p from last week) Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. The first unconfirmed transaction is called the ancestor and the transactions depending on it the descendants. The total amount of transactions is reffered to as "packages".
since last week
As said in "Chain limits" last week Morcos did write a proposal about lowering the default limits for transaction-chains. 2 use cases came up which are currently in use or happened before: As example: someone buys bitcoin from a website and can spend those bitcoin in the marketplace of the same website without waiting for confirmation in order to improve the bitcoin user-experience. This leaves a sequential transaction chain. They don't need to chain more than 5 transactions deep for this, and it falls within the proposed limits. What's not within the proposed limits is the chain of +/- 100 transactions a company had during the spam-attacks. These where simply increased activities by end-users while not enough UTXO's where available (3 to be precise)(UTXO: unspent transaction output, an output that can be used as input for a new transaction). Notably this is with the best practices of using confirmed transactions first. Ways this can be solved from the company's end is to have more UTXO's available before hand, bundling transactions (which requires delaying customer's request) or using replace-by-fee to add payees (which saves blockchain space, is cheaper in fees and gets transactions through quicker, but is not widely deployed by miners atm). Bare in mind these proposals are for default values for the memorypool, not in any way hard limits.
Sense of urgency. Quoting sipa: "my mempool is 2.5G... we better get some solution!" Current attack analysis assumes child-pays-for-parent mining, it should probably be done again without. Higher limits on number of transactions increase attack-vectors. Proposed number of transactions gets some push-back, total size limit not. Mixing default values (for example having a 50% of a 10/10 limit and 50% of a 100/100 limit) wastes bandwidth while there are too many factors that limit utility of long chains as well. 25 transaction limit ought to be enough for everyone (for now).
This is in regards to the recent malleability attack. Which is caused by a value 'S' in the ECDSA signature which can be 2 values, a high and low value and still be valid. Resulting in different transaction id's. more info A solution for this is to require nodes to have the "low-s" encoding for signatures. Downside is that it will block most transactions made by sufficiently out of date software (+/- pre-march 2014) This does not replace the need for BIP62, it only eliminates the cheap DOS attack.
95% of transactions already confirm to this, and more fixes have been applied since. BlueMatt has a node which several people are running that auto-malleates to low-s transactions. Questions whether we release it ASAP or wait for the next release and get it to a couple of miners in the meantime (possibly with auto-lowS-malleating)
CLTV: checkLockTimeVerify CSV: checkSequenceVerify Both new time-related OP-codes. Been discussed heavily last week.
Concerns whether CSV will be ready enough for release later this month. There's no clarity on how things look when all 3 time related pull-requests are merged. There's a number of people still reviewing the pull-requests. Uncertainty and confusion about whether the semantics are final or not (in regards to using bits from nSequence). nSequence are 4 bytes intended for sequencing time-locked transactions, but this never got used. Now these bytes are being repurposed for a mixture of things. Currently the plan is: " bits 0..15 are the relative locktime, bit 30 determines units (0: height, 1: time w/ 512s granularity), and bit 31 toggles BIP 68 (0: on, 1: off). bits 16..29 are masked off and can take any value."
Clarification from maaku regarding nSequence for BIP68. (after the meeting he explained he was waiting for opinions, but not enough people seemed to know the issue at hand) Continue review of pull requests 6312, 6564 and 6566 Creation of bitcoin discuss mailing list
The bitcoin-dev mailing list is intented for technical discussions only. There's things that don't belong there but need to be discussed anyway. Now this is done in bitcoin-dev, but the volume of this is getting too big. There's recently also an influx of really inappropriate posts, level kindergarden.
No clarity about who are the moderators. Next week there'll be a bitcoin-discuss list created. Decisions are needed as to who'll become the moderators for that and bitcoin-dev. Decisions are needed as to what will be the list and moderation policies.
The bitcoin-discuss list will be created as well as a simple website listing all the lists and corresponding policies. A meeting is scheduled on monday to discuss the moderation and policies of said lists. Participants morcos Alex Morcos gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan sipa Pieter Wuille BlueMatt Matt Corallo btcdrak btcdrak petertodd Peter Todd warren Warren Togami phantomcircuit Patrick Strateman dstadulis Daniel Stadulis GreenIsMyPepper Joseph Poon bsm117532 Bob McElrath
Bitcoin dev IRC meeting in layman's terms (2015-10-22)
Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Disclaimer Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit. link to this week logsMeeting minutes by meetbot Main topics discussed where: Mempool Memory Usage LevelDB replacement Median Past locktime & CLTV Short topics/notes BIP 9 Versionbits PR #6816 is ready for implementation and needs more reviews. A 3 month moderation period on the bitcoin-dev mailinglist has started, as well as a new list bitcoin-discuss. more details: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Octobe011591.html "bitcoin.org had incorrect release notes for 0.11.1. It's corrected now. They had posted the release notes for the initial RC and not updated them. Process wise it would be good to watch out for that in the future." Mempool Memory Usage
When a transaction is relayed across the network it is held by the nodes in memory, until it gets into a block. All these transactions that sit in memory are called the memorypool or mempool for short. Like we could see during the spam-attack if there's a big back-log of transactions that couldn't make it in the blockchain this mempool can get pretty big resulting in nodes crashing. To stop this from happening devs created a mechanism to reject and/or remove transactions from the mempool. This mempool limiting got merged this week. Also relevant: There is an already existing limit on the database cache size called "dbCache". The default value for that is 100MB.
Testing shows there's a discrepancy between the configured mempool limit and the actual memory usage. This is caused by the amount of UTXO data when processing transactions. This data is only flushed after a block is processed (so temporarily exceeding the cache limit set in dbCache). There are 2 "obvious" solutions for this:
Always enforce the UTXO cache limit, just like the mempool limit is always enforced. Downside for that is if you misconfigure your mempool limit an attack can blow away your UTXO cache, which significantly slows down validation and propagation.
Take the UTXO cache into account when limiting the mempool. Downside for that is that you could construct transactions which require way more cache space and thereby more easily kick out other transactions.
A more optimal solution would be to give priority in the cache to things in the mempool. Ways to achieve that are to kick UTXO's from transaction that are evicted from the mempool out of the cache and from transactions that never made it into the mempool. Something TheBlueMatt is working on
Continue to research and optimize. LevelDB replacement
LevelDB is the database system currently used in bitcoin. Since this is not being maintained for some time devs are looking for replacements.
jgarzik worked on a patch for SQLite Some people express concerns whether the performance will be good enough with SQLite, but there are no benchmark results yet.
Do research into other options Do lots of benchmarks and report results Median Past locktime & CLTV
When a block is created miners include a timestamp. This timestamp has to be between the median of the previous 11 blocks and the network-adjusted time +2 hours. So this timestamp can vary a decent amount from the real time. With the introduction of lock-time transactions, that are only valid after a certain time, miners are incentivised to lie about the time in order to include time-locked transactions (and their fees) that wouldn't otherwise be valid. BIP 113 enables the usage of GetMedianTimePast (the median of the previous 11 blocks) from the prior block in lock-time transactions to combat this behaviour. Users can compensate for this by adding 1 hour (6 blocks) to their lock times. CLTV stands for CheckLockTimeVerify, BIP65 Commonly reffered to as: How you thought nLockTime worked before you actually tried to use it.
CLTV is ready to be merged (and has been merged at time of writing) Questions of whether to add median past locktime as mempool only or as softfork Overall questions as to what to include in the CLTV deployment, what to include as mem-pool only and what as softfork. Median past locktime violates current 'standard' behavior, so we would prefer to have that violation dead in the network before the median past locktime softfork moves forward.
review BIP-113: Mempool-only median time-past as endpoint for lock-time calculations review the CLTV backports (done and merged at time of writing) Backport median past locktime to 0.10 and 0.11 Participants btcdrak btcdrak sipa Pieter Wuille gmaxwell Gregory Maxwell BlueMatt Matt Corallo morcos Alex Morcos petertodd Peter Todd CodeShark Eric Lombrozo jgarzik Jeff Garzik maaku Mark Friedenbach kanzure Bryan Bishop jcorgan Johnathan Corgan Luke-Jr Luke Dashjr jonasschnelli Jonas Schnelli sdaftuar Suhas Daftuar
Everyone has a flawed mind. So this post is just putting his into the spotlight. I think he deserves it since he is actively trying to harm bitcoin by writing to the SEC about his bogus beliefs which include incredibly broad definitions of pyramid schemes that would apply to virtually any investment. Sometimes he makes good points and he seems to put a lot of time and thought into his comments so this will be just looking at a recent comment of his where he gets into the subject of economics. It is always interesting to see computer scientists and cryptographers like Gmaxwell and jstolfi chiming in with their economic expertise. Anyways... https://www.reddit.com/btc/comments/5ql70f/at_any_point_in_time_mining_pools_could_have/dd0gayu/
But it cannot do that if its value keeps increasing, because that will cause people to hoard most of the coins, and that will make the price too volatile for currency use.
actually... if bitcoins value keeps increasing it will get less volatile over time because of the increased liquidity and investor pool. It's easy to see by using extreme examples. If bitcoin was worth a penny a piece and there are only 16 million then a person with 160k could have the potential to drastically effect the market. Whereas now with the current value/market cap someone with that much worth is just a drop in the bucket. It is also amusing how people believe in contradicting things. How is it that people like this believe that bitcoins flaw is that it "keeps increasing" (deflationary) but it is also volatile? Which one is it? It can't be both. Volatile means up and down and not just up.
But it is a fallacy. Scarcity alone does not make something valuable; there are plenty of things that exist only in a finite number, but are quite worthless. To make the argument work, one need to assume also that bitcoin will be increasingly used as a currency for payments.
If you dissect this comment it is pretty pointless. Obviously it takes more than rarity to be valuable. If it only took rarity then a clone of bitcoin would be worth the same as bitcoin.
For that reason, ,a good currency must lose value gradually, so that no one will want to "invest in" (hoard) it. Economists have been saying that for a long time; but Satoshi, being a computer guy rather than econmist, did not believe in that. And I did not believe either -- until I watched bitcoin and saw how the mere expectation of increasing value can wreck a currency.
For loans, an inflationary currency is pretty helpful for the borrower. This perhaps means that bitcoin isn't best suited for loans. And if that is the case it isn't a big deal. In an age where there is incredible debt and where everything is incredibly leveraged and where these two factors contribute to "busts" and boom cycles and failures and bankruptcies where taxpayers pay the bill... how terrible is it to have a currency out there that doesn't lend itself well to being leveraged? Put simply, there are tools that will be built on top of and around bitcoin that will allow people to still utilize debt even in an age where bitcoin is king. Furthermore, along with the decrease in volatility as bitcoin becomes "bigger" there is a certain proportional importance regarding payments. The question isn't "is bitcoin stable enough to allow payments". The question is "is bitcoin stable enough to store your wealth in it?. If the answer to the second question is yes then the answer to the first question is implicitly yes because when you make a payment you are spending only a fraction of your net wealth so the volatility is inconsequential in comparison to the bulk of your wealth.
That is a commonly repeated mantra among bitcoin idealists. But it seems to be mostly wishful thinking. There are three major classes of bitcoin "users": the "Shoppers", who use bitcoin as a currency to make or receive payments that they can't do with banks or PayPal; the "Traders", who use it as an instrument for day-trading within the exchanges; and the "Holders", who have some bitcoin and intend to keep them until they are much more valuable than today. The Shoppers have no reason to care about the 21 M cap or any other "sacred principles". All they want is see their payments reach the destination. The Traders don't care about principles either; they like bitcoin because it has huge volatility (and they are the main cause of it). Many traders do not know how bitcoin works, and don't care. All they need to know is that it can be bought and sold, and the price varies like crazy. The Holders are the only ones who would care about the 21 M cap. But there is not much they can do, if it is in danger. Their choices are to dump and lose their expected gains, or continue holding and hoping that their expectations will be met in spite of the change. Does not seem a clear-cut choice to me...
since we are actually talking about the "value" of bitcoin and since holders affect the "value" of bitcoin the most, then it seems that the mantra is pretty self evident. Obviously a supply change would upset holders more than shoppers but it is the holders who keep the value high (and not the shoppers). Shoppers do, however, benefit from a high value because it helps with liquidity which reduces the spread and increases chances of acceptance.
Barring quantum computers, is Monero immune from cryptographic breaks? Quoting gmaxwell's statement on bitcoin's cryptography strength:
nullc 8 points 8 days ago
But for me as a long term holder, it would just be another blip on the radar.
Or, perhaps, you quietly lose 100% of your position over a period of months while attackers target high value slow moving txouts and move them and cash out long before anyone realizes there is a break. A second preimage vulnerability would allow forging your signatures... even if you noticed people would just think you and other people complaining got hacked. This kind of break isn't likely by any means, but it is not outside the bounds of plausibility. You are not immune from cryptographic breaks.
This graph shows Bitcoin price and volume (ie, blocksize of transactions on the blockchain) rising hand-in-hand in 2011-2014. In 2015, Core/Blockstream tried to artificially freeze the blocksize - and artificially froze the price. Bitcoin Classic will allow volume - and price - to freely rise again.
http://nakamotoinstitute.org/mempool/how-we-know-bitcoin-is-not-a-bubble/#selection-59.4-68.0 (Scroll down to see the graph - also note there is a typo in the legend: "Bitcoin market map" should say "Bitcoin market cap[italization]".) Without artificial limits, Bitcoin volume and price are naturally and tightly correlated. This tight, lockstep correlation between those two lines during 2011-2014 has been absolutely amazing - one of the tightest correlations you'll ever observe in any dynamic system anywhere, in economics, sociology, or nature. Price and volume rose (and fell) hand-in-hand for 4 years straight - one of the most majestic examples of emergent phenomena in the whole history of economics. Left to run its natural course, this graph would probably have continued in lockstep, and thus would have eventually gone into the history books of future generations, marking the inexorable emergence and dominance of the cryptocurrency known as Bitcoin - the inevitable triumph of humanity's first decentralized and permissionless store of value, medium of exchange, and unit of account - steadily rising through the years in price and volume - and in usefulness. Then in late 2014, a new company called Blockstream tried to block this natural progression. The oligarchs behind the ancien régime of debt-backed, violence-enforced infinite fiat thought they had figured out a clever way to attempt to make their last pièce de résistance while making some money too. They brought out their their usual grab-bag of assorted dirty tricks which they typically use to take down any new social or economic or political movement that promises to liberate people from the stranglehold of private central bankers:
They bought off the Core developers, bringing them into the Blockstream corporation, with a measly initial $ 21 million in funding, and now adding another measly $ 55 million (mere chump change compared with the tsunami of trillions of dollars in wealth which Bitcoin's market cap could eventually represent).
They figured out how to "play" the Core devs like fiddles, turning them into "useful idiots": taking advantage of their cypherpunk sensibilities and economic innocence in order to trick them into thinking that the only metric of decentralization was "The blocksize must remain small enough for Luke-Jr to run a node over a slow-ass internet connection in the backwaters of Florida" - while making them ignore all other metrics, in particular: decentralization of mining, and price & adoption.
So far, Blockstream thinks they're winning in their battle to control Bitcoin.
They succeeded (during 2015) in splitting the community, maybe even creating even a few more useful idiots in the process.
They succeeded (during 2015) in suppressing the price: as you can see by observing how the lockstep correlation between price and volume diverged in 2015, with the price now lagging and sagging below the volume for the first time ever.
https://imgur.com/jLnrOuK But can they keep spreading around their fiat and FUD to continue fooling all the people all the time? Probably not. Because... Now you can choose to run a repo without Blockstream's artificial scarcity on blocksize and transactions on the blockchain. Now, instead of running the Bitcoin Core repo from Blockstream, you can run any one of these another tested and deployed repos, which do notartificially limit the blocksize to 1 MB:
Bitcoin is a natural, market-based and community-based, emergent phenomenon. At its heart, in the words of Satoshi Nakamoto, Bitcoin is a P2P Electronic Cash System where Alice "A" can send to Bob "B" some amount of Coins "C", secured via a cryptographic signature. It may come as a shock to certain people's egos, but even if most of the devs were to suddenly stop working now - the current system would probably work fine for the next few years - with investors and businesspeople continuing to gradually increase the price and volume in accordance with the desires of the worldwide market, and miners and full-nodes continuing to gradually increase the "max blocksize" in accordance with the capacity of the worldwide infrastructure - and everyone continuing to innovate and participate in the growth of the system in accordance with the desires of the worldwide community. Bitcoin doesn't really need a whole lot of interference from devs trying to centrally plan what the "max blocksize" should be - or mods trying to centrally control what the "consensus of opinions" should be. These kinds of things are better left to just naturally emerge on their own. Central planning and control are not needed. As we have already seen, when the market is allowed to determine Bitcoin price and volume on its own, they both naturally go up, hand-in-hand - while the value of centrally-planned fiat goes down and and down. And when the community is allowed to determine upvotes and downvotes on its own, the quality of debate naturally goes up - while the quality of centrally-controlled debate on censored forums goes down and down. We all know that Bitcoin is supposed to be trustless and permissionless. Bitcoin development should also be egoless. As a dev or a mod, it's hard to "step aside" and let the market or the community decide. It's much more tempting to interfere: enforce a limit here, delete a comment there. But the market and the community are emergent phenomena. They work best when devs and mods learn to put aside their egos and "step back" and let the market and the community do what they will. This is the raison d'être of Bitcoin Classic, Bitcoin Unlimited, and Bitcoin XT: learning to let the market and the community decide again - learning to step back again, and let the price and volume go up again, with no unnecessary interference from devs or mods. https://imgur.com/jLnrOuK
A one party state... is a type of state in which one political party has the right to form the government. All other parties are either outlawed or allowed to take only a limited and controlled participation in elections."
Referring to the linked article, note the list of countries that practice this form of government. It has been vehemently argued by Core that Bitcoin is not majoritarian. It has been vehemently argued by Core that consensus rules are not up for "Nakamoto vote".
The protocol rules of the bitcoin system have never been up for vote by CPU; not from the very first release, not in the earliest descriptions of the system. - GMaxwell
Though Core will also argue vehemently that they do not "control" Bitcoin, note this part of the definition of a "one-party state:
Sometimes the term de facto one-party state is used to describe a dominant-party system that, unlike the one-party state, allows (at least nominally) democratic multiparty elections, but the existing practices or balance of political power effectively prevent the opposition from winning the elections.
My friends, I fear this is Bitcoin. Yes, Nakamoto consensus does permit the possibility of a "Nakamoto vote" on the consensus rules. Yes, this does in theory allow a competing dev team to create alternative implementations. But, de facto, through control of media, censorship, and partnership with key miners, Core has been able to thwart the "referendum" on itself. If Core can prevent a referendum on itself, then it "controls Bitcoin." Folks, Classic adoption has stalled. In the past there were schisms that divided the community and chunks of people left. When XT stalled, Mike and a bunch of other people gave up on Bitcoin. Now Classic is stalling and I foresee another wave of people leaving. I now understand the strategy. With each new "issue" (ie ASIC mining, the blocksize limit, etc. etc.), Core can obstruct progress right to the point that it has actually enraged the majority. As long as Core can continue to censor & excise people like us in waves, such that we aren't allowed to "build up" in its community and become a majority, then there can never be a "vote on leadership." It can't come up for vote. Bitcoin depends on open communication channels in order to work. This might be a coincidence, or it might be telling us that whoever controls the channels, controls the coin. I got involved with Bitcoin knowing full well that there were a million ways it could fail. Intellectually, it's been an amazing ride regardless: I've learned so much in the past few years that will be relevant regardless if Bitcoin succeeds or fails. Financially, it's been great too. Fortunately I never "put in more than I could afford to lose" so I'm actually willing to ride Bitcoin into the ground if need be. The thing is, I didn't sign up for a Bitcoin that is resistant to ideas, and which serves a small, special-interested group. I didn't sign up for the Core team. Hell when I got involved, most of those people were still scoffing at Bitcoin! I am not interested in this "small tent" vision of Bitcoin. I got involved in permissionless innovation, where anyone with an economically efficient idea could get his ideas heard and implemented. I got involved in the "big tent" vision of Bitcoin, a Bitcoin that would scale on-chain. [ASIDE: the limit was introduced roughly six years ago. That's four iterations of Moore's Law. If we scaled with Moore's law, from the moment the 1MB was introduced, the limit would currently be 16MB.] [ASIDE: when the limit was introduced the typical block contained one (1) transaction (the coinbase transaction) because nobody was using the network, so the 1MB limit was 4000X greater than the typical block size. If the same padding were used today, the limit would be ~4GB] I've included these observations because I don't believe that anyone in 2010 would have ever thought that six years later, Bitcoin could be worth $400+, would be carrying hundreds of thousands of transactions daily, and would still have a 1MB capacity cap. And I feel doubly sure that in 2010 people would have lost their fucking minds at the idea that in 2016 the capacity would be limited in order "to let a fee market develop." Who the hell is going to invest in a technology that is already at capacity? Folks, I think we're looking at a potential end-game playing out here. The folks at Core are obviously completely blind to this, but sooner or later Core will simply get sufficiently out of touch with the market that people just abandon Bitcoin because something else is actually working much better. That is in fact Core's explanation for how the economic incentives in Bitcoin work:
The economic mechanism that provides feedback to miners is that the users of the system won't accept their blocks if they violate the rules the users prefer exist. - GMaxwell
If this is the de facto operative vision of Bitcoin, then it's doomed. First off, this system can only reject sufficiently hostile innovations. "Annoying" and "non value added" and even "pretty bad" innovations can still be forced through through soft-forks that avoid the consensus vote. But worse, and this is the real kicker, this system cannot choose innovations for itself. It must passively accept only those innovations offered by Core. "Got a brilliant idea that could revolutionize the blockchain? Core hates it? Fuck you. Start an altcoin. Censored" If I'm understanding this correctly, that strategy will work every time. So the idea of Bitcoin that I envisioned - one in which miners would voluntarily select code that expresses the consensus rules that they believe should emerge on the network - that Bitcoin might not exist. Which is a shame, because that Bitcoin is permissionless, censorship-resistant, and innovates at the speed of the market. Instead, we might just have CoreCoin :( Which is only as censorship-resistant as they decide, and which innovates at the speed of their willingness to permit it. Like I said, I didn't sign up for that particular group of people - most of them were still making fun of Bitcoin when I got started. But a de facto one-party state = CoreCoin. Owning a Bitcoin is an economic vote in Core. Am I wrong? And if not, can this train get put back on the tracks?
“When we talk about gold as a store of value that just means a lot of people agree to pay the same price for one ounce of gold,” Epstein once said. “In 2017, enough people agree on the value of bitcoin that it can serve the same purpose. There will only ever be 21 million bitcoins, but this limit comes from computer code, not by how many User:Gmaxwell/features. From Bitcoin Wiki. Jump to: navigation, search. This is a non-official list of features I personally would like to see in the reference Bitcoin software. Although it's just my personal list, some of these items are generally supported by other people— and I've included many things that I wouldn't use myself but think The cryptocurrency community has been discussing the infamous Ghislaine Maxwell, the associate of the financier and convicted sex offender Jeffrey Epstein. Maxwell was recently arrested and many speculators think she may see the same fate as Epstein [5:33] gmaxwell: praxeology: You might have noticed that I spoke precisely. Bitcoin is fiat by the definition used in economics. That makes absolutely no sense whatsoever. There is no formal authorization or decree involved in Bitcoin, centralized or decentralized. There is an economic incentive to provide proof of work. That's it. It is well known that the former Bear Stearns partner Jeffrey Epstein liked bitcoin and spoke about the subject often before his death. “When we talk about gold as a store of value that just means a lot of people agree to pay the same price for one ounce of gold,” Epstein once said. “In 2017, enough people agree on the value of bitcoin
Bitcoin price drops 15% in a matter of minutes. What does this mean for bitcoin bulls? Is btc even bullish anymore? Here is what you can look out for on the bitcoin charts. Bitcoin finding difficulty to break the key structure level. Price rejection at this point can be very fatal. Must watch key area for BTC at the moment. The premise is that the “value of Bitcoin is a function of its energy input in Joules. The formula he created was then accurate, with his analysis indicating it has had an 80% R2 value over ... Welcome to Team Underground, I (Thomas) do weekly BTC price analysis on YouTube. I've been full time trading bitcoin for over a year now and I've decided to share some of my analysis on YouTube ... Bitcoin Price History in Dollars From 2012 to 2017 (Monthly) - Duration: 2:01. Paddingtonyt 1,883 views. 2:01. 100 Year History Of Silver Prices Proves Its Worth! - Duration: 13:23.