Bitcoin Core version 0.17.0 released

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]

What's the f*****ng benefit of the reactivated OP_Codes?

Nobody explained what we can do with the soon to be reactivated OP_Codes for Bitcoin Cash, and nobody explained why we need them. It's a fact that there are risks associated with them, and there is no sufficient testing of these risks by independent developers, nor is there a sufficient explanation why they carry no risk. BitcoinABC developers, explain yourselves, please.
Edit: Instead of calling me a troll, please answer the question. If not, ask someone else.
Edit Edit: tomtomtom7 provided a resfreshing answer on the question:
https://www.reddit.com/btc/comments/7z3ly4/to_the_people_who_thing_we_urgently_need_to_add/dulkmnf/
The OP_Codes were disabled because bugs were found, and worry existed that more bugs could exist.
They are now being re-enabled with these bugs fixed, with sufficient test cases and they will be put through thorough review.
These are missing pieces in the language for which various use cases have been proposed over the years.
The reason to include these, is because all developers from various implementations have agreed that this is a good idea. No objections are raised.
Note that this does not mean that all these OP_Codes will make it in the next hardfork. This is obviously uncertain when testing and reviewing is still being done.
This is not yet the case for OP_GROUP. Some objection and questions have been raised which takes time to discuss and time to come to agreement. IMO this is a very healthy process.
Another good comment is here
https://www.reddit.com/btc/comments/7z49at/whats_the_fng_benefit_of_the_reactivated_op_codes/dullcek/
One precise thing: Allowing more bitwise logical operators can (will) yield smaller scripts, this saves data on the blockchain, the hex code gets smaller.
Here is a detailled answer. I did not goe through it if it is satisfying, but at least it is a very good start, Thank you silverjustice.
But further, if you want specific advantages for some of these, then I recommend you check out the below from the scaling Bitcoin conference:
opcodes are very useful, such as in for example with CAT you can do tree signatures even if you have a very complicated multisig design using CAT you could reduce that size to log(n) size. It would be much more compact. Or with XOR we could do some kind of deterministic random number generator by combining secret values from different parties so that nobody could cheat. They could combine and generate a new random number. If people think-- ... we could use LEFT to make weaker hash. These opcodes were re-enabled in sidechain elements project. It's a sidechain from Bitcoin Core. We can reintroduce these functions to bitcoin.
The other problem are the ... numeric operations which were disabled by Satoshi. There's another problem. Which is that the range of values accepted by script is limited and confused because the CScript.. is processed at ..... bit integers internally. But to these opcodes it's only 32 bits at most. So it's quite confusing. The other problem is that we have this.. it requires 251 encode or calculate or manipulate this number. So we need at least 52 bits. But right now it is only 32 bits. So the proposal is to expand the valid input range to 7 bytes which would allow 56 bits. And it limits the maximum size to 7 bytes so we could have the same size for inputs and outputs. For these operations, we could re-enable them within these safe limits. It would be safe for us to have these functions again.
The other problem is that we currently cannot commit to additional scripts. In the original design of bitcoin, we could have script operations inside of the signature. But the problem is that the signature is not covered by the signature itself. So any script in the scriptSig is modifiable by any third party in the network. For example, if we tried to do a CHECKSIG operation in the signature, people could simply replace it with an OP_0 and invalidate the transaction. This is a bypass of the.. signature check in the scriptSig. But actually this function is really useful, for example, we can do... delegation, people could add additional scripts to a new UTXO without first spending it. So people could do something like let's say to let their son spend their coin within a year if it is not first spent otherwise.. and also, people, talk about replay protection. So we have some ohter new opcode like pushing the blockhash to the stack, with this function we could have replay protection to make sure the transaction is valid only in a specified blockchain.
So the proposal is that in the future the CHECKSIG should have the ability to sign additional script and to execute these scripts. And finally the other problem is that the script has limited access to different parts of the transaction. There is only one type of operation that allowed to investigate different parts of the transaction, which is CHECKSIG and CHECKMULTISIG. But it is very limited. There are sighash limitations here... there are only 6 types of sighash. The advantage of doing this is that it's very compact and could use only one byte to indicate which component to sign. But the problem is that it's inflexible. The meaning of this sighash is set at the beginning and you can't change it. You need a new witness version to have another checksig. And the other problem is that the sighash can be complex and people might make mistakes so Satoshi made this mistake in the sighash design such as the well-known bug in validation time and also the SIGHASH_SINGLE bug. It's not easy to prevent.
The proposal is that we might have the next generation of sighash (sighashv2) to expand to two bytes, allow it to cover different parts of the transaction and allow people to choose which components they would like to sign. This would allow more flexibility and hopefully not overly complicated. But still this is probably not enough for more flexible design.
Another proposal is OP_PUSHTXDATA which pushes the value of different components of a transaction to the stack. It's easy to implement, for example, we could just push the scriptpubkey of the second output to the stack, okay. So it is actually easier to implement. We could do something more than just... because we have sighash, we could check where something is equal to the specified value. But if we could push the value, like the value of an output to the stack, then we could use other operations like more than or less than and then we could do something like checking whether the value of output x must be at least y bitcoin, which is a fixed value.
There are some other useful functions like MAST which would allow for more compact scripts by hiding the other unexecuted branches. There's also aggregation that would allow n-of-n multisig to be reduced to a single signature and so on. In the elements project, they implemented CHECKSIGFROMSTACK where they don't check the transaction structure but instead they verify a message on the stack. So it could be some message like not bitcoin maybe, perhaps cross-chain swap, or another bitcoin UTXO. And also we might have some elliptic curve point addition and operations which are also useful in lightning network design.
Here are some related works in progress. If you are interested in this topic, I would like to encourage you to join our discussions because it's a very active topic. jl2012 bip114 MAST, maaku's MBV, luke-jr or version-1 witness program, Simplicity, etc.
so you have your script template the amount value and there is a block impactor beause we have the sha chain whih allows you to hae the hashes.. we can hae that errortate constant beause you need the HTLC chashes, to properly reoke the prior states and if you an't do that then you can't onstruct the redeem script. Right now it ineeds a signature for eery state, you need all the HTLCs, it needs the netowrk erification state, and there's another cool thing you can do with which is like trap door erification and you can include it in the transaction itself and there can be a alsue where there is some margin for it.. Which make sit powerful, and then you can make it more private with these constructs. We only have a few minutes left, we can cover this.
One furthe rthing is that in the transformation, we have privacy issue because we need to keep going forward, we need to have hte private state, so there's a history of this in the ages in the past, the current one used replications, which was one of the cool things about lightning. We used to have deckman signatures we had a sequence value of like 30 days, we did an update, we had to switch sides then we make it 29 then 27 etc. You can only broadcast the most recent state because otherwise the other party can transact the other transaction. If you start with 30 days then you can only do about 30 bidirectiona lswitches. Then there was cdecker's payment channels where you have a root tree and every time you need to- you had two payment channels, you had to rebalance htem and then it's on your part of the channel you can reset the channel state. You can do 30 this way, you have another tree, you can do it that way, and then there's a new version of it in the indefinite lifetime... by keeping the transaction in CSV, the drawback on that paproahc because you have al arge validation tree, in the worst cas eyou have 8 or 10 on the tree, and then you nee dfor the prior state and then you do the 12 per day, and every time you have to make a state, you have to revoke the preimage from the prior state, this is cool because if they ever broadcast the entire state, eahc one has the caluse so that you can draw the entire money in the event o f a violation. There are some limitations for doing more complex verifications and you have this log(n) state that you have to deal with ehen you deal with that.
We're going to do the key power on the stack to limit key verifications on this main contract. this is all composable. You can do discreet log contracts. You can now check signtures on arbitrary messages. You can sign a message nad then we can enforce structure on the messages themselves. Right now you need to have sequene numbers. So each state we are going to increment the sequence numbers. So you give me a siequence number on that state. On the touputs we have a commitment ot the sequence number and the value r. So people on chain will know that how many places we did in that itself. The ool part about this is that because we have a seq number then I have the one if it's highest neough. Then I am opening that commitment to say this is state 5 and I present to you a new signed ommitment and open that as well, that's in a validation state. The cool things is that you only need one of those m. So we have to some auxiliary state, and each time I have a new state I an drop the old state. I have a signed commitment to revoke the prior state. This is a ibg deal beause the state is much smaller. Currently we require you to fwe use a state mahcine on state 2, and it also has implications for verifications and watch tower
So on lightning, there's this technique itself- it's timelocks CSV value and if you can't react within that value then you can't go to court and enforce judgement on this attacker. So the watchtower is a requirement, you delegate the state watching to the watchtower. They know which channels you're watching. You send some initial points, like a script template. For every one you send the signautre and the verification state. They can use the verification stat ethat collapses into a log(n) tree, you can basically use state where you send half the txids, you can decrypt this in... some time.
submitted by Der_Bergmann to btc [link] [comments]

So, on the expiration date of the HK stalling / non-scaling non-agreement, Viacoin scammer u/btcdrak calls a meeting with no customer-facing businesses invited (just Chinese miners & Core/Blockstream), and no solutions/agreements allowed, and no transparency (just a transcript from u/kanzure). WTF!?

TL;DR: Bitcoin's so-called "governance" is being hijacked by some anonymous scammer named u/btcdrak who created a shitcoin called Viacoin and who's a subcontractor for Blockstream - calling yet another last-minute stalling / non-scaling meeting on the expiration date of Core/Blockstream's previous last-minute stalling / non-scaling non-agreement - and this non-scaling meeting is invite-only for Chinese miners and Core/Blockstream (with no actual Bitcoin businesses invited) - and economic idiot u/maaku7 who also brought us yet another shitcoin called Freicoin is now telling us that no actual solutions will be provided because no actual agreements will be allowed - and this invite-only no-industry no-solutions / no-agreements non-event will be manually transcribed by some guy named u/kanzure who hates u/Peter__R (note: u/Peter__R gave us actual solutions like Bitcoin Unlimited and massive on-chain scaling via XThin) - and as usual this invite-only non-scaling no-solutions / no-agreements no-industry invite-only non-event is being paid for by some fantasy fiat finance firm AXA whose CEO is head of the Bilderberg Group which will go bankrupt if Bitcoin succeeds. What the fuck?!?
Any update on the Silicon Valley meeting underway?
I was the one who encouraged this event to happen and I made the arrangements, so all blame should be directed to me.
~ u/btcdrak
https://np.reddit.com/btc/comments/4vdjhn/any_update_on_the_silicon_valley_meeting_underway/d5y5aqi
The 21 February 2016 Hong Kong Roundtable agreement expires on 31 July 2016.
Btcdrak (Blockstream contractor or at least supporter) organizes "an invite-only social event with Blockstream and Chinese miners" on 30+31 July 2016.
"Agreements explicitly forbidden"
https://np.reddit.com/btc/comments/4vfkpthe_fedfomc_holds_meetings_to_decide_on_money/d5y5co4
This is a good faith social event with agreements explicitly forbidden from coming out of it.
~ u/maaku
https://np.reddit.com/btc/comments/4vfkpthe_fedfomc_holds_meetings_to_decide_on_money/d5y0pec
To be clear, myself, Peter Smith, CEO of Blockchain.info, and I assume just about every other consumer facing business were not invited. It seems to only be Miners, and Core.
~ u/MemoryDealers
https://np.reddit.com/btc/comments/4vdjhn/any_update_on_the_silicon_valley_meeting_underway/d5y3ls9
What's the story with the ViaCoin scam? Anyone one know details?
https://np.reddit.com/btc/comments/42depj/whats_the_story_with_the_viacoin_scam_anyone_one/
BTCdrak forked bitcoin and hired Peter Todd to insert some new, basically useless feature that was purely for marketing hype.
ViaCoin was initially sold with a marketcap of $380,000 which is approximately how much BTCDrak made from the coin without including additional mining profits if he had any.
Then, like every other altcoin scam, the creator walked away holding a bag of fiat currency and laughing like a fool.
So, let me see if I understand this correctly:
Did I leave anything out?
What the fuck is actually going on here?!?
submitted by ydtm to btc [link] [comments]

/u/vampireban wants you to believe that "a lot of people voted" and "there is consensus" for Core's "roadmap". But he really means only 57 people voted. And most of them aren't devs and/or don't understand markets. Satoshi designed Bitcoin for *the economic majority* to vote - not just 57 people.

vampireban has been very busy lately on r\bitcoin and btc, trying to preach his depressing message of hopelessness and resignation to the masses:
segwit and lightning, not our solution but an ok solution and time to plan for success
https://np.reddit.com/btc/comments/4e8nn9/segwit_and_lightning_not_our_solution_but_an_ok/
segwit and lightning, time to plan for success
https://np.reddit.com/Bitcoin/comments/4e8hqo/segwit_and_lightning_time_to_plan_for_success/
He's trying to convince people that there has been some kind of "election":
"a lot of people voted so it is time to call the election and in the grand scheme it is probably good enough"
But when he says "a lot of people voted" in an "election", he's only talking about a tiny handful of 57 people who actually "voted".
They are all part of a self-selected group of so-called "Core" "devs" who, by definition, also support Core's "roadmap" - which vampireban repeatedly links to as if we're supposed to be impressed or intimidated by it:
https://bitcoincore.org/en/2015/12/21/capacity-increase/
He is trying to use that page as if it were some kind of "vote" showing "consensus" for Core's "roadmap".
But who are these 57 people?
How many of them are actually "devs"?
How many of them actually understand markets and economics?
To paraphrase tsontar: "If 57 smart guys on a webpage could outsmart the market, we wouldn't need Bitcoin."
Satoshi designed Bitcoin itself to be our voting system. This is the whole meaning of "voting with your CPU" - also known as "Nakamoto consensus".
And now vampireban wants everyone to throw out Satoshi's invention.
He wants us to throw out on-chain scaling and Nakamoto consensus... and go back to the bad old days, where 57 self-appointed "experts" could get together and decide everything for the rest of us.
And actually, calling these people "experts" is also a bit of a stretch or exaggeration.
Let's look at the HTML source for the page of "Core" "devs" who are "signatories" to Core's "roadmap":
https://bitcoincore.org/en/2015/12/21/capacity-increase/
https://bitcoin.org/en/bitcoin-core/capacity-increases
https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#roadmap
In the HTML page source, you can see that each of these "devs" has a link to their so-called GitHub repo.
But in most cases, their repo is empty - or it only includes 1-2 commits.
Often these commits are just minor formatting changes - merely involving a cosmetic change to a display string, or a change to a README.md file.
https://github.com/bitcoin/bitcoin/commits?author=adam3us
https://github.com/bitcoin/bitcoin/commits?author=morcos
https://github.com/bitcoin/bitcoin/commits?author=voisine
https://github.com/bitcoin/bitcoin/commits?author=bpdavenport
https://github.com/bitcoin/bitcoin/commits?author=bgorlick
https://github.com/bitcoin/bitcoin/commits?author=bramcohen
https://github.com/bitcoin/bitcoin/commits?author=kanzure
https://github.com/bitcoin/bitcoin/commits?author=btcdrak
https://github.com/bitcoin/bitcoin/commits?author=coblee
https://github.com/bitcoin/bitcoin/commits?author=cdecker
https://github.com/bitcoin/bitcoin/commits?author=cobra-bitcoin
https://github.com/bitcoin/bitcoin/commits?author=theuni
https://github.com/bitcoin/bitcoin/commits?author=crwatkins
https://github.com/bitcoin/bitcoin/commits?author=arowser
https://github.com/bitcoin/bitcoin/commits?author=domob1812
https://github.com/bitcoin/bitcoin/commits?author=harding
https://github.com/bitcoin/bitcoin/commits?author=DavidVorick
https://github.com/bitcoin/bitcoin/commits?author=devrandom
https://github.com/bitcoin/bitcoin/commits?author=dexX7
https://github.com/bitcoin/bitcoin/commits?author=jrmithdobbs
https://github.com/bitcoin/bitcoin/commits?author=CodeShark
https://github.com/bitcoin/bitcoin/commits?author=ghtdak
https://github.com/bitcoin/bitcoin/commits?author=gmaxwell
https://github.com/bitcoin/bitcoin/commits?author=instagibbs
https://github.com/bitcoin/bitcoin/commits?author=jameshilliard
https://github.com/bitcoin/bitcoin/commits?author=jmcorgan
https://github.com/bitcoin/bitcoin/commits?author=jl2012
https://github.com/bitcoin/bitcoin/commits?author=jonasschnelli
https://github.com/bitcoin/bitcoin/commits?author=Joukehofman
https://github.com/bitcoin/bitcoin/commits?author=greenaddress
https://github.com/bitcoin/bitcoin/commits?author=luke-jr
https://github.com/bitcoin/bitcoin/commits?author=maaku
https://github.com/bitcoin/bitcoin/commits?author=martindale
https://github.com/bitcoin/bitcoin/commits?author=maraoz
https://github.com/bitcoin/bitcoin/commits?author=MarcoFalke
https://github.com/bitcoin/bitcoin/commits?author=TheBlueMatt
https://github.com/bitcoin/bitcoin/commits?author=midnightmagic
https://github.com/bitcoin/bitcoin/commits?author=fanquake
https://github.com/bitcoin/bitcoin/commits?author=btchip
https://github.com/bitcoin/bitcoin/commits?author=NicolasDorier
https://github.com/bitcoin/bitcoin/commits?author=obi
https://github.com/bitcoin/bitcoin/commits?author=pstratem
https://github.com/bitcoin/bitcoin/commits?author=paveljanik
https://github.com/bitcoin/bitcoin/commits?author=petertodd
https://github.com/bitcoin/bitcoin/commits?author=sipa
https://github.com/bitcoin/bitcoin/commits?author=randy-waterhouse
https://github.com/bitcoin/bitcoin/commits?author=nvk
https://github.com/bitcoin/bitcoin/commits?author=rubensayshi
https://github.com/bitcoin/bitcoin/commits?author=sdaftuar
https://github.com/bitcoin/bitcoin/commits?author=theymos
https://github.com/bitcoin/bitcoin/commits?author=afk11
https://github.com/bitcoin/bitcoin/commits?author=wangchun
https://github.com/bitcoin/bitcoin/commits?author=wtogami
https://github.com/bitcoin/bitcoin/commits?author=laanwj

So, lots of these so-called "Core devs" haven't actually ever written code for Bitcoin.
But wait, it gets worse than that: Lots of them also don't actually understand markets or economics either.
For example, many of us have already commented on the fact that Adam Back and Greg Maxwell are clueless are when it comes to markets and economics:
Adam Back & Greg Maxwell are experts in mathematics and engineering, but not in markets and economics. They should not be in charge of "central planning" for things like "max blocksize". They're desperately attempting to prevent the market from deciding on this. But it will, despite their efforts.
https://np.reddit.com/btc/comments/46052e/adam_back_greg_maxwell_are_experts_in_mathematics/
And many of the lesser-known "Core" "devs" (who look up to Greg and Adam) are also clueless about markets and economics.
For example, meet maaku7 - another "Core" "dev" who "voted" for Core's "roadmap". Here he was a few months ago on reddit, proudly exposing his ignorance about markets and economics:
"Core dev" maaku7 is on the front page today for saying he'd "quit" if users were the "boss" of Bitcoin. He was already being laughed at yesterday in another thread for saying he thought fiat was run by "majority-vote". Let him "quit". He never actually understood how Bitcoin works.
https://np.reddit.com/btc/comments/41j818/core_dev_umaaku7_is_on_the_front_page_today_fo
So basically what vampireban is saying is: 57 people - many of who don't contribute code to Bitcoin, and/or don't understand economics - have "voted", and so we should all just accept that an move on.
But that is not the system that Satoshi designed.
Satoshi designed Bitcoin to allow the economic majority to vote using their CPU. He did not design a system where only 57 wannabe devs and economic noobs can vote using some web page linked to a bunch of mostly-empty Github repos.
Satoshi also happened to disagree rather vehemently with Core's "roadmap".
He preferred the simplest approach that would work - hard-fork the code, to support bigger blocks:
"The existing Visa credit card network processes about 15 million Internet purchases per day worldwide. Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost. It never really hits a scale ceiling." - Satoshi Nakomoto
https://np.reddit.com/btc/comments/49fzak/the_existing_visa_credit_card_network_processes/
We've heard this message of hopeless and resignation many times before.
vampireban is like the new Marget Thatcher, beating everyone over the head telling us "TINA" = "There Is No Alternative".
But he's wrong.
There actually is an alternative.
In fact, there are several alternatives.
And they're already running smoothly on the Bitcoin main network.
They're called Bitcoin Classic, Bitcoin Unlimited and BitcoinXT.
They already provide simple scaling without the complexity and fragility of SegWit-as-a-softfork - and without the complexity and centralization of Lightning-with-no-pathfinding.
Which approach do you think would be the simplest and safest way to provide scaling for Bitcoin right now?
  • listening to Satoshi, who designed a system where the economic majority can vote directly with their CPU, using a permissionless decentralized network called Bitcoin, or
  • listening to vampireban, who wants to replace Bitcoin's built-in voting system with 57 wannabe devs and economic noobs who signed some web page?
submitted by ydtm to btc [link] [comments]

Bitcoin dev IRC meeting in layman's terms (or an attempt to)

As you may or may not know, since scaling bitcoin in Montreal there's a weekly dev meeting on IRC. While very interesting to read, as a non-technical person such as myself it really takes some time to understand what they're all talking about, but I do like to know what they are working on.
Since I'm doing the work to find out anyway, I might as well share it with the community.
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.
The full IRC-logs can be found here.
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.
Main topics discussed where: Mempool limiting BIP68 + CHECKSEQUENCEVERIFY CLTV soft fork deployment libconsensus merge time window
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.
There are multiple worked out ideas for this, namely: Limit mempool by throwing away the cheapest txn and setting min realy fee to it Mempool limiting with descendant package tracking exponential rising effective min relay feerate
devs are leaning towards 6722 (throwing away the cheapest txn and setting min relay fee to it) because it's the more simpler approach and possibly less edge-cases. The idea behind it is to have a mem-pool that gives a good approximation on what'll be included in the next blocks, meaning higher fee transactions. This approach also helps to build a fee-estimator. Some devs propose to include a time-based eviction as well.
6722 should be completed and 6722, 6557 and 6673 should be attacked by the others to try and find edge-cases. The default mempool size should be 300Mb.
Chain limits
Related to mempool limiting. 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 referred to as "packages".
All of the mempool limiting approaches are way easier to attack if you have bigger chain limits. the reason to have larger descendant packages is you can't control that yourself, somebody pays you and bob, and bob chains off a million descendants and he ends up screwing you. if you have a say 900kb ancestor package limit, then even if the ancestor fee rate is reasonably high, default mining code is likely going to find 100kb of very high fee txs to include first, and then there won't be room for your ancestor package. Morcos proposes 25/250kb for ancestors and 50/500kb for descendants, meaning max. either 25 transactions or 250kb in size for ancestors. Most seem to be fine with those limits and even smaller.
-meeting conclusion
morcos writes a chain-limit proposal to post on the mailing list in order to find possible usecases for large chain transactions.
CHECKLOCKTIMEVERIFY softfork
Commonly referred to as: How you thought nLockTime worked before you actually tried to use it. There's a fair amount of demand for this and the code is reviewed and has been running on sidechains alpha for 6 months. The only real issue is how and when it's merged. Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than X 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.
Questions are being posed whether we wait for other time-related BIP's and/or versionbits, or do it now using isSuperMajority. If versionbits is deployed later it needs to wait for all supermajority softforks to be over. Vladimir van der Laan doesn't want to deploy any soft forks in major releases (0.12 in this case) so that people explicitly upgrade for the softfork not for other things. You could roll out multiple supermajority forks as long as they are cumulative. Talks seem to converge to using supermajority to deploy checkLockTimeVerify and checkSequenceVerify if it's ready by the end of October.
checkLockTimeVerify backports (deployment in older versions) needs to be reviewed as well as BIP68, 112 and 113 (all the time-related BIP's).
Libconsensus
Satoshi wasn't the best programmer out there, which leaves a pretty messy code. Ideally you'd have the part of the code that influences the network consensus separately, but in bitcoin it's all intertwined. Libconsensus is what eventually should become this part. This way people can more easily make changes in the non-consensus part without fear of causing a network fork. This however is a slow and dangerous project of moving lot's of code around.
Lot's of discussion on when existing changes should be merged, when the code should be frozen for next release etc. In linux changes are merged right after a major release. jtimon notices this was planned for after 0.10 and 0.11 too, but nothing happened. There seems to be a lack of planning and overview as to what where has to go.
jtimon will provide a high level rationale for what and where things should move so people can make comments and review according to this rationale.
Participants
dstadulis Daniel Stadulis wumpus Wladimir J. van der Laan morcos Alex Morcos gmaxwell Gregory Maxwell btcdrak btcdrak jonasshnelli Jonas Schnelli maaku Mark Friedenbach sdaftuar Suhas Daftuar sipa Pieter Wuille BlueMatt Matt Corallo CodeShark Eric Lombrozo Luke-Jr Luke Dashjr bsm117532 Bob McElrath jgarzik Jeff Garzik
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 IRC meeting in layman's terms (2016-01-28)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last summarisation
Disclaimer
Please bear in mind I'm not a developer so some things might be incorrect or plain wrong. There are no decisions being made in these meetings, but since a fair amount of devs are present it's a good representation. Copyright: Public domain

Logs

Main topics

Short topics

ajtowns has written some functional test scripts for OP_CSV which will be helpful for testing #7184(BIP 68) and #6564(BIP 112)

Refactoring window

background

jtimon asks when exactly this is and what it entails. Refactoring is moving code around to specific libraries or files to make things easier to read and to safely change parts of the code without affecting other parts. Mainly these will be moves to facilitate libconsensus, the part that will hold all the consensus-critical code.

meeting comments

Wumpus is fine with starting to merge moveonly stuff. The refactors might interfere with segregated witness, however waiting for it might cause the refactor window for 0.13 to be missed.

meeting conclusion

Refactor window is from now till -undecided- Review #7091, #7287, #7310 and #7311

outstanding issues for 0.12.0

background

Bitcoin Core 0.12 is scheduled for release around February and introduces a lot of fixes and improvements. (release notes) There's a release candidate 0.12rc2 available at https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

meeting comments

We need to sign the win32 release with a new key for win7+ as the current key uses sha-1 which is broken. There's still some controversy how the changes for priority should be noted in the release notes. e.g. #7346 gmaxwell points out we never did anything about the issues with localhost being whitelisted which might cause issues with the new automatic hidden service creation. This issue was raised in the 2015/12/03 meeting

meeting conclusion

There will be a new key, if it takes too long to get it someone else can sign it this time. gmaxwell will change #7082 to only remove the privledging of localhost. The rest of the PR can be done for 12.1/0.13

how does this new "critical" OpenSSL release affect us

background

There's a new openSSL release which fixes some security issues. https://mta.openssl.org/pipermail/openssl-announce/2016-January/000061.html Question is if and how this affects bitcoin. Since 0.12 bitcoin-core uses their own libsecp256k1 for ECDSA signature verification instead of openSSL.

meeting comments

BIP70 (Payment Protocol) might be affected. The parts of core that still depend on openSSL are entropy, AES (wallet) and BIP70. There's a plan to replace openSSL for entropy with fortuna (build by sipa and gmaxwell), which needs to be build into a separate library. There are many complications in making a safe random number generator, first among them is fork detection (fork= a unix operation which duplicates the entire process state which will lead to reuse of random numbers) Wumpus notes openSSL has the same issues and we only have to be better than openSSL, also bitcoin never forks so the problem is mainly for other applications using the library. It would be good if this was an effort which included non-bitcoin users (e.g. mailinglist & tor)

meeting conclusion

Long term goal is leaving openSSL only for BIP70.

Participants

wumpus Wladimir J. van der Laan jonasschnelli Jonas Schnelli gmaxwell Gregory Maxwell petertodd Peter Todd jtimon Jorge Timón cfields Cory Fields btcdrak btcdrak Luke-Jr Luke Dashjr paveljanik Pavel Janik maaku Mark Friedenbach 

Comic relief

19:47 wumpus note also that bitcoin never forks 19:48 wumpus gmaxwell: just add a disclaimer 'not fork safe' 19:48 jonasschnelli 'not fork safe'? HF or SF.... 19:48 jonasschnelli  
submitted by G1lius to Bitcoin [link] [comments]

Merkle branch verification & tail-call semantics for generalized MAST | Mark Friedenbach | Sep 07 2017

Mark Friedenbach on Sep 07 2017:
I would like to propose two new script features to be added to the
bitcoin protocol by means of soft-fork activation. These features are
a new opcode, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution
semantics.
In brief summary, MERKLE-BRANCH-VERIFY allows script authors to force
redemption to use values selected from a pre-determined set committed
to in the scriptPubKey, but without requiring revelation of unused
elements in the set for both enhanced privacy and smaller script
sizes. Tail-call execution semantics allows a single level of
recursion into a subscript, providing properties similar to P2SH while
at the same time more flexible.
These two features together are enough to enable a range of
applications such as tree signatures (minus Schnorr aggregation) as
described by Pieter Wuille [1], and a generalized MAST useful for
constructing private smart contracts. It also brings privacy and
fungibility improvements to users of counter-signing wallet/vault
services as unique redemption policies need only be revealed if/when
exceptional circumstances demand it, leaving most transactions looking
the same as any other MAST-enabled multi-sig script.
I believe that the implementation of these features is simple enough,
and the use cases compelling enough that we could BIP 8/9 rollout of
these features in relatively short order, perhaps before the end of
the year.
I have written three BIPs to describe these features, and their
associated implementation, for which I now invite public review and
discussion:
Fast Merkle Trees
BIP: https://gist.github.com/maaku/41b0054de0731321d23e9da90ba4ee0a
Code: https://github.com/maaku/bitcoin/tree/fast-merkle-tree
MERKLEBRANCHVERIFY
BIP: https://gist.github.com/maaku/bcf63a208880bbf8135e453994c0e431
Code: https://github.com/maaku/bitcoin/tree/merkle-branch-verify
Tail-call execution semantics
BIP: https://gist.github.com/maaku/f7b2e710c53f601279549aa74eeb5368
Code: https://github.com/maaku/bitcoin/tree/tail-call-semantics
Note: I have circulated this idea privately among a few people, and I
will note that there is one piece of feedback which I agree with but
is not incorporated yet: there should be a multi-element MBV opcode
that allows verifying multiple items are extracted from a single
tree. It is not obvious how MBV could be modified to support this
without sacrificing important properties, or whether should be a
separate multi-MBV opcode instead.
Kind regards,
Mark Friedenbach
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Septembe014932.html
submitted by dev_list_bot to bitcoin_devlist [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 (2016-01-21)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last summarisation
Disclaimer
Please bear in mind I'm not a developer so some things might be incorrect or plain wrong. There are no decisions being made in these meetings, but since a fair amount of devs are present it's a good representation. Copyright: Public domain

Logs

Main topics

Short topics

0.11 backport release for chainstate obfuscation

background

As some windows users might have experienced in the past, anti-virus software regularly detects values in the bitcoin database files which are false-positives. Thereby deleting those files and corrupting the database. To prevent this from happening developers discussed a way to obfuscate the database files and implemented it last year. While downgrading after upgrading is possible, if you start from a new 0.12 installation or you've done a -reindex on 0.12 it's impossible to downgrade to 0.11 (without starting from scratch).

meeting comments

The proposed pull-request detects the obfuscation in 0.11 so it throws a relevant error message. To avoid this in the future it would be good to have versionnumbers for the chainstate.

meeting conclusion

Release a 0.11 backport release right after the 0.12 final release to avoid confusion.

C++11 update

background

C++11 is an update of the C++ language. It offers new functionalities, an extended standard library, etc. Zerocash had to be written with some c++11 libraries and some IBLT simulation code was written in c++11, which they want to recycle for the eventual core commit.

meeting comments

All changes needed for C++11 have gone in and it's ready to switch. Cfields talked to the travis team and all the features needed (trusty, caching) will be ready by the end of the month, so he proposes to wait until then to flip the switch. Wangchung from f2pool indicated he would not run code that required a C++11 compiler. No one knows what his exact concerns are. Wumpus notes the gitian-built executables don't need any special OS support after the C++11 switch.

meeting conclusion

Wait for Travis update to switch to C++11. Talk to wangchung about his concerns.

EOL Policy / release cycles

background

In general bugfixes, translations and softforks are maintained for 2 major releases. btcdrak proposed to makes this official into a software life-cycle document for bitcoin core in order to inform users what to expect and developers what to code for. Pull request for this document. Given the huge 0.12 changelog jonasschnelli asks whether shorter release cycles might be a good idea. Currently there's a +/- 6 month release cycle.

meeting comments

Gmaxwell notes he doesn't know how useful the backports are given there's no feedback about them, but thinks the current policy is not bad. "I am observing the backports appear to be a waste of time. From a matter of principle, I think they are important, but the industry doesn't appear to agree." If no one is using the backports, it might not see sufficient testing. People generally agree with the 2 major releases approach.
The cyclelength also contributes to frustration and pressure to get features in, as it won't see the light of day for 6 months if it doesn't make the new release. For users it's not really better to have more frequent major releases, as upgrading may not always be a trivial process. There's also a lot of work going into releases. If the GUI and wallet where detached there could be more frequent releases for that part.

meeting conclusion

Policy will be: final release of 0.X means end-of-life of 0.(X-2), which means a 1 year support on the 6 month cycle.

Participants

wumpus Wladimir J. van der Laan gmaxwell Gregory Maxwell jonasshnelli Jonas Schnelli cfields Cory Fields btcdrak btcdrak sipa Pieter Wuille jtimon Jorge Timón maaku Mark Friedenbach kangx_ ??? Kang Zhang ??? sdaftuar Suhas Daftuar phantomcircuit Patrick Strateman CodeShark Eric Lombrozo bsm117532 Bob McElrath dkog ?dkog? jeremias ??? Jeremias Kangas ??? 

Comic relief

jonasschnelli maaku: refactoring? We have a main.cpp. We don't need refactoring. :) gmaxwell jonasschnelli: can we move everything back into main.cpp? I'd save a lot of time grepping. :P wumpus #endmeeting lightningbot` Meeting ended Thu Jan 21 19:55:48 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) btcdrak wumpus: hole in one maaku Did it right this time! gmaxwell Hurray! 
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]

[BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime | Btc Drak | Aug 13 2015

Btc Drak on Aug 13 2015:
I have written the following draft BIP for a new opcode
CHECKSEQUENCEVERIFY by Mark Friedenbach, which introduces a form of
relative-locktime to Bitcoin's scripting language.
https://github.com/btcdrak/bips/blob/bip-checksequenceverify/bip-csv.mediawiki
BIP: XX
Title: CHECKSEQUENCEVERIFY
Authors: BtcDrak <btcdrak at gmail.com>
 Mark Friedenbach <[mark at friedenbach.org](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev)> 
Status: Draft
Type: Standards Track
Created: 2015-08-10
==Abstract==
This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin
scripting system that in combination with BIP 68 allows execution
pathways of a script to be restricted based on the age of the output
being spent.
==Summary==
CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed
it compares the top item on the stack to the inverse of the nSequence
field of the transaction input containing the scriptSig. If the
inverse of nSequence is less than the sequence threshold (1 << 31),
the transaction version is greater than or equal to 2, and the top
item on the stack is less than or equal to the inverted nSequence,
script evaluation continues as though a NOP was executed. Otherwise
the script fails immediately.
BIP 68's redefinition of nSequence prevents a non-final transaction
from being selected for inclusion in a block until the corresponding
input has reached the specified age, as measured in block heiht or
block time. By comparing the argument to CHECKSEQUENCEVERIFY against
the nSequence field, we indirectly verify a desired minimum age of the
the output being spent; until that relative age has been reached any
script execution pathway including the CHECKSEQUENCEVERIFY will fail
to validate, causing the transaction not to be selected for inclusion
in a block.
==Motivation==
BIP 68 repurposes the transaction nSequence field meaning by giving
sequence numbers new consensus-enforced semantics as a relative
lock-time. However, there is no way to build Bitcoin scripts to make
decisions based on this field.
By making the nSequence field accessible to script, it becomes
possible to construct code pathways that only become accessible some
minimum time after proof-of-publication. This enables a wide variety
of applications in phased protocols such as escrow, payment channels,
or bidirectional pegs.
==Specification==
Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.
case OP_NOP3: { if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) { // not enabled; treat as a NOP3 if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) { return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS); } break; } if (stack.size() < 1) return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); // Note that unlike CHECKLOCKTIMEVERIFY we do not need to // accept 5-byte bignums since any value greater than or // equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected // anyway. This limitation just happens to coincide with // CScriptNum's default 4-byte limit with an explicit sign // bit. // // This means there is a maximum relative lock time of 52 // years, even though the nSequence field in transactions // themselves is uint32_t and could allow a relative lock // time of up to 120 years. const CScriptNum nInvSequence(stacktop(-1), fRequireMinimal); // In the rare event that the argument may be < 0 due to // some arithmetic being done first, you can always use // 0 MAX CHECKSEQUENCEVERIFY. if (nInvSequence < 0) return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME); // Actually compare the specified inverse sequence number // with the input. if (!CheckSequence(nInvSequence)) return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME); break; } bool CheckSequence(const CScriptNum& nInvSequence) const { int64_t txToInvSequence; // Fail under all circumstances if the transaction's version // number is not set high enough to enable enforced sequence // number rules. if (txTo->nVersion < 2) return false; // Sequence number must be inverted to convert it into a // relative lock-time. txToInvSequence = (int64_t)~txTo->vin[nIn].nSequence; // Sequence numbers under SEQUENCE_THRESHOLD are not consensus // constrained. if (txToInvSequence >= SEQUENCE_THRESHOLD) return false; // There are two types of relative lock-time: lock-by- // blockheight and lock-by-blocktime, distinguished by // whether txToInvSequence < LOCKTIME_THRESHOLD. // // We want to compare apples to apples, so fail the script // unless the type of lock-time being tested is the same as // the lock-time in the transaction input. if (!( (txToInvSequence < LOCKTIME_THRESHOLD && nInvSequence < 
LOCKTIME_THRESHOLD) ||
 (txToInvSequence >= LOCKTIME_THRESHOLD && nInvSequence >= 
LOCKTIME_THRESHOLD)
 )) return false; // Now that we know we're comparing apples-to-apples, the // comparison is a simple numeric one. if (nInvSequence > txInvToSequence) return false; return true; } 
https://github.com/maaku/bitcoin/commit/33be476a60fcc2afbe6be0ca7b93a84209173eb2
==Example: Escrow with Timeout==
An escrow that times out automatically 30 days after being funded can be
established in the following way. Alice, Bob and Escrow create a 2-of-3
address with the following redeemscript.
IF 2    3 
CHECKMULTISIGVERIFY
ELSE CHECKSEQUENCEVERIFY DROP  CHECKSIGVERIFY ENDIF 
At any time funds can be spent using signatures from any two of Alice,
Bob or the Escrow.
After 30 days Alice can sign alone.
The clock does not start ticking until the payment to the escrow address
confirms.
==Reference Implementation==
A reference implementation is provided in the following git repository:
https://github.com/maaku/bitcoin/tree/checksequenceverify
==Deployment==
We reuse the double-threshold switchover mechanism from BIPs 34 and
66, with the same thresholds, but for nVersion = 4. The new rules are
in effect for every block (at height H) with nVersion = 4 and at least
750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
have nVersion = 4. Furthermore, when 950 out of the 1000 blocks
preceding a block do have nVersion = 4, nVersion = 3 blocks become
invalid, and all further blocks enforce the new rules.
It is recommended that this soft-fork deployment trigger include other
related proposals for improving Bitcoin's lock-time capabilities, including:
[https://github.com/bitcoin/bips/blob/mastebip-0065.mediawiki BIP 65]:
OP_CHECKLOCKTIMEVERIFY,
[https://github.com/bitcoin/bips/blob/mastebip-0068.mediawiki BIP 68]:
Consensus-enforced transaction replacement signalled via sequence numbers,
and [https://github.com/bitcoin/bips/blob/mastebip-00XX.mediawiki BIP XX]:
Median-Past-Time-Lock.
==Credits==
Mark Friedenbach invented the application of sequence numbers to
achieve relative lock-time, and wrote the reference implementation of
CHECKSEQUENCEVERIFY.
The reference implementation and this BIP was based heavily on work
done by Peter Todd for the closely related BIP 65.
BtcDrak authored this BIP document.
==References==
BIP 68: Consensus-enforced transaction replacement signalled via
sequence numbers
https://github.com/bitcoin/bips/blob/mastebip-0068.mediawiki
BIP 65: OP_CHECKLOCKTIMEVERIFY
https://github.com/bitcoin/bips/blob/mastebip-0065.mediawiki
BIP XX: Median past block time for time-lock constraints
https://github.com/bitcoin/bips/blob/mastebip-00XX.mediawiki
HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and
revocation hashes
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html
==Copyright==
This document is placed in the public domain.
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010198.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [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 here we are today at $15000.
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.

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) 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 UASF [link] [comments]

Is bitcoin eyeing a price breakout? THIS IS HUUUGE!!!! BITCOIN NEWS CONFIRMING $30,000 BULL RUN NOW SAYS Confirmed! PayPal Just Said YES to Cryptocurrency in 2020!  Bitcoin and Cryptocurrency News WOW!!! MOST BULLISH BITCOIN NEWS OF 2020!?! REAL OR FAKE??? Bitcoin News - YouTube

As such, any protocol relying on a transaction replacement policy can be defeated by miners choosing not to follow that policy, which they may even be incentivised to do so (if older transactions provide higher fee per byte, for example). Transaction replacement is presently disabled in Bitcoin Core. 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 News Bitcoin News. Jennifer Marr. Bitcoin Development Discussion Summary 10/10/15. allegro101. 10/10/2015. Bitcoin News. 11353. 2. SHARES. Reddit Facebook Twitter Google. 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 A hacker news comment 'This isn't productive' Now you have me laughing. There is a lot in the bitcoin protocol that is possible that the vast majority of people have never heard of, some of which this article touches on. maaku on Dec 6, 2013. If Alice is able to maintain a fork at equal length to the main chain, that's a 51% attack. > > 1. If consensus parameters cannot be voted on then Bitcoin is a failure > Eagerly awaiting a substantive response to this by maaku. I am very much not maaku, but first it's obvious that Proof-of-Work has not been used to decide consensus protocol parameters (it's used for transaction ordering and establishing the consensus history).

[index] [22142] [5176] [17403] [2264] [14475] [5864] [5992] [4903] [2211] [11274]

Is bitcoin eyeing a price breakout?

🌌 TA Tips and Strategies condensed into a 2.5 hour course 🌌 GET $45 OFF T4 TODAY! USE CODE "MAYDAY" AT CHECKOUT https://t4tylers.teachable.com/purchase?produ... Read on Cointelegraph the top latest news and predictoins of cryptocurrency Bitcoin (BTC) and price analysis from around the world Bitcoin will crash 75% soon in 2020 before the 2021 BTC bull run can begin! price targets, TA & NYSE - Duration: ... (Investors Must See) Crypto News 2020 - Duration: 15:25. The BTC news & analysis can be inspiration for your own Bitcoin trading or investing, but is NOT financial advice. On this channel, The Moon, I make 1 video every single day about crypto news ... BITCOIN TODAY: Bitcoin is getting an ETP by a German company. In this video, I'll go through the Bitcoin news today & I'll make a Bitcoin price analysis. The BTC news & analysis can be inspiration ...

Flag Counter