gmaxwell says Bitcoin is "Fiat" : btc

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:
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!

BIP9 Miner-Activated Soft Fork

Basically, BIP9 has a bunch of parameters:
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:

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.

Covert ASICBoost

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.
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:
  1. 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.
  2. 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.

Taproot Activation Proposals

There are two primary proposals I can see for Taproot activation:
  1. BIP8.
  2. Modern Softfork Activation.
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.
  1. First have a 12-month BIP9 (fail at timeout).
  2. 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.
  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:
  1. You hear a new version of your favorite software has a nice new feature.
  2. Excited, you install the new version.
  3. You find that the new version has subtle incompatibilities with your current workflow.
  4. You are sad and downgrade to the older version.
  5. You find out that the new version has changed your files in incompatible ways that the old version cannot work with anymore.
  6. 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:
  1. 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.
  2. 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.
submitted by almkglor to Bitcoin [link] [comments]

Long live decentralized bitcoin(!) A reading list

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

Summary / The fundamental tradeoff

A trip to the moon requires a rocket with multiple stages by gmaxwell (must read) https://www.reddit.com/Bitcoin/comments/438hx0/a_trip_to_the_moon_requires_a_rocket_with/
Bram Cohen, creator of bittorrent, argues against a hard fork to a larger block size https://medium.com/@bramcohen/bitcoin-s-ironic-crisis-32226a85e39f#.558vetum4
gmaxwell's summary of the debate https://bitcointalk.org/index.php?topic=1343716.msg13701818#msg13701818
Core devs please explain your vision (see luke's post which also argues that blocks are already too big) https://www.reddit.com/Bitcoin/comments/61yvvv/request_to_core_devs_please_explain_your_vision/
Mod of btc speaking against a hard fork https://www.reddit.com/btc/comments/57hd14/core_reaction_to_viabtc_this_week/d8scokm/
It's becoming clear to me that a lot of people don't understand how fragile bitcoin is https://www.reddit.com/Bitcoin/comments/59kflj/its_becoming_clear_to_me_that_a_lot_of_people/
Blockchain space must be costly, it can never be free https://www.reddit.com/Bitcoin/comments/4og24h/i_just_attended_the_distributed_trade_conference/
Charlie Lee with a nice analogy about the fundamental tradeoff https://medium.com/@SatoshiLite/eating-the-bitcoin-cake-fc2b4ebfb85e#.444vr8shw
gmaxwell on the tradeoffs https://bitcointalk.org/index.php?topic=1520693.msg15303746#msg15303746
jratcliff on the layering https://www.reddit.com/btc/comments/59upyh/segwit_the_poison_pill_for_bitcoin/d9bstuw/

Scaling on-chain will destroy bitcoin's decentralization

Peter Todd: How a floating blocksize limit inevitably leads towards centralization [Feb 2013] https://bitcointalk.org/index.php?topic=144895.0 mailing list https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-February/002176.html with discussion on reddit in Aug 2015 https://www.reddit.com/Bitcoin/comments/3hnvi8/just_a_little_history_lesson_for_everyone_new_the/
Nick Szabo's blog post on what makes bitcoin so special http://unenumerated.blogspot.com/2017/02/money-blockchains-and-social-scalability.html
There is academic research showing that even small (2MB) increases to the blocksize results in drastic node dropoff counts due to the non-linear increase of RAM needed. http://bravenewcoin.com/assets/Whitepapers/block-size-1.1.1.pdf
Reddit summary of above link. In this table, you can see it estimates a 40% drop immediately in node count with a 2MB upgrade and a 50% over 6 months. At 4mb, it becomes 75% immediately and 80% over 6 months. At 8, it becomes 90% and 95%. https://www.reddit.com/Bitcoin/comments/5qw2wa_future_led_by_bitcoin_unlimited_is_a/dd442pw/
Larger block sizes make centralization pressures worse (mathematical) https://petertodd.org/2016/block-publication-incentives-for-miners
Talk at scalingbitcoin montreal, initial blockchain synchronization puts serious constraints on any increase in the block size https://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m06s with transcript https://scalingbitcoin.org/transcript/montreal2015/block-synchronization-time
Bitcoin's P2P Network: The Soft Underbelly of Bitcoin https://www.youtube.com/watch?v=Y6kibPzbrIc someone's notes: https://gist.github.com/romyilano/5e22394857a39889a1e5 reddit discussion https://www.reddit.com/Bitcoin/comments/4py5df/so_f2pool_antpool_btcc_pool_are_actually_one_pool/
In adversarial environments blockchains dont scale https://scalingbitcoin.org/transcript/hongkong2015/in-adversarial-environments-blockchains-dont-scale
Why miners will not voluntarily individually produce smaller blocks https://scalingbitcoin.org/transcript/hongkong2015/why-miners-will-not-voluntarily-individually-produce-smaller-blocks
Hal Finney: bitcoin's blockchain can only be a settlement layer (mostly interesting because it's hal finney and its in 2010) https://www.reddit.com/Bitcoin/comments/3sb5nj/most_bitcoin_transactions_will_occur_between/
petertodd's 2013 video explaining this https://www.youtube.com/watch?v=cZp7UGgBR0I
luke-jr's summary https://www.reddit.com/Bitcoin/comments/61yvvv/request_to_core_devs_please_explain_your_vision/dficjhj/
Another jratcliff thread https://www.reddit.com/Bitcoin/comments/6lmpll/explaining_why_big_blocks_are_bad/

Full blocks are not a disaster

Blocks must be always full, there must always be a backlog https://medium.com/@bergealex4/bitcoin-is-unstable-without-the-block-size-size-limit-70db07070a54#.kh2vi86lr
Same as above, the mining gap means there must always be a backlog talk: https://www.youtube.com/watch?time_continue=2453&v=iKDC2DpzNbw transcript: https://scalingbitcoin.org/transcript/montreal2015/security-of-diminishing-block-subsidy
Backlogs arent that bad https://www.reddit.com/Bitcoin/comments/49p011/was_the_fee_event_really_so_bad_my_mind_is/
Examples where scarce block space causes people to use precious resources more efficiently https://www.reddit.com/Bitcoin/comments/4kxxvj/i_just_singlehandedly_increased_bitcoin_network/
https://www.reddit.com/Bitcoin/comments/47d4m2/why_does_coinbase_make_2_transactions_pe
https://www.reddit.com/Bitcoin/comments/53wucs/why_arent_blocks_full_yet/d7x19iv
Full blocks are fine https://www.reddit.com/Bitcoin/comments/5uld1a/misconception_full_blocks_mean_bitcoin_is_failing/
High miner fees imply a sustainable future for bitcoin https://www.reddit.com/BitcoinMarkets/comments/680tvf/fundamentals_friday_week_of_friday_april_28_2017/dgwmhl7/
gmaxwell on why full blocks are good https://www.reddit.com/Bitcoin/comments/6b57ca/full_blocks_good_or_bad/dhjxwbz/
The whole idea of the mempool being "filled" is wrong headed. The mempool doesn't "clog" or get stuck, or anything like that. https://www.reddit.com/Bitcoin/comments/7cusnx/to_the_people_still_doubting_that_this_congestion/dpssokf/

Segwit

What is segwit

luke-jr's longer summary https://www.reddit.com/Bitcoin/comments/6033h7/today_is_exactly_4_months_since_the_segwit_voting/df3tgwg/?context=1
Charlie Shrem's on upgrading to segwit https://twitter.com/CharlieShrem/status/842711238853513220
Original segwit talk at scalingbitcoin hong kong + transcript https://youtu.be/zchzn7aPQjI?t=110
https://scalingbitcoin.org/transcript/hongkong2015/segregated-witness-and-its-impact-on-scalability
Segwit is not too complex https://www.reddit.com/btc/comments/57vjin/segwit_is_not_great/d8vos33/
Segwit does not make it possible for miners to steal coins, contrary to what some people say https://www.reddit.com/btc/comments/5e6bt0/concerns_with_segwit_and_anyone_can_spend/daa5jat/?context=1
https://keepingstock.net/segwit-eli5-misinformation-faq-19908ceacf23#.r8hlzaquz
Segwit is required for a useful lightning network It's now known that without a malleability fix useful indefinite channels are not really possible.
https://www.reddit.com/Bitcoin/comments/5tzqtc/gentle_reminder_the_ln_doesnt_require_segwit/ddqgda7/
https://www.reddit.com/Bitcoin/comments/5tzqtc/gentle_reminder_the_ln_doesnt_require_segwit/ddqbukj/
https://www.reddit.com/Bitcoin/comments/5x2oh0/olaoluwa_osuntokun_all_active_lightning_network/deeto14/?context=3
Clearing up SegWit Lies and Myths: https://achow101.com/2016/04/Segwit-FUD-Clearup
Segwit is bigger blocks https://www.reddit.com/Bitcoin/comments/5pb8vs/misinformation_is_working_54_incorrectly_believe/dcpz3en/
Typical usage results in segwit allowing capacity equivalent to 2mb blocks https://www.reddit.com/Bitcoin/comments/69i2md/observe_for_yourself_segwit_allows_2_mb_blocks_in/

Why is segwit being blocked

Jihan Wu (head of largest bitcoin mining group) is blocking segwit because of perceived loss of income https://www.reddit.com/Bitcoin/comments/60mb9e/complete_high_quality_translation_of_jihans/
Witness discount creates aligned incentives https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e#.h36odthq0 https://medium.com/@SegWit.co/what-is-behind-the-segwit-discount-988f29dc1edf#.sr91dg406
or because he wants his mining enterprise to have control over bitcoin https://www.reddit.com/Bitcoin/comments/6jdyk8/direct_report_of_jihan_wus_real_reason_fo

Segwit is being blocked because it breaks ASICBOOST, a patented optimization used by bitmain ASIC manufacturer

Details and discovery by gmaxwell https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html
Reddit thread with discussion https://www.reddit.com/Bitcoin/comments/63otrp/gregory_maxwell_major_asic_manufacturer_is/
Simplified explaination by jonny1000 https://www.reddit.com/Bitcoin/comments/64qq5g/attempted_explanation_of_the_alleged_asicboost/
http://www.mit.edu/~jlrubin/public/pdfs/Asicboost.pdf
https://medium.com/@jimmysong/examining-bitmains-claims-about-asicboost-1d61118c678d
Evidence https://www.reddit.com/Bitcoin/comments/63yo27/some_circumstantial_evidence_supporting_the_claim/
https://www.reddit.com/Bitcoin/comments/63vn5g/please_dont_stop_us_from_using_asicboost_which/dfxmm75/
https://www.reddit.com/Bitcoin/comments/63soe3/reverse_engineering_an_asic_is_a_significant_task/dfx9nc
Bitmain admits their chips have asicboost but they say they never used it on the network (haha a likely story) https://blog.bitmain.com/en/regarding-recent-allegations-smear-campaigns/
Worth $100m per year to them (also in gmaxwell's original email) https://twitter.com/petertoddbtc/status/849798529929424898
Other calculations show less https://medium.com/@vcorem/the-real-savings-from-asicboost-to-bitmaintech-ff265c2d305b
This also blocks all these other cool updates, not just segwit https://www.reddit.com/Bitcoin/comments/63otrp/gregory_maxwell_major_asic_manufacturer_is/dfw0ej3/
Summary of bad consequences of asicboost https://www.reddit.com/Bitcoin/comments/64qq5g/attempted_explanation_of_the_alleged_asicboost/dg4hyqk/?context=1
Luke's summary of the entire situation https://www.reddit.com/Bitcoin/comments/6ego3s/why_is_killing_asicboost_not_a_priority/diagkkb/?context=1
Prices goes up because now segwit looks more likely https://twitter.com/TuurDemeestestatus/849846845425799168
Asicboost discovery made the price rise https://twitter.com/TuurDemeestestatus/851520094677200901
A pool was caught red handed doing asicboost, by this time it seemed fairly certain that segwit would get activated so it didnt produce as much interest as earlier https://www.reddit.com/Bitcoin/comments/6p7lr5/1hash_pool_has_mined_2_invalid_blocks/ and https://www.reddit.com/Bitcoin/comments/6p95dl/interesting_1hash_pool_mined_some_invalid_blocks/ and https://twitter.com/petertoddbtc/status/889475196322811904
This btc user is outraged at the entire forum because they support Bitmain and ASICBOOST https://www.reddit.com/btc/comments/67t43y/dragons_den_planned_smear_campaign_of_bitmain/dgtg9l2/
Antbleed, turns out Bitmain can shut down all its ASICs by remote control: http://www.antbleed.com/

What if segwit never activates

What if segwit never activates? https://www.reddit.com/Bitcoin/comments/6ab8js/transaction_fees_are_now_making_btc_like_the_banks/dhdq3id/ with https://www.reddit.com/Bitcoin/comments/5ksu3o/blinded_bearer_certificates/ and https://www.reddit.com/Bitcoin/comments/4xy0fm/scaling_quickly/

Lightning

bitcoinmagazine's series on what lightning is and how it works https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791/ https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-creating-the-network-1465326903/ https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-completing-the-puzzle-and-closing-the-channel-1466178980/
The Lightning Network ELIDHDICACS (Explain Like I Don’t Have Degrees in Cryptography and Computer Science) https://letstalkbitcoin.com/blog/post/the-lightning-network-elidhdicacs
Ligtning will increases fees for miners, not lower them https://medium.com/lightning-resources/the-lightning-paradox-f15ce0e8e374#.erfgunumh
Cost-benefit analysis of lightning from the point of view of miners https://medium.com/@rusty_lightning/miners-and-bitcoin-lightning-a133cd550310#.x42rovlg8
Routing blog post by rusty https://medium.com/@rusty_lightning/routing-dijkstra-bellman-ford-and-bfg-7715840f004 and reddit comments https://www.reddit.com/Bitcoin/comments/4lzkz1/rusty_russell_on_lightning_routing_routing/
Lightning protocol rfc https://github.com/lightningnetwork/lightning-rfc
Blog post with screenshots of ln being used on testnet https://medium.com/@btc_coach/lightning-network-in-action-b18a035c955d video https://www.youtube.com/watch?v=mxGiMu4V7ns
Video of sending and receiving ln on testnet https://twitter.com/alexbosworth/status/844030573131706368
Lightning tradeoffs http://www.coindesk.com/lightning-technical-challenges-bitcoin-scalability/
Beer sold for testnet lightning https://www.reddit.com/Bitcoin/comments/62uw23/lightning_network_is_working_room77_is_accepting/ and https://twitter.com/MrHodl/status/848265171269283845
Lightning will result in far fewer coins being stored on third parties because it supports instant transactions https://medium.com/@thecryptoconomy/the-barely-discussed-incredible-benefit-of-the-lightning-network-4ce82c75eb58
jgarzik argues strongly against LN, he owns a coin tracking startup https://twitter.com/petertoddbtc/status/860826532650123264 https://twitter.com/Beautyon_/status/886128801926795264
luke's great debunking / answer of some misinformation questions https://www.reddit.com/Bitcoin/comments/6st4eq/questions_about_lightning_network/dlfap0u/
Lightning centralization doesnt happen https://www.reddit.com/Bitcoin/comments/6vzau5/reminder_bitcoins_key_strength_is_in_being/dm4ou3v/?context=1
roasbeef on hubs and charging fees https://twitter.com/roasbeef/status/930209165728825344 and https://twitter.com/roasbeef/status/930210145790976000

Immutability / Being a swiss bank in your pocket / Why doing a hard fork (especially without consensus) is damaging

A downside of hard forks is damaging bitcoin's immutability https://www.reddit.com/Bitcoin/comments/5em6vu/what_happens_if_segwit_doesnt_activate/dae1r6c/?context=3
Interesting analysis of miners incentives and how failure is possible, don't trust the miners for long term https://www.reddit.com/Bitcoin/comments/5gtew4/why_an_increased_block_size_increases_the_cost_of/daybazj/?context=2
waxwing on the meaning of cash and settlement https://www.reddit.com/Bitcoin/comments/5ei7m3/unconfirmed_transactions_60k_total_fees_14btc/dad001v/
maaku on the cash question https://www.reddit.com/Bitcoin/comments/5i5iq5/we_are_spoiled/db5luiv/?context=1
Digital gold funamentalists gain nothing from supporting a hard fork to larger block sizes https://www.reddit.com/Bitcoin/comments/5xzunq/core_please_compromise_before_we_end_up_with_bu/dem73xg/?context=1
Those asking for a compromise don't understand the underlying political forces https://www.reddit.com/Bitcoin/comments/6ef7wb/some_comments_on_the_bip148_uasf_from_the/dia236b/?context=3
Nobody wants a contentious hard fork actually, anti-core people got emotionally manipulated https://www.reddit.com/Bitcoin/comments/5sq5ocontentious_forks_vs_incremental_progress/ddip57o/
The hard work of the core developers has kept bitcoin scalable https://www.reddit.com/Bitcoin/comments/3hfgpo/an_initiative_to_bring_advanced_privacy_features/cu7mhw8?context=9
Recent PRs to improve bitcoin scaleability ignored by the debate https://twitter.com/jfnewbery/status/883001356168167425
gmaxwell against hard forks since 2013 https://bitcointalk.org/index.php?topic=140233.20
maaku: hard forks are really bad https://www.reddit.com/Bitcoin/comments/5zxjza/adam_greg_core_devs_and_big_blockers_now_is_the/df275yk/?context=2

Some metrics on what the market thinks of decentralization and hostile hard forks

The price history shows that the exchange rate drops every time a hard fork threatens: https://i.imgur.com/EVPYLR8.jpg
and this example from 2017 https://twitter.com/WhalePanda/status/845562763820912642
http://imgur.com/a/DuHAn btc users lose money
price supporting theymos' moderation https://i.imgur.com/0jZdF9h.png
old version https://i.imgur.com/BFTxTJl.png
older version https://pbs.twimg.com/media/CxqtUakUQAEmC0d.jpg
about 50% of nodes updated to the soft fork node quite quickly https://imgur.com/O0xboVI

Bitcoin Unlimited / Emergent Consensus is badly designed, changes the game theory of bitcoin

Bitcoin Unlimited was a proposed hard fork client, it was made with the intention to stop segwit from activating
A Future Led by Bitcoin Unlimited is a Centralized Future https://blog.sia.tech/a-future-led-by-bitcoin-unlimited-is-a-centralized-future-e48ab52c817a#.p1ly6hldk
Flexible transactions are bugged https://www.reddit.com/Bitcoin/comments/57tf5g/bitcoindev_bluematt_on_flexible_transactions/
Bugged BU software mines an invalid block, wasting 13 bitcoins or $12k
https://www.reddit.com/Bitcoin/comments/5qwtr2/bitcoincom_loses_132btc_trying_to_fork_the/
https://www.reddit.com/btc/comments/5qx18i/bitcoincom_loses_132btc_trying_to_fork_the/
bitcoin.com employees are moderators of btc https://medium.com/@WhalePanda/the-curious-relation-between-bitcoin-com-anti-segwit-propaganda-26c877249976#.vl02566k4
miners don't control stuff like the block size http://hackingdistributed.com/2016/01/03/time-for-bitcoin-user-voice/
even gavin agreed that economic majority controls things https://www.reddit.com/Bitcoin/comments/5ywoi9/in_2010_gavin_predicted_that_exchanges_ie_the/
fork clients are trying to steal bitcoin's brand and network effect, theyre no different from altcoins https://medium.com/@Coinosphere/why-bitcoin-unlimited-should-be-correctly-classified-as-an-attempted-robbery-of-bitcoin-not-a-9355d075763c#.qeaynlx5m
BU being active makes it easier to reverse payments, increases wasted work making the network less secure and giving an advantage to bigger miners https://www.reddit.com/Bitcoin/comments/5g1x84/bitcoin_unlimited_bu_median_value_of_miner_eb/
bitcoin unlimited takes power away from users and gives it to miners https://medium.com/@alpalpalp/bitcoin-unlimiteds-placebo-controls-6320cbc137d4#.q0dv15gd5
bitcoin unlimited's accepted depth https://twitter.com/tdryja/status/804770009272696832
BU's lying propaganda poster https://imgur.com/osrViDE

BU is bugged, poorly-reviewed and crashes

bitcoin unlimited allegedly funded by kraken stolen coins
https://www.reddit.com/btc/comments/55ajuh/taint_analysis_on_bitcoin_stolen_from_kraken_on/
https://www.reddit.com/btc/comments/559miz/taint_analysis_on_btc_allegedly_stolen_from_kraken/
Other funding stuff
https://www.reddit.com/Bitcoin/comments/5zozmn/damning_evidence_on_how_bitcoin_unlimited_pays/
A serious bug in BU https://www.reddit.com/Bitcoin/comments/5h70s3/bitcoin_unlimited_bu_the_developers_have_realized/
A summary of what's wrong with BU: https://www.reddit.com/Bitcoin/comments/5z3wg2/jihanwu_we_will_switch_the_entire_pool_to/devak98/

Bitcoin Unlimited Remote Exploit Crash 14/3/2017

https://www.reddit.com/Bitcoin/comments/5zdkv3/bitcoin_unlimited_remote_exploit_crash/ https://www.reddit.com/Bitcoin/comments/5zeb76/timbe https://www.reddit.com/btc/comments/5zdrru/peter_todd_bu_remote_crash_dos_wtf_bug_assert0_in/
BU devs calling it as disaster https://twitter.com/SooMartindale/status/841758265188966401 also btc deleted a thread about the exploit https://i.imgur.com/lVvFRqN.png
Summary of incident https://www.reddit.com/Bitcoin/comments/5zf97j/i_was_undecided_now_im_not/
More than 20 exchanges will list BTU as an altcoin
https://www.reddit.com/Bitcoin/comments/5zyg6g/bitcoin_exchanges_unveil_emergency_hard_fork/
Again a few days later https://www.reddit.com/Bitcoin/comments/60qmkt/bu_is_taking_another_shit_timberrrrr

User Activated Soft Fork (UASF)

site for it, including list of businesses supporting it http://www.uasf.co/
luke's view
https://www.reddit.com/Bitcoin/comments/5zsk45/i_am_shaolinfry_author_of_the_recent_usedf1dqen/?context=3
threat of UASF makes the miner fall into line in litecoin
https://www.reddit.com/litecoin/comments/66omhlitecoin_global_roundtable_resolution/dgk2thk/?context=3
UASF delivers the goods for vertcoin
https://www.reddit.com/Bitcoin/comments/692mi3/in_test_case_uasf_results_in_miner_consensus/dh3cm34/?context=1
UASF coin is more valuable https://www.reddit.com/Bitcoin/comments/6cgv44/a_uasf_chain_will_be_profoundly_more_valuable/
All the links together in one place https://www.reddit.com/Bitcoin/comments/6dzpew/hi_its_mkwia_again_maintainer_of_uasfbitcoin_on/
p2sh was a uasf https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
jgarzik annoyed at the strict timeline that segwit2x has to follow because of bip148 https://twitter.com/jgarzik/status/886605836902162432
Committed intolerant minority https://www.reddit.com/Bitcoin/comments/6d7dyt/a_plea_for_rational_intolerance_extremism_and/
alp on the game theory of the intolerant minority https://medium.com/@alpalpalp/user-activated-soft-forks-and-the-intolerant-minority-a54e57869f57
The risk of UASF is less than the cost of doing nothing https://www.reddit.com/Bitcoin/comments/6bof7a/were_getting_to_the_point_where_a_the_cost_of_not/
uasf delivered the goods for bitcoin, it forced antpool and others to signal (May 2016) https://bitcoinmagazine.com/articles/antpool-will-not-run-segwit-without-block-size-increase-hard-fork-1464028753/ "When asked specifically whether Antpool would run SegWit code without a hard fork increase in the block size also included in a release of Bitcoin Core, Wu responded: “No. It is acceptable that the hard fork code is not activated, but it needs to be included in a ‘release’ of Bitcoin Core. I have made it clear about the definition of ‘release,’ which is not ‘public.’”"
Screenshot of peter rizun capitulating https://twitter.com/chris_belcher_/status/905231603991007232

Fighting off 2x HF

https://twitter.com/MrHodl/status/895089909723049984
https://www.reddit.com/Bitcoin/comments/6h612o/can_someone_explain_to_me_why_core_wont_endorse/?st=j6ic5n17&sh=cc37ee23
https://www.reddit.com/Bitcoin/comments/6smezz/segwit2x_hard_fork_is_completely_useless_its_a/?st=j6ic2aw3&sh=371418dd
https://www.reddit.com/Bitcoin/comments/6sbspv/who_exactly_is_segwit2x_catering_for_now_segwit/?st=j6ic5nic&sh=1f86cadd
https://medium.com/@elliotolds/lesser-known-reasons-to-keep-blocks-small-in-the-words-of-bitcoin-core-developers-44861968185e
b2x is most of all about firing core https://twitter.com/WhalePanda/status/912664487135760384
https://medium.com/@StopAndDecrypt/thats-not-bitcoin-this-is-bitcoin-95f05a6fd6c2

Misinformation / sockpuppets

https://www.reddit.com/Bitcoin/comments/6uqz6k/markets_update_bitcoin_cash_rallies_for_three/dlurbpx/
three year old account, only started posting today https://archive.is/3STjH
Why we should not hard fork after the UASF worked: https://www.reddit.com/Bitcoin/comments/6sl1qf/heres_why_we_should_not_hard_fork_in_a_few_months/

History

Good article that covers virtually all the important history https://bitcoinmagazine.com/articles/long-road-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality/
Interesting post with some history pre-2015 https://btcmanager.com/the-long-history-of-the-fight-over-scaling-bitcoin/
The core scalabality roadmap + my summary from 3/2017 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decembe011865.html my summary https://www.reddit.com/Bitcoin/comments/5xa5fa/the_core_development_scalability_roadmap/
History from summer 2015 https://www.reddit.com/Bitcoin/comments/5xg7f8/the_origins_of_the_blocksize_debate/
Brief reminders of the ETC situation https://www.reddit.com/Bitcoin/comments/6nvlgo/simple_breakdown_of_bip91_its_simply_the_miners/dkcycrz/
Longer writeup of ethereum's TheDAO bailout fraud https://www.reddit.com/ethereumfraud/comments/6bgvqv/faq_what_exactly_is_the_fraud_in_ethereum/
Point that the bigblocker side is only blocking segwit as a hostage https://www.reddit.com/BitcoinMarkets/comments/5sqhcq/daily_discussion_wednesday_february_08_2017/ddi3ctv/?context=3
jonny1000's recall of the history of bitcoin https://www.reddit.com/Bitcoin/comments/6s34gg/rbtc_spreading_misinformation_in_rbitcoinmarkets/dl9wkfx/

Misc (mostly memes)

libbitcoin's Understanding Bitcoin series (another must read, most of it) https://github.com/libbitcoin/libbitcoin/wiki/Understanding-Bitcoin
github commit where satoshi added the block size limit https://www.reddit.com/Bitcoin/comments/63859l/github_commit_where_satoshi_added_the_block_size/
hard fork proposals from some core devs https://bitcoinhardforkresearch.github.io/
blockstream hasnt taken over the entire bitcoin core project https://www.reddit.com/Bitcoin/comments/622bjp/bitcoin_core_blockstream/
blockstream is one of the good guys https://www.reddit.com/Bitcoin/comments/6cttkh/its_happening_blockstream_opens_liquid_sidechain/dhxu4e
Forkers, we're not raising a single byte! Song lyrics by belcher https://gist.github.com/chris-belche7264cd6750a86f8b4a9a
Some stuff here along with that cool photoshopped poster https://medium.com/@jimmysong/bitcoin-realism-or-how-i-learned-to-stop-worrying-and-love-1mb-blocks-c191c35e74cb
Nice graphic https://twitter.com/RNR_0/status/871070843698380800
gmaxwell saying how he is probably responsible for the most privacy tech in bitcoin, while mike hearn screwed up privacy https://www.reddit.com/btc/comments/6azyme/hey_bu_wheres_your_testnet/dhiq3xo/?context=6
Fairly cool propaganda poster https://twitter.com/urbanarson/status/880476631583924225
btc tankman https://i.redd.it/gxjqenzpr27z.png https://twitter.com/DanDarkPill/status/853653168151986177
asicboost discovery meme https://twitter.com/allenscottoshi/status/849888189124947971
https://twitter.com/urbanarson/status/882020516521013250
gavin wanted to kill the bitcoin chain https://twitter.com/allenscottoshi/status/849888189124947971
stuff that btc believes https://www.reddit.com/Bitcoin/comments/6ld4a5/serious_is_the_rbtc_and_the_bu_crowd_a_joke_how/djszsqu/
after segwit2x NYA got agreed all the fee pressure disappeared, laurenmt found they were artificial spam https://twitter.com/i/moments/885827802775396352
theymos saying why victory isnt inevitable https://www.reddit.com/Bitcoin/comments/6lmpll/explaining_why_big_blocks_are_bad/djvxv2o/
with ignorant enemies like these its no wonder we won https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-999 ""So, once segwit2x activates, from that moment on it will require a coordinated fork to avoid the up coming "baked in" HF. ""
a positive effect of bcash, it made blockchain utxo spammers move away from bitcoin https://www.reddit.com/btc/comments/76lv0b/cryptograffitiinfo_now_accepts_bitcoin_cash/dof38gw/
summary of craig wright, jihan wu and roger ver's positions https://medium.com/@HjalmarPeters/the-big-blockers-bead6027deb2
Why is bitcoin so strong against attack?!?! (because we're motivated and awesome) https://www.reddit.com/btc/comments/64wo1h/bitcoin_unlimited_is_being_blocked_by_antivirus/dg5n00x/
what happened to #oldjeffgarzik https://www.reddit.com/Bitcoin/comments/6ufv5x/a_reminder_of_some_of_jeff_garziks_greatest/
big blockers fully deserve to lose every last bitcoin they ever had and more https://www.reddit.com/BitcoinMarkets/comments/756nxf/daily_discussion_monday_october_09_2017/do5ihqi/
gavinandresen brainstorming how to kill bitcoin with a 51% in a nasty way https://twitter.com/btcdrak/status/843914877542567937
Roger Ver as bitcoin Judas https://imgur.com/a/Rf1Pi
A bunch of tweets and memes celebrating UASF
https://twitter.com/shaolinfry/status/842457019286188032 | https://twitter.com/SatoshiLite/status/888335092560441345 | https://twitter.com/btcArtGallery/status/887485162925285377 | https://twitter.com/Beautyon_/status/888109901611802624 | https://twitter.com/Excellion/status/889211512966873088 | https://twitter.com/lopp/status/888200452197801984 | https://twitter.com/AlpacaSW/status/886988980524396544 | https://twitter.com/BashCo_/status/877253729531162624 | https://twitter.com/tdryja/status/865212300361379840 | https://twitter.com/Excellion/status/871179040157179904 | https://twitter.com/TraceMayestatus/849856343074902016 | https://twitter.com/TraceMayestatus/841855022640033792 | https://fs.bitcoinmagazine.com/img/images/Screen_Shot_2017-08-18_at_01.36.47.original.png
submitted by belcher_ to Bitcoin [link] [comments]

Don't buy the current massive FUD campaign, keep calm, Hodl and enjoy these facts...

Bitcoin keeps going on stronger than ever and its development is growing fast. Core developers are working really hard and efficiently. Check out this great summary by John Newbery:
https://twitter.com/jfnewbery/status/928642936555876354
Phew. I'm glad that madness is behind us. If you've been distracted in the last 6 months, you may have missed the real work happening.
We've released the most robust and performant Bitcoin client yet: https://bitcoincore.org/en/releases/0.15.0.1/ … (thanks to @orionwl and all contributors!)
Work continues apace on signature aggregation and batch validation (thanks to @pwuille and gmaxwell)
BIP159 is in the works so pruned nodes can serve recent blocks to their peers: https://github.com/bitcoin/bitcoin/pull/10387 … (thanks to @jonasschnelli)
Bitcoin has taken one small step (or is that a giant leap?) closer to the moon: https://blockstream.com/satellite/ (thanks to @adam3us and the Blockstream satellite team)
The fiber network continues to be made more robust, reducing miner centralization pressure: http://bitcoinfibre.org/ (thanks to @theBlueMatt)
A major Bitcoin service company has rolled out SegWit for over half its customers , cutting fees in half: https://blog.bitgo.com/bitgo-segwit-launch-4732163d2c7f … (thanks to @lopp and @murchandamus)
(shameless plug 😳) I've announced an initiative to help broaden and strengthen the Bitcoin developer community: http://hackerresidency.com
There are three (count 'em) lightning UIs: http://blog.lightning.engineering/announcement/2017/10/12/test-blitz.htmlhttp://zap.jackmallers.com/ https://github.com/alexbosworth/lnd-gui … (thanks to @roasbeef, @jackmallers and @alexbosworth)
... and work continues on four independent lightning implementations: https://github.com/lightninglabs/lightning-apphttps://github.com/ElementsProject/lightninghttps://github.com/ACINQ/eclair https://github.com/mit-dci/lit (thanks to @starkness, @rusty_twit, @acinq_co and @tdryja)
And in with a bullet, we now have aggregatable range proofs in O(log(n)) size for compact confidential transactions. Bang bang: http://web.stanford.edu/~buenz/pubs/bulletproofs.pdf …. (thanks to Benedikt Bünz)
Now imagine what we could have achieved together if we weren't also having to write code to protect user funds from a dangerous 2x fork.
Addendum: This list wasn't meant to be exhaustive, but turns out that I forget a bunch of stuff which is just far too cool to exclude.
First up: Neutrino - light clients done right: https://github.com/lightninglabs/neutrino … (thanks to @roasbeef and @stile65)
Eclair: another really cool looking lightning client:John Newbery added,
Announcing Eclair Wallet, a user-friendly android wallet for Lightning ⚡️https://medium.com/@ACINQ/announcing-eclair-wallet-a8d8c136fc7e … #bitcoinlightning
Three (at least) proposals for MAST (thanks @johnsonlau01, @MarkFriedenbach and Russell O'Connor)
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
submitted by readish to Bitcoin [link] [comments]

Bitcoin is stronger than ever.

Bitcoin keeps going on stronger than ever and its development is growing fast. Core developers are working really hard and efficiently. Check out this great summary by John Newbery:
https://twitter.com/jfnewbery/status/928642936555876354
Phew. I'm glad that madness is behind us. If you've been distracted in the last 6 months, you may have missed the real work happening.
We've released the most robust and performant Bitcoin client yet: https://bitcoincore.org/en/releases/0.15.0.1/ … (thanks to @orionwl and all contributors!)
Work continues apace on signature aggregation and batch validation (thanks to @pwuille and gmaxwell)
BIP159 is in the works so pruned nodes can serve recent blocks to their peers: https://github.com/bitcoin/bitcoin/pull/10387 … (thanks to @jonasschnelli)
Bitcoin has taken one small step (or is that a giant leap?) closer to the moon: https://blockstream.com/satellite/ (thanks to @adam3us and the Blockstream satellite team)
The fiber network continues to be made more robust, reducing miner centralization pressure: http://bitcoinfibre.org/ (thanks to @theBlueMatt)
A major Bitcoin service company has rolled out SegWit for over half its customers , cutting fees in half: https://blog.bitgo.com/bitgo-segwit-launch-4732163d2c7f … (thanks to @lopp and @murchandamus)
(shameless plug 😳) I've announced an initiative to help broaden and strengthen the Bitcoin developer community: http://hackerresidency.com
There are three (count 'em) lightning UIs: http://blog.lightning.engineering/announcement/2017/10/12/test-blitz.htmlhttp://zap.jackmallers.com/ https://github.com/alexbosworth/lnd-gui … (thanks to @roasbeef, @jackmallers and @alexbosworth)
... and work continues on four independent lightning implementations: https://github.com/lightninglabs/lightning-apphttps://github.com/ElementsProject/lightninghttps://github.com/ACINQ/eclair https://github.com/mit-dci/lit (thanks to @starkness, @rusty_twit, @acinq_co and @tdryja)
And in with a bullet, we now have aggregatable range proofs in O(log(n)) size for compact confidential transactions. Bang bang: http://web.stanford.edu/~buenz/pubs/bulletproofs.pdf …. (thanks to Benedikt Bünz)
Now imagine what we could have achieved together if we weren't also having to write code to protect user funds from a dangerous 2x fork.
Addendum: This list wasn't meant to be exhaustive, but turns out that I forget a bunch of stuff which is just far too cool to exclude.
First up: Neutrino - light clients done right: https://github.com/lightninglabs/neutrino … (thanks to @roasbeef and @stile65)
Eclair: another really cool looking lightning client:John Newbery added,
Announcing Eclair Wallet, a user-friendly android wallet for Lightning ⚡️https://medium.com/@ACINQ/announcing-eclair-wallet-a8d8c136fc7e … #bitcoinlightning
Three (at least) proposals for MAST (thanks @johnsonlau01, @MarkFriedenbach and Russell O'Connor)
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?
submitted by readish to btc [link] [comments]

Take SegWit Off the Table: Rebase BU to Core 0.14

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.
submitted by clarkmoody to btc [link] [comments]

Bitcoin company CTO here. Why I oppose Segwit.

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.
submitted by ZeroFucksG1v3n to Bitcoin [link] [comments]

"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

https://np.reddit.com/Bitcoin/comments/5ab7zi/bitcoin_company_cto_here_why_i_oppose_segwit/
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.
~ u/ZeroFucksG1v3n
submitted by ydtm to btc [link] [comments]

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.

https://np.reddit.com/btc/comments/5i0sg7/blocksize_scarcity_is_necessary_in_order_to/db4jb2a/
The more Greg Maxwell talks about economics, the deeper he digs himself into a hole.
He has become so blinded and corrupted by his own power, that now he has everything upside-down:
"a majority hashpower cartel undermining the decentralization of the network" (?!?)
"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 (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:
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"...
...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:
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...
Now, Greg just can't bring himself to let go of the immense awesome Olympian power he gets from being able to:
It all comes down to the same thing: power corrupts.
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:
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:
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."
https://np.reddit.com/btc/comments/459iyw/gmaxwell_in_2006_during_his_wikipedia_vandalism/
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.
https://np.reddit.com/btc/comments/4klqtg/people_are_starting_to_realize_how_toxic_gregory/
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/45ail1/wikipedians_on_greg_maxwell_in_2006_now_cto_of/
In other words (in his own words) he is so accustomed to being generally disliked due to his anti-social, anti-free-market behaviors, that he has now come to accept and embrace this as his lot in life, and he now wears it perversely and proudly.
Greg should instead try to wrap his head around some of the writings of John Blocke:
John Blocke: Bitcoin Economics in One Lesson
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...
  • which by the way, let us recall, Satoshi said we should have eliminated by now via an ultra-simple & safe fixed-flag-day hard fork.
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.
submitted by ydtm to btc [link] [comments]

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 logs Meeting 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.
Review "Improve usage of fee estimation code" BlueMatt will mail the developer mailinglist announcing the changes. ( https://www.mail-archive.com/[email protected]/msg02790.html )
Opt-in replace-by-fee
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 
Comic relief
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 
submitted by G1lius to Bitcoin [link] [comments]

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 logs Meeting 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.
Review PR 6722 Limit mempool by throwing away the cheapest txn and setting min relay fee to it Morcos/sipa will do some more benchmarks and comment on the PR ( morcos' benchmark results )
sendheaders BIP
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:
  1. A node (N) announces the new tip with an "inv" message, containing the block hash
  2. 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
  3. 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:
  1. Extend the version message.
  2. Have an "options" message that can send flags.
  3. Send a "sendheaders" message early when connecting so the way peers want their block announcement is immediately known.
  4. 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.
review versionbits implementation
dev/discuss list policy
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?
submitted by G1lius to Bitcoin [link] [comments]

Bitcoin dev meeting in layman's terms (2015-10-8)

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 logs link 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".
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).
Review & test Limit mempool by throwing away the cheapest txn and setting min relay fee to it Provide support for Lower default limits for tx chains aka convince people 25 should be enough.
Low-S change
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)
Contact miners about "Test LowS in standardness, removes nuisance malleability vector" Release scheduled for the end of the month, together with likely check-lock-time-verify and possibly check-sequence-verfiy.
CLTV & CSV backport review
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
submitted by G1lius to Bitcoin [link] [comments]

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 logs Meeting 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:
  1. 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.
  2. 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
submitted by G1lius to Bitcoin [link] [comments]

The flawed mind of jstolfi

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.
submitted by specialenmity to btc [link] [comments]

Is Monero immune from cryptographic breaks?

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.
submitted by johnrosenbaud11 to Monero [link] [comments]

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.

The graph below tells you everything you need to know about the way that Bitcoin price and volume normally always move in lockstep, tightly correlated with each other - until Blockstream tragically tried to interfere starting around 2015:
https://imgur.com/jLnrOuK
http://nakamotoinstitute.org/static/img/mempool/how-we-know-bitcoin-is-not-a-bubble/MetcalfeGraph.png
(There is a typo in the legend of the second graph linked above: "Bitcoin market map" should say "Bitcoin market cap[italization]".)
Bitcoin's "Metcalfe's Law" relationship between market cap and the square of the number of transactions
https://np.reddit.com/Bitcoin/comments/3x8ba9/bitcoins_metcalfes_law_relationship_between/
https://np.reddit.com/btc/comments/3x8mmc/bitcoins_metcalfes_law_relationship_between/
How We Know Bitcoin Is Not a Bubble
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:
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 not artificially 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
submitted by ydtm to btc [link] [comments]

Bitcoin is a one-party state

Definition here.
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?
submitted by tsontar to btc [link] [comments]

Bitcoins Value Proposition by Tone Vays BITCOIN HASHRATE HITS A HIGH - BTC PRICE WILL FOLLOW SAYS ... Historical Price of Bitcoin (2010 - 2019) WARNING !!! BITCOIN PRICE IN DANGER RIGHT NOW!!! MUST HOLD THIS KEY LEVEL !!! BITCOIN PRICE PLUMMETS IN MINUTES!  WHAT IS NEXT FOR BTC?

“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

[index] [6682] [268] [7433] [18680] [22631] [251] [26366] [29608] [26429] [19987]

Bitcoins Value Proposition by Tone Vays

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.

Flag Counter