Matt Corallo - cryptoanarchy.wiki

This is hilarious: Matt Corallo's support level of SegWit2x is "LOL"!

https://en.bitcoin.it/wiki/Segwit_support
There are seven levels of support: No, Deficient, Evaluating, Wanting, Weak, Acceptable, and Prefer.
Matt Corallo's support level of SegWit2x is "LOL"!
LOL!
submitted by exab to Bitcoin [link] [comments]

Subreddit Stats: btc posts from 2019-05-28 to 2019-06-07 10:40 PDT

Period: 10.34 days
Submissions Comments
Total 850 14116
Rate (per day) 82.22 1245.55
Unique Redditors 440 1828
Combined Score 26564 50495

Top Submitters' Top Submissions

  1. 3690 points, 33 submissions: MemoryDealers
    1. Brains..... (420 points, 94 comments)
    2. The first trade has already happened on Local.bitcoin.com! (193 points, 67 comments)
    3. China is already leading the way with the most trades done on local.bitcoin.com, followed by India. We really are helping free the world! (192 points, 58 comments)
    4. More than 100 BCH has been raised in just a few days to help support BCH protocol development! (180 points, 63 comments)
    5. The Bitcoin Cash Protocol Development Fund has already raised more than 10% of its goal from 467 separate transactions!!! (180 points, 58 comments)
    6. Local.bitcoin.com (159 points, 80 comments)
    7. The BCH miners are good guy heroes! (152 points, 161 comments)
    8. The Bitcoin.com YouTube channel just pased 25K subscribers (147 points, 19 comments)
    9. Ways to trigger a BTC maximalist: Remind them that because they didn't increase the block size, fees will eventually climb to dumb levels again. This will put brakes on it's bull trend, and funnel cash into alts instead. (141 points, 107 comments)
    10. Why more and more people are switching from BTC to BCH (137 points, 193 comments)
  2. 1561 points, 20 submissions: money78
    1. "Not a huge @rogerkver fan and never really used $BCH. But he wiped up the floor with @ToneVays in Malta, and even if you happen to despise BCH, it’s foolish and shortsighted not to take these criticisms seriously. $BTC is very expensive and very slow." (261 points, 131 comments)
    2. Jonathan Toomim: "At 32 MB, we can handle something like 30% of Venezuela's population using BCH 2x per day. Even if that's all BCH ever achieved, I'd call that a resounding success; that's 9 million people raised out of poverty. Not a bad accomplishment for a hundred thousand internet geeks." (253 points, 180 comments)
    3. CEO of CoinEx: "CoinEx already add SLP token solution support. The first SLP token will list on CoinEx Soon. Also welcome apply to list SLP tokens on CoinEx." (138 points, 18 comments)
    4. "While Ethereum smart contracts have a lot more functionality than those in Bitcoin Cash, with the upcoming CashScript we've tried to replicate a big part of the workflow, hopefully making it easier for developers to engage with both of these communities. Check it out 🚀" (120 points, 35 comments)
    5. Bitcoin ABC 0.19.7 is now available! This release includes RPC and wallet improvements, and a new transaction index database. See the release notes for details. (104 points, 5 comments)
    6. Vin Armani: "Huge shout out to the @BitcoinCom wallet team! I just heard from a very authoritative source that multi-output BIP 70 support has been successfully tested and will be in a near-term future release. Now, the most popular BCH wallet will support Non-Custodial Financial Services!" (88 points, 23 comments)
    7. BSV folks: Anything legal is good...We want our coin to be legal! (79 points, 66 comments)
    8. BCH fees vs BTC fees (78 points, 85 comments)
    9. "This @CashShuffle on BCH looks awesome. The larger blocksize on BCH allows for cheap on-chain transactions. @CashShuffle leverages this in a very creative way to gain privacy. Ignoring the tribalism, it's fascinating to watch BCH vs. BTC compete in the marketplace." (77 points, 3 comments)
    10. Bitcoin Cash the best that bitcoin can be...🔥💪 (60 points, 9 comments)
  3. 1413 points, 18 submissions: Egon_1
    1. "The claim “Bitcoin was purpose-built to first be a Store of Value” is false. In this article I've posting every single instance I could find across everything Satoshi ever wrote related to store of value or payments. It wasn't even close. Payments win." (299 points, 82 comments)
    2. The Art of Rewriting History ... File this under Deception! (184 points, 69 comments)
    3. Today's Next Block Fee: BTC ($3.55) and BCH ($0.00). Enjoy! (120 points, 101 comments)
    4. Andreas Brekken: "The maxi thought leaders have a ⚡in their username but can't describe a bidirectional payment channel. Ask questions? They attack you until you submit or leave. Leave? You're a scammer....." (115 points, 11 comments)
    5. Tone Vays: "So I will admit, I did terrible in the Malta Debate vs @rogerkver [...]" (107 points, 95 comments)
    6. This Week in Bitcoin Cash (96 points, 10 comments)
    7. “There was no way to win that debate. Roger came armed with too much logic and facts.” (78 points, 1 comment)
    8. BTC supporter enters a coffee shop: "I like to pay $3 premium security fee for my $4 coffee ☕️" (64 points, 100 comments)
    9. Matt Corallo: "... the worst parts of Bitcoin culture reliably come from folks like @Excellion and a few of the folks he has hired at @Blockstream ..." (63 points, 43 comments)
    10. Angela Walch: "Is there a resource that keeps an up-to-date list of those who have commit access to the Bitcoin Core Github repo & who pays them for their work on Bitcoin? In the past, getting this info has required digging. Is that still the case? " (57 points, 5 comments)
  4. 852 points, 11 submissions: jessquit
    1. PSA: BTC not working so great? Bitcoin upgraded in 2017. The upgraded Bitcoin is called BCH. There's still time to upgrade! (185 points, 193 comments)
    2. Nobody uses Bitcoin Cash (178 points, 89 comments)
    3. Yes, Bitcoin was always supposed to be gold 2.0: digital gold that you could use like cash, so you could spend it anywhere without needing banks and gold notes to make it useful. So why is Core trying to turn it back into gold 1.0? (112 points, 85 comments)
    4. This interesting conversation between Jonathan Toomim and @_drgo where jtoomim explains how large blocks actually aren't a centralization driver (89 points, 36 comments)
    5. This Twitter conversation between Jonathan Toomim and Adam Back is worth a read (75 points, 15 comments)
    6. In October 2010 Satoshi proposed a hard fork block size upgrade. This proposed upgrade was a fundamental factor in many people's decision to invest, myself included. BCH implemented this upgrade. BTC did not. (74 points, 41 comments)
    7. what do the following have in common: Australia, Canada, USA, Hong Kong, Jamaica, Liberia, Namibia, New Zealand, Singapore, Taiwan, Caribbean Netherlands, East Timor, Ecuador, El Salvador, the Federated States of Micronesia, the Marshall Islands, Palau, Zimbabwe (47 points, 20 comments)
    8. Core myth dispelled: how Bitcoin offers sovereignty (45 points, 65 comments)
    9. Satoshi's Speedbump: how Bitcoin's goldlike scarcity helps address scaling worries (25 points, 9 comments)
    10. Greater Fool Theory (14 points, 13 comments)
  5. 795 points, 7 submissions: BitcoinXio
    1. Erik Voorhees on Twitter: “I wonder if you realize that if Bitcoin didn’t work well as a payment system in the early days it likely would not have taken off. Many (most?) people found the concept of instant borderless payments captivating and inspiring. “Just hold this stuff” not sufficient.” (297 points, 68 comments)
    2. On Twitter: “PSA: The Lightning Network is being heavily data mined right now. Opening channels allows anyone to cluster your wallet and associate your keys with your IP address.” (226 points, 102 comments)
    3. Shocking (not): Blockstream has had a hard time getting business due to their very bad reputation (73 points, 25 comments)
    4. While @PeterMcCormack experiments with his #LightningNetwork bank, waiting over 20 seconds to make a payment, real P2P #Bitcoin payments have already arrived on #BitcoinCash. (66 points, 94 comments)
    5. This is what we’re up against. Mindless sheep being brain washed and pumping Bitcoin (BTC) as gold to try to make a buck. (56 points, 29 comments)
    6. Tuur Demeester: “At full maturity, using the Bitcoin blockchain will be as rare and specialized as chartering an oil tanker.” (54 points, 61 comments)
    7. ‪Bitcoin Cash 101: What Happens When We Decentralize Money? ‬ (23 points, 2 comments)
  6. 720 points, 2 submissions: InMyDayTVwasBooks
    1. A Reminder Why You Shouldn’t Use Google. (619 points, 214 comments)
    2. 15 Years Ago VS. Today: How Tech Scales (101 points, 53 comments)
  7. 485 points, 15 submissions: JonyRotten
    1. Cashscript Is Coming, Bringing Ethereum-Like Smart Contracts to Bitcoin Cash (96 points, 6 comments)
    2. Localbitcoins Removes In-Person Cash Trades Forcing Traders to Look Elsewhere (86 points, 26 comments)
    3. Bitcoin.com's Local Bitcoin Cash Marketplace Is Now Open for Trading (48 points, 22 comments)
    4. Report Insists 'Bitcoin Was Not Purpose-Built to First Be a Store of Value' (48 points, 8 comments)
    5. BCH Businesses Launch Development Fund for Bitcoin Cash (36 points, 1 comment)
    6. Another Aspiring Satoshi Copyrights the Bitcoin Whitepaper (31 points, 0 comments)
    7. Bitcoin Cash and SLP-Fueled Badger Wallet Launches for iOS (27 points, 0 comments)
    8. Bitcoin Mining With Solar: Less Risky and More Profitable Than Selling to the Grid (26 points, 0 comments)
    9. Former Mt Gox CEO Mark Karpeles Announces New Blockchain Startup (25 points, 25 comments)
    10. Mixing Service Bitcoin Blender Quits After Bestmixer Takedown (23 points, 7 comments)
  8. 426 points, 2 submissions: btcCore_isnt_Bitcoin
    1. Ponder the power of propaganda, Samson Mow, Adam Back and Greg Maxwell all know how import control of bitcoin is. (394 points, 98 comments)
    2. How many Bitcoin Core supporters does it take to change a light bulb? (32 points, 35 comments)
  9. 369 points, 3 submissions: where-is-satoshi
    1. Currently you must buy 11,450 coffees on a single Lightning channel to match the payment efficiency of Bitcoin BCH - you will also need to open an LN channel with at least $47,866 (230 points, 173 comments)
    2. North Queensland's Beauty Spot finds Bitcoin BCH a thing of beauty (74 points, 6 comments)
    3. Can't start the day without a BCHinno (65 points, 9 comments)
  10. 334 points, 5 submissions: AD1AD
    1. You Can Now Send Bitcoin Cash to Mobile Phones in Electron Cash Using Cointext! (132 points, 32 comments)
    2. Merchants are Dropping Multi-Coin PoS for One Cryptocurrency: Bitcoin Cash (73 points, 21 comments)
    3. A Stellar Animated Video from CoinSpice Explaining how CashShuffle Works Under the Hood! (67 points, 10 comments)
    4. If you haven't seen the "Shit Bitcoin Cash Fanatics Say" videos from Scott Rose (The Inspirational Nerd), YOU NEED TO DO IT NOWWW (50 points, 7 comments)
    5. New Video from Bitcoin Out Loud: "Can You Store Data on the Bitcoin Blockchain?" (Spoiler: Not really.) (12 points, 10 comments)
  11. 332 points, 6 submissions: eyeofpython
    1. I believe the BCH denomination is the best (in contrast to bits, cash and sats), if used with eight digits & spaces: 0.001 234 00 BCH. This way both the BCH and the satoshi amount is immediately clear. Once the value of a satoshi gets close to 1¢, the dot can simply be dropped. (112 points, 41 comments)
    2. Only after writing more BCH Script I realized how insanely usefull all the new opcodes are — CDS and those activated/added back in May '18. Kudos to the developers! (104 points, 22 comments)
    3. CashProof is aready so awesome it can formally prove all optimizations Spedn uses, except one. Great news for BCH smart contracts! (51 points, 6 comments)
    4. Proposal for a new opcode: OP_REVERSE (43 points, 55 comments)
    5. My response on your guy's critisism of OP_REVERSE and the question of why the SLP protocol (and others) don't simply switch to little endian (20 points, 25 comments)
    6. random post about quantum physics (both relevant and irrelevant for Bitcoin at the same time) (2 points, 11 comments)
  12. 322 points, 6 submissions: unitedstatian
    1. BCH is victim to one of the biggest manipulation campaigns in social media: Any mention of BCH triggered users instantly to spam "BCASH".. until BSV which is a BCH fork and almost identical to it pre-November fork popped out of nowhere and suddenly social media is spammed with pro-BSV posts. (131 points, 138 comments)
    2. LocalBitcoins just banned cash. It really only goes to show everything in the BTC ecosystem is compromised. (122 points, 42 comments)
    3. The new narrative of the shills who moved to promoting bsv: Bitcoin was meant to be government-friendly (33 points, 138 comments)
    4. Hearn may have been the only sober guy around (21 points, 29 comments)
    5. PSA: The economical model of the Lightning Network is unsound. The LN will support different coins which will be interconnected and since the LN tokens will be transacted instead of the base coins backing them up their value will be eroded over time. (14 points, 8 comments)
    6. DARPA-Funded Study Looks at How Crypto Chats Spread on Reddit (1 point, 0 comments)
  13. 313 points, 8 submissions: CreativeName44
    1. Venezuela Hidden Bitcoin Cash paper wallet claimed with 0.17468 BCH! Congrats to the one who found it! (80 points, 0 comments)
    2. Alright BCH Redditors, Let's make some HUGE noise!! Announcing The NBA finals Toronto Raptors Hidden BCH Wallet!! (60 points, 9 comments)
    3. FindBitcoinCash gaining traction around the world - Calling out to Bitcoin Cashers to join the fun!! (41 points, 0 comments)
    4. The Toronto Raptors Bitcoin Cash Wallet has been hidden: Address qz72j9e906g7pes769yp8d4ltdmh4ajl9vf76pj0v9 (PLS RT - Some local media tagged on it) (39 points, 0 comments)
    5. This is the next BitcoinCash wallet that is going to be hidden, hopefully REALLY soon! (36 points, 13 comments)
    6. Bitcoin Cash Meetups From Around the World added to FindBitcoinCash (25 points, 0 comments)
    7. FindBitcoinCash Wallets in other languages English/Spanish/Lithuanian/Swedish/Korean (20 points, 18 comments)
    8. Thank you for a great article!! (12 points, 0 comments)
  14. 312 points, 1 submission: scriberrr
    1. WHY? (312 points, 49 comments)
  15. 311 points, 4 submissions: Anenome5
    1. Libertarian sub GoldandBlack is hosting a free, live online workshop about how to setup and use Electron Cash on Sat 1st June via discord, including how to use Cashshuffle, with a Q&A session to follow. All are invited! (119 points, 40 comments)
    2. For anyone who still hasn't seen this, here is Peter Rizun and Andrew Stone presenting their research on how to do 1 gigabyte blocks, all the way back in 2017 at the Scaling Bitcoin Conference. The BTC camp has known we can scale bitcoin on-chain for years, they just don't want to hear it. (92 points, 113 comments)
    3. @ the trolls saying "No one uses Bitcoin Cash", let's look at the last 60 blocks... (72 points, 84 comments)
    4. Research Reveals Feasibility of 1TB Blocks, 7M Transactions per Second (28 points, 22 comments)
  16. 293 points, 2 submissions: BeijingBitcoins
    1. /Bitcoin mods are censoring posts that explain why BitPay has to charge an additional fee when accepting BTC payments (216 points, 110 comments)
    2. Meetups and adoption don't just happen organically, but are the result of the hard work of passionate community members. There are many others out there but these girls deserve some recognition! (77 points, 9 comments)
  17. 282 points, 1 submission: EddieFrmDaBlockchain
    1. LEAKED: Attendee List for Buffet Charity Lunch (282 points, 98 comments)
  18. 273 points, 4 submissions: HostFat
    1. Breakdown of all Satoshi’s Writings Proves Bitcoin not Built Primarily as Store of Value (159 points, 64 comments)
    2. Just to remember - When you are afraid that the market can go against you, use the state force. (48 points, 5 comments)
    3. CypherPoker.JS v0.5.0 - P2P Poker - Bitcoin Cash support added! (35 points, 3 comments)
    4. Feature request as standard for all bch mobile wallets (31 points, 12 comments)
  19. 262 points, 3 submissions: CaptainPatent
    1. Lightning Network capacity takes a sudden dive well below 1k BTC after passing that mark back in March. (97 points, 149 comments)
    2. Yeah, how is it fair that Bitpay is willing to eat a $0.0007 transaction fee and not a $2+ transaction fee?! (89 points, 59 comments)
    3. BTC Fees amplified today by last night's difficulty adjustment. Current (peak of day) next-block fees are testing new highs. (76 points, 59 comments)
  20. 262 points, 1 submission: Badrush
    1. Now I understand why Bitcoin Developers hate on-chain solutions like increasing block sizes. (262 points, 100 comments)

Top Commenters

  1. jessquit (2337 points, 242 comments)
  2. LovelyDay (1191 points, 160 comments)
  3. Ant-n (1062 points, 262 comments)
  4. MemoryDealers (977 points, 62 comments)
  5. jtoomim (880 points, 108 comments)
  6. 500239 (841 points, 142 comments)
  7. jonald_fyookball (682 points, 86 comments)
  8. ShadowOfHarbringer (672 points, 110 comments)
  9. money78 (660 points, 41 comments)
  10. playfulexistence (632 points, 76 comments)
  11. Bagatell_ (586 points, 72 comments)
  12. Big_Bubbler (552 points, 196 comments)
  13. homopit (551 points, 79 comments)
  14. Anenome5 (543 points, 130 comments)
  15. WippleDippleDoo (537 points, 111 comments)
  16. MobTwo (530 points, 52 comments)
  17. FalltheBanks3301 (483 points, 87 comments)
  18. btcfork (442 points, 115 comments)
  19. chainxor (428 points, 71 comments)
  20. eyeofpython (425 points, 78 comments)

Top Submissions

  1. A Reminder Why You Shouldn’t Use Google. by InMyDayTVwasBooks (619 points, 214 comments)
  2. Brains..... by MemoryDealers (420 points, 94 comments)
  3. Ponder the power of propaganda, Samson Mow, Adam Back and Greg Maxwell all know how import control of bitcoin is. by btcCore_isnt_Bitcoin (394 points, 98 comments)
  4. WHY? by scriberrr (312 points, 49 comments)
  5. "The claim “Bitcoin was purpose-built to first be a Store of Value” is false. In this article I've posting every single instance I could find across everything Satoshi ever wrote related to store of value or payments. It wasn't even close. Payments win." by Egon_1 (299 points, 82 comments)
  6. Erik Voorhees on Twitter: “I wonder if you realize that if Bitcoin didn’t work well as a payment system in the early days it likely would not have taken off. Many (most?) people found the concept of instant borderless payments captivating and inspiring. “Just hold this stuff” not sufficient.” by BitcoinXio (297 points, 68 comments)
  7. LEAKED: Attendee List for Buffet Charity Lunch by EddieFrmDaBlockchain (282 points, 98 comments)
  8. Now I understand why Bitcoin Developers hate on-chain solutions like increasing block sizes. by Badrush (262 points, 100 comments)
  9. "Not a huge @rogerkver fan and never really used $BCH. But he wiped up the floor with @ToneVays in Malta, and even if you happen to despise BCH, it’s foolish and shortsighted not to take these criticisms seriously. $BTC is very expensive and very slow." by money78 (261 points, 131 comments)
  10. Jonathan Toomim: "At 32 MB, we can handle something like 30% of Venezuela's population using BCH 2x per day. Even if that's all BCH ever achieved, I'd call that a resounding success; that's 9 million people raised out of poverty. Not a bad accomplishment for a hundred thousand internet geeks." by money78 (253 points, 180 comments)

Top Comments

  1. 109 points: mossmoon's comment in Now I understand why Bitcoin Developers hate on-chain solutions like increasing block sizes.
  2. 104 points: _degenerategambler's comment in Nobody uses Bitcoin Cash
  3. 96 points: FreelanceForCoins's comment in A Reminder Why You Shouldn’t Use Google.
  4. 94 points: ThomasZander's comment in "Not a huge @rogerkver fan and never really used $BCH. But he wiped up the floor with @ToneVays in Malta, and even if you happen to despise BCH, it’s foolish and shortsighted not to take these criticisms seriously. $BTC is very expensive and very slow."
  5. 91 points: cryptotrillionaire's comment in The Art of Rewriting History ... File this under Deception!
  6. 87 points: tjonak's comment in A Reminder Why You Shouldn’t Use Google.
  7. 86 points: money78's comment in Tone Vays: "So I will admit, I did terrible in the Malta Debate vs @rogerkver [...]"
  8. 83 points: discoltk's comment in "Not a huge @rogerkver fan and never really used $BCH. But he wiped up the floor with @ToneVays in Malta, and even if you happen to despise BCH, it’s foolish and shortsighted not to take these criticisms seriously. $BTC is very expensive and very slow."
  9. 79 points: jessquit's comment in Ways to trigger a Shitcoin influencer Part 1: Remind them that’s it’s very likely they got paid to shill fake Bitcoin to Noobs
  10. 78 points: PaladinInc's comment in The BCH miners are good guy heroes!
Generated with BBoe's Subreddit Stats
submitted by subreddit_stats to subreddit_stats [link] [comments]

What is up with all these Bitcoin devs who think that their job includes HARD-CODING CERTAIN VALUES THAT ARE SUPPOSED TO BE USER-CONFIGURABLE (eg: "seed servers")?

Recently, the developer of SegWit2x / BTC1, Jeff Garzik, caused some controversy by hard-coding the "seed servers" which Bitcoin uses to first start hunting for "peers".
Worse than that: apparently one of the "seeds" is a company he started, variously named Chainalysis / Skry / Bloq - which apparently specializes in de-anonymizing Bitcoin transactions and performing KYC/AML - and which also has apparently entered into agreements with Interpol.
Seriously, WTF???
This is what "Bitcoin devs" still consider to be part of their "job" - hard-coding parameters like this, which affect everyone else on the network - and which could easily be "exposed" to be made user-configurable - instead of being baked into the source code and requiring a friggin' recompile to change???
This recent event has refocused attention on the fact all these past years, most of these seed servers in "the" existing (legacy) client running on most of the network have _also been hard-coded - to domains under the control of "devs associated with Blockstream".
I don't like the list of seed servers in Bitcoin Core
Pieter Wuille - does not support BIP148 - works for Blockstream
Matt Corallo - does not support BIP148 - works for Blockstream
Luke Dashjr - supports BIP148 - works for Blockstream
Christian Decker - supports BIP148 - works for Blockstream
Jonas Schnelli - supports BIP148
Peter Todd - supports BIP148 - worked for Samson Mow who works for Blockstream
https://np.reddit.com/btc/comments/6nd50h/i_dont_like_the_list_of_seed_servers_in_bitcoin/
The corporate takeover of bitcoin illustrated in 1 commit
In The corporate takeover of bitcoin illustrated in 1 commit a user complains that btc1 changing the seed servers to servers run by some companies (see commit) equals a "corporate takeover of bitcoin". I never really took much care who runs these seed server, although they do posses a certain power over the network as correctly pointed out by P. Todd in the same thread:
...and the key thing with that is being able to control what nodes a node connects to can be a very powerful tool to attack new nodes, as it lets you prevent a node from learning about the valid chain with the most work.
[...]
4 out of 5 people running the bitcoin networks seed servers are directly associated with Blockstream!
I don't even believe that Blockstream is actually plotting an evil, forceful takeover of bitcoin using the seed servers. However it beautifully counteracts Adam's "decentralization is everything" arguments. What is most troublesome to me, is that this simple information is not allowed to appear on r\bitcoin at all.
https://np.reddit.com/btc/comments/6n8vqc/the_corporate_takeover_of_bitcoin_illustrated_in/
Seriously?
Bitcoin is almost 9 years old - and most people are still running clients which use hard-coded values (which require an inconvenient recompile to reconfigure) for the "seed servers"??
Maybe this is, in some sense, part of the reason why people like BlueMatt and Luke-Jr and Pieter Wiulle think they can lord it over us and tell everyone else what to do? ...because they have quietly (and unfairly / incompetently) hard-coded their own friggin' server domain names directly into everyone else's client code, as our "seed servers"?
Is the low level of "quality" we - as a community - have become accustomed to from our devs?
Do other clients (Bitcoin Classic, Bitcoin Unlimited and Bitcoin ABC) also gratuitously hard-code their "seed servers" like this?
Here's a post from a year ago regarding "seed servers" in Classic:
How come "classic" uses the same alert keys/DNS seeds as Core?
https://np.reddit.com/btc/comments/44atsp/how_come_classic_uses_the_same_alert_keysdns/
Meanwhile, here's the main question:
Why are any "serious" Bitcoin clients still "gratuitously" hard-coding any values like this?
Why has our "ecosystem" / "community" not naturally evolved to the point where we have some public "wiki" pages listing all the "good" (community-recognized, popular) seed servers - and every user configures their own client software by choosing who they want from this list?
(Maybe because we've been distracted by bullshit for these past few years, fighting with these very same devs because they've refused provide any support for users who want bigger blocks?)
What would users have to do if (God forbid) something were to happen to the servers of those 4-5 seed servers which are currently hard-coded into nearly everyone's clients?
In that situation (assuming some "new" seed servers quickly appeared) people would be have two options:
  • Edit their C++ source code and download/install a (trusted, verified) C++ compiler (if they don't already have one), and recompile the friggin' code; or
  • Wait until new binaries got posted online - and download them (and verify them).
Seriously?
This unnecessary "centralization point" (or major inconvenience / bottleneck) has been sitting in our code this entire time - while these supposedly knowledgeable devs keep beating us over their head with their mantra of "decentralization" - which they have actually been doing so little to maximize?
Psycho-Socio-Economic Side Bar
Serious (but delicate/senstive) question: How many of these "devs" have developed (possibly unconscious?) behaviors in life where they try to make users dependent on them?
"Vendor lock-in" is a thing - a very bad thing, which certain Bitcoin devs have exhibited a tendency to inflict on users - in many cases due to rather obvious (psychological, social, and/or economic) reasons.
We should gently (but firmly) reject these tendencies whenever any dev exhibits them.
Our community should expect and demand an accessible, user-friendly interface for all user-configurable parameters - to maximize decentralization and autonomy
  • In "command-line" versions of the client program, these kind of parameters should be:
    • in a separate config file - using some ultra-simple, standard format such as YAML or JSON
    • also configurable via options (eg, --seed-server) upon invocation on the command-line
  • In GUI versions version of the client program (using some popular cross-platform standard such as Qt, HTML, etc.) these kind of parameters should be exposed as user-configurable options.
Yes, these user-configurable values for things like "seed servers" (or "max blocksize") could come pre-configured to "sensible defaults - so that the software will work "out of the box" (immediately upon downloading and installing) - with no initial configuration required by the user.
Yes: Even the blocksize has always been user-configurable - but most users don't know this, because most devs have been hiding this fact from us.
Three recent posts by u/ForkiusMaximus explained how Adjustable-Blocksize-Cap (ABC) Bitcoin clients shatter this illusion:
Adjustable-blocksize-cap (ABC) clients give miners exactly zero additional power. BU, Classic, and other ABC clients are really just an argument in code form, shattering the illusion that devs are part of the governance structure.
https://np.reddit.com/btc/comments/614su9/adjustableblocksizecap_abc_clients_give_miners/
Adjustable blocksize cap (ABC) is dangerous? The blocksize cap has always been user-adjustable. Core just has a really shitty inferface for it.
https://np.reddit.com/btc/comments/617gf9/adjustable_blocksize_cap_abc_is_dangerous_the/
Clearing up Some Widespread Confusions about BU
https://np.reddit.com/btc/comments/602vsy/clearing_up_some_widespread_confusions_about_bu/
Note about Bitcoin ABC vs Bitcoin Unlimited:
There is a specific new Bitcoin client called Bitcoin ABC, which functions similar to Bitcoin Unlimited - with the important difference that Bitcoin ABC is _guaranteed to hard-fork to bigger blocks on August 1_.
(Please correct me if I'm wrong about this. Documentation for the behavior of these various hard-forks is currently still rather disorganized :-)
All serious devs should be expected to provide code which does not require a "recompile" to change these "initial, sensible" default parameters.
I mean - come on. Even back in the 80s people had "*.INI" files on DOS and Windows.
Nearly all users understand and know how to set user-configurable values - for decades.
How many people are familiar with using a program which has a "Preferences" screen? (Sometimes you may have to close and re-open the program in order for your new preferences to take effect.) This is really basic, basic functionality which nearly all software provides via a GUI (and or config file and/or command-line options).
And nearly all devs have been offering this kind of functionality - in either command-line parameters, config files, and/or graphic user interfaces (GUIs).
Except most Bitcoin devs.
The state of "software development" for Bitcoin clients seems really messed up in certain ways like this.
As users, we need to start demanding simple, standard features in our client software - such as accessible, user-friendly configurability of parameter values - without the massive inconvenience of a recompile.
What is a "Bitcoin client"?
After nearly 9 years in operation, our community should by now have a basic concept or definition of what a "Bitcoin client" is / does - probably something along the lines of:

A Bitcoin client is a device for reading (and optionally appending to) the immutable Bitcoin Blockchain.

Based on that general concept / definition, a program which does all of the above and also gratuitously "hard-codes" a bunch of domain names for "seed servers" is not quite the same thing as a "a Bitcoin client".
Such an "overspecialized" client actually provides merely a subset of the full functionality of a true "Bitcoin client", eg:
  • An "overspecialized" client only enables connecting to certain "seed servers" upon startup (in accordance with the "gratuitous opinion" of the dev who (mis)translated the community's conceptual specifications to C++ code)
  • An "overspecialized" client only enables mining blocks less that a certain size (in accordance with the "gratuitous opinion" of the dev who (mis)translated the community's conceptual specifications to C++ code)
One of the main problems with nearly all Bitcoin clients developed so far is that they are gratuitously opinionated: they "gratuitously" hard-code particular values (eg, "max blocksize", "seed servers") which are not part of the whitepaper, and not part of the generally accepted definition of a "Bitcoin client".
This failure on the part of devs to provide Bitcoin clients which behave in accordance with the community's specification of "Bitcoin clients" is seriously damaging Bitcoin - and needs to be fixed as soon as possible.
Right now is a good opportunity - with so many new Bitcoin clients popping up, as the community prepares to fork.
All devs working on various Bitcoin client software offerings need to wake up and realize that there is about to be a major battle to find out which Bitcoin client software offering performs "best" (in the user-interface sense - and ultimately in the economic sense) at:

reading (and optionally appending to) the immutable Bitcoin Blockchain

The Bitcoin client software offerings which can optimally (and most simply and securely :-) "satisfy" the above specification (and not merely some gratuitously overspecialized "subset" of it) will have the most success.
submitted by ydtm to btc [link] [comments]

Why Chaincode Labs being one of the biggest Core contributors is truly troubling.

First of all, who started Chaincode Labs?
From their own website:
Alex Morcos was one of the early pioneers of automated trading and co-founded Hudson River Trading in 2002, where he spent 10 years working to make markets more efficient and improve market structure. He discovered his passion for Bitcoin in 2012, and in 2014 he co-founded Chaincode with Suhas. He has enjoyed contributing to Bitcoin Core and learning about the exciting nascent field of cryptocurrency ever since.
Also
Suhas Daftuar co-founded Hudson River Trading LLC in 2002, where he spent over a decade developing HRT into a global trading firm and helping to shape the complex policy debates surrounding technology in financial markets. In 2014, Suhas co-founded Chaincode Labs with Alex to create a place for engineers and scientists to support the development of decentralized digital currencies and further our collective understanding of how such technologies can work.
What does Hudson River Trading do?
Hudson River Trading LLC (HRT) is a multi-asset class quantitative trading firm, and more specifically a high-frequency trading (HFT) firm, based in New York City and founded in 2002. According to the Wall Street Journal, it is responsible for about 5% of all stock trading in the United States.
What is HFT?
Specifically, it is the use of sophisticated technological tools and computer algorithms to rapidly trade securities. HFT uses proprietary trading strategies carried out by computers to move in and out of positions in seconds or fractions of a second.
Why is this a problem?
A substantial body of research argues that HFT and electronic trading pose new types of challenges to the financial system. Algorithmic and high-frequency traders were both found to have contributed to volatility in the Flash Crash of May 6, 2010, when high-frequency liquidity providers rapidly withdrew from the market. Several European countries have proposed curtailing or banning HFT due to concerns about volatility.
I encourage everyone to go to the Wiki page on HFT, and do their own research. There is a lot more on this subject than I have the time for. (Market manipulation, Spoofing, Quote stuffing, etc.) What you will find is that these firms are often investigated by regulators, and are often given small fines, but rarely is anyone thrown in jail for manipulating financial markets like this.
Also notice how it says European countries have proposed banning it, but not the US. This is because the regulators are likely in bed with the same companies that they are supposed to be regulating. This is evidenced by the revolving door of former government regulators being hired by the same companies they were regulating, and in some cases going back to work for the government after.
This may be why Matt Corallo went to the SEC. He also works for Chaincode! Again, from their own website:
Matt Corallo is a long-time Bitcoin developer who has been contributing to Bitcoin Core since 2011. Matt helped co-found Blockstream where he co-authored the Sidechains whitepaper and implemented the Elements Sidechain. Matt also built and maintains the Bitcoin FIBRE project, the latest generation of low-latency Bitcoin block relay.
As always, do your own due diligence. Look around for yourself. Who benefits? Follow the money, and you will find out.
submitted by 324JL to btc [link] [comments]

Estimation of Miner Hash Rates and Consensus on Blockchains

arXiv:1707.00082
Date: 2017-07-01
Author(s): A. Pinar Ozisik, George Bissias, Brian Levine

Link to Paper


Abstract
We make several contributions that quantify the real-time hash rate and therefore the consensus of a blockchain. We show that by using only the hash value of blocks, we can estimate and measure the hash rate of all miners or individual miners, with quanti able accuracy. We apply our techniques to the Ethereum and Bitcoin blockchains; our solution applies to any proof-of-work-based blockchain that relies on a numeric target for the validation of blocks. We also show that if miners regularly broadcast status reports of their partial proof-of- work, the hash rate estimates are signi cantly more accurate at a cost of slightly higher bandwidth. Whether using only the blockchain, or the additional information in status reports, merchants can use our techniques to quantify in real-time the threat of double-spend attacks.

References
[1] 2015. The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. https://lightning.network/lightning-network-paper.pdf. (July 2015).
[2] 2016. Gnosis. https://www.gnosis.pm. (November 2016).
[3] Asaph Azaria, Ariel Ekblaw, Thiago Vieira, and Andrew Lippman. 2016. "MedRec: Using Blockchain for Medical Data Access and Permission Management. In Proc. Intl. Conf. on Open and Big Data. 25–30.
[4] Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and Pieter Wuille. 2014. Enabling Blockchain Innovations with Pegged Sidechains. Technical report. (Oct 22 2014).
[5] Simon Barber, Xavier Boyen, Elaine Shi, and Ersin Uzun. 2012. Bitter to better—how to make bitcoin a better currency. In International Conference on Financial Cryptography and Data Security. Springer, 399–414.
[6] Bryan Bishop. 2015. bitcoin-dev mailling list: Weak block thoughts... https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe011158.html. (Sep 2015).
[7] bitcoin 2015. Confirmation. https://en.bitcoin.it/wiki/Confirmation. (February 2015).
[8] Joseph Bonneau. 2015. How long does it take for a Bitcoin transaction to be confirmed? https://coincenter.org/2015/11/what-does-it-meanfor-a-bitcoin-transaction-to-be-confirmed/. (November 2015).
[9] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J.A. Kroll, and E.W. Felten. 2015. SoK: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies. In IEEE S&P. 104–121. http://doi.org/10.1109/ SP.2015.14
[10] George Casella and Roger L. Berger. 2002. Statistical inference. Brooks Cole, Pacific Grove, CA. http://opac.inria.frecord=b1134456
[11] Kyle Croman et al. 2016. On Scaling Decentralized Blockchains . In Workshop on Bitcoin and Blockchain Research.
[12] Digix. 2017. https://www.dgx.io/. (Last retrieved June 2017).
[13] DigixDAO. 2017. https://www.dgx.io/dgd/. (Last retrieved June 2017).
[14] J. Douceur. 2002. The Sybil Attack. In Proc. Intl Wkshp on Peer-to-Peer Systems (IPTPS).
[15] Bradley Efron. 1982. The jackknife, the bootstrap and other resampling plans. Society for industrial and applied mathematics (SIAM).
[16] Ethash. 2017. https://github.com/ethereum/wiki/wiki/Ethash. (Last retrieved June 2017).
[17] ethereum. Ethereum Homestead Documentation. http://ethdocs.org/en/latest/. (????).
[18] Etheria. 2017. http://etheria.world. (Last retrieved June 2017).
[19] Ittay Eyal and Emin Gün Sirer. 2014. Majority is not enough: Bitcoin mining is vulnerable. Financial Cryptography (2014), 436–454. http://doi.org/10.1007/978-3-662-45472-5_28
[20] William Feller. 1968. An Introduction to Probability Theory and its Applications: Volume I. Vol. 3. John Wiley & Sons London-New YorkSydney-Toronto.
[21] Juan Garay, Aggelos Kiayias, and Nikos Leonardos. 2015. The bitcoin backbone protocol: Analysis and applications. In Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, 281–310.
[22] Arthur Gervais, Ghassan O. Karame, Karl Wust, Vasileios Glykantzis, Hubert Ritzdorf, and Srdjan Capkun. 2016. On the Security and Performance of Proof of Work Blockchains. https://eprint.iacr.org/2016/555. (2016).
[23] Hashcash. 2017. https://en.bitcoin.it/wiki/Hashcash. (Last retrieved June 2017).
[24] Ethan Heilman, Leen Alshenibr, Foteini Baldimtsi, Alessandra Scafuro, and Sharon Goldberg. 2017. TumbleBit: An untrusted Bitcoincompatible anonymous payment hub. In Proc. ISOC Network and Distributed System Security Symposium (NDSS).
[25] Svante Janson. 2014. Tail Bounds for Sums of Geometric and Exponential Variable. Technical Report. Uppsala University.
[26] Litecoin. 2017. https://litecoin.org. (Last retrieved June 2017).
[27] Satoshi Nakamoto. 2009. Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf. (May 2009).
[28] A. Pinar Ozisik, Gavin Andresen, George Bissias, Amir Houmansadr, and Brian Neil Levine. 2016. A Secure, Efficient, and Transparent Network Architecture for Bitcoin. Technical Report UM-CS-2016-006. University of Massachusetts, Amherst, MA. https://web.cs.umass.edu/publication/details.php?id=2417
[29] Meni Rosenfeld. 2012. Analysis of hashrate-based double-spending. https://bitcoil.co.il/Doublespend.pdf. (December 2012).
[30] Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar. 2015. Optimal Selfish Mining Strategies in Bitcoin. https://arxiv.org/pdf/1507.06183.pdf. (July 2015).
[31] Eli Ben Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. 2014. Zerocash: Decentralized Anonymous Payments from Bitcoin. In IEEE S&P. 459–474. http://dx.doi.org/10.1109/SP.2014.36
[32] Yonatan Sompolinsky and Aviv Zohar. 2015. Secure high-rate transaction processing in Bitcoin. Financial Cryptography and Data Security (2015). http://doi.org/10.1007/978-3-662-47854-7_32
[33] Yonatan Sompolinsky and Aviv Zohar. 2016. Bitcoin’s Security Model Revisited. https://arxiv.org/abs/1605.09193. (May 2016).
[34] F. Tschorsch and B. Scheuermann. 2016. Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies. IEEE Communications Surveys Tutorials PP, 99 (2016), 1–1. https://doi.org/10.1109/COMST. 2016.2535718
[35] Marko Vukolić. 2015. The quest for scalable blockchain fabric: Proof-ofwork vs. BFT replication. In International Workshop on Open Problems in Network Security. Springer, 112–125.
submitted by dj-gutz to myrXiv [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-11-12)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Note that I crosspost this to Voat, bitcoin.com and the bitcoin-discuss mailing list every week. I can't control what's being talking about in the meeting, if certain things come up I might not be able to post here because of "guidelines".
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
transaction priority for 0.12 Opt-in replace-by-fee Versionbits Chain limits
transaction priority for 0.12
Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which currently makes some transactions free. This currently has a large amount of code, which makes it harder to maintain, and is not that optimal since you can't expect miners to include 0-fee transactions.
Most people seem fine with removing priority in the mempool, but people should be notified ahead of time this is coming. sdaftuar proposed a staggered approach, setting the default value for priority to 0, and remove it entirely in the next release. petertodd notes there will be a natural staggered process since not everyone will upgrade to 0.12 instantly and some implementations might not remove priority at all. Most wallet-software outside of bitcoin-core don't implement priority calculations. As fee estimation becomes more important and many wallet providers use the bitcoin-core fee estimation, improvements on that are welcome. Luke-Jr doesn't agree with removing priority, particularly with changing the mining code to use the priority a transaction has when it enters the mempool. Sipa has the idea to add a small fraction of bitcoin days destroyed divided by the average UTXO age to the fee, so that non-spam-attack transactions are viewed as if they have a larger fee.
While most agree with the proposal to remove the current priority, there's still much debate on whether it needs to be replaced for 0.13, and if so, how.
Review "Improve usage of fee estimation code" BlueMatt will mail the developer mailinglist announcing the changes. ( https://www.mail-archive.com/[email protected]/msg02790.html )
Opt-in replace-by-fee
Currently when a node sees a transaction that spends the same output it ignores it. With replace-by-fee it replaces the current transaction in the mempool if it has a higher fee. This allows for things like spending "stuck" transactions, adding more recipients to a transaction in order to prevent chaining, etc.
Since there are people that accept 0-confirmation transactions and this would make it extremely easy to double spend them, this is made opt-in. The sender can choose to opt-in to replace-by-fee by changing an input in the nSequence field.
Peter Todd wrote some tools to use replace-by-fee. link It would be nice to have opt-in per output instead of the whole transaction, however that would be very hard to implement and would have some privacy concerns. Luke-Jr would like to see an option to toggle between first-seen-safe/full RBF and neveopt-in/always. Since there are possibly some objections with the "always" toggle it should be a separate pull-request.
review and merge nSequence-based Full-RBF opt-in Peter Todd will write a mail to the list to explain how it works and how people can not accept opt-in transactions.
Versionbits
BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than Y the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.
There are 2 different implementations. One from Codeshark and one from Rusty jtimon thinks both implementations are more complicated than they need to be. There needs to be a minor revision namely a starting time for proposals. In general we'd like to get this in soon, but existing softforks need to complete first.
CodeShark adds a starting time to versionbits.
Chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent malleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
Wumpus doesn't feel comfortable with merging it because there's some controversy from companies who exceed the limits (or could be/want to). jgarzik does feel comfortable with it, and many think it should be merged as it's easy to revert if needed. There's little choice as it's not safe from attacks without limits. We should communicate the replace-by-fee sendmany alternative to long chains (adding new recipients on existing non-confirmed transactions), although it won't show up in users wallet yet and block-explorers probably aren't ready to display it correctly. Emphasis on the fact it's a change in default values, not a consensus change, however default values have a lot of power. The final limits are 25 transactions and 101kb total size for both ancestor and descendant packages.
jgarzik will merge the pull-request. Morcos will mail the list once it's merged.
Participants
BlueMatt Matt Corallo petertodd Peter Todd morcos Alex Morcos jgarzik Jeff Garzik gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan Luke-Jr Luke Dashjr jtimon Jorge Timón btcdrak btcdrak phantomcircuit Patrick Strateman sipa Pieter Wuille CodeShark Eric Lombrozo sdaftuar Suhas Daftuar jg_taxi jg_taxi gavinandresen Gavin Andresen cfields Cory Fields bsm1175321 Bob McElrath 
Comic relief
19:53 sipa new topic? 19:53 wumpus any other topics? 19:53 petertodd  19:53 jgarzik did we cover jonas while I was in the taxi? 19:54 sdaftuar ? 19:54 jtimon ? 19:54 CodeShark not sure I want to know 19:54 jgarzik proposal for new GUI maintainer 19:54 CodeShark sounds kinky, though 19:54 petertodd CodeShark: GUI's are pretty kinky 19:56 BlueMatt ok, end meeting? 19:56 btcdrak if we can remember the command this week :-) 19:56 wumpus #meetingend 19:56 gmaxwell #destroymeeting 19:56 wumpus #endmeeting 19:56 Luke-Jr #endmeeting 19:56 lightningbot Meeting ended Thu Nov 12 19:56:42 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 19:56 BlueMatt #magicmeetbotincantation 19:57 petertodd #DoWhatIMean 
submitted by G1lius to Bitcoin [link] [comments]

Subreddit Stats: Bitcoin posts from 2018-10-09 to 2018-10-16 19:41 PDT

Period: 7.10 days
Submissions Comments
Total 765 10226
Rate (per day) 107.80 1494.28
Unique Redditors 596 3440
Combined Score 31658 33963

Top Submitters' Top Submissions

  1. 4526 points, 1 submission: Alexsayzz
    1. Anti-crypto propaganda... promoted by American Express (4526 points, 513 comments)
  2. 2391 points, 2 submissions: MoonMan_666
    1. Someone just paid $0.10 to move $194M (29,999 BTC). Think about how powerful that is for a second. (2369 points, 380 comments)
    2. Dev sends Bitcoin without using the web or the power grid (22 points, 4 comments)
  3. 2077 points, 1 submission: _Logicrypto
    1. When your boss thanks you for staying late at work but you were just watching the Bitcoin price and lost track of time (2077 points, 69 comments)
  4. 1496 points, 1 submission: bitbug42
    1. ⚡Lightning Network at the Senate - Counterargument to Roubini's speech that Bitcoin can never scale to serve the planet (1496 points, 186 comments)
  5. 1417 points, 1 submission: opencoins
    1. Why sell and pay capital gains, why not wait for mass adoption? That's my motto. (1417 points, 244 comments)
  6. 1174 points, 1 submission: awertheim
    1. Took a while but finally part of the picture club (had to wait on the web browser update!) (1174 points, 127 comments)
  7. 853 points, 1 submission: Hodl_it
    1. Feeling good? (853 points, 215 comments)
  8. 833 points, 1 submission: cointastical
    1. Bitcoin ATM operator gets the $62,500 that police confiscated back (833 points, 110 comments)
  9. 802 points, 2 submissions: JandyJammer
    1. Congratulations US senators for understanding crypto better than this guy (748 points, 125 comments)
    2. How is Bitmex the biggest exchange... total joke. I hope their competitors crush them. (54 points, 49 comments)
  10. 704 points, 1 submission: lesbiansareoverrated
    1. ...in case you missed the laura shill burn today (704 points, 100 comments)
  11. 512 points, 5 submissions: castorfromtheva
    1. Mycelium wallet will FINALLY get segwit! "This month" as stated by Mycelium developers on 9 October 2018. Glad to hear! I am excited. (312 points, 136 comments)
    2. Just saw it on their website: Ledger Nano S 20% off, directly from manufacturer! For six days, starting today. Just in case you consider getting a hardware wallet. (146 points, 84 comments)
    3. Newsflash: Bitfinex Unveils ‘Distributed Banking Solution,’ Resumes Fiat Deposits (44 points, 8 comments)
    4. Binance Uganda Launch 80% Ready As Users Can Now Sign Up: Deposits & Trading Coming Soon (8 points, 1 comment)
    5. Article: "Cryptos at a turning point", trustnodes.com (2 points, 0 comments)
  12. 510 points, 4 submissions: eddieweng
    1. Someone moved 12,220 BTC ($82M) in block 545,877 (393 points, 180 comments)
    2. Someone moved 22,200 BTC ($139M) in block 545,243 (90 points, 38 comments)
    3. CoinMarketBull – CoinMarketCap, but with a different metric (26 points, 4 comments)
    4. holdernews - trending stories on bitcointalk (1 point, 0 comments)
  13. 387 points, 1 submission: StoneHammers
    1. We are three months away from Bitcoins 10 year anniversary. (387 points, 39 comments)
  14. 366 points, 3 submissions: TrackCoinMarket-com
    1. Citizens of Venezuela have turned to Bitcoin and gold farming in online games to survive the country’s economic collapse. (365 points, 60 comments)
    2. Zambian Central Bank Declares Bitcoin Is Not Legal Tender (1 point, 7 comments)
    3. Bitcoin is Maturing, Crypto Growth Surprisingly Positive Reveals Study (0 points, 3 comments)
  15. 358 points, 1 submission: musicfan39
    1. Bitcoin all-time price graph (Aug 2010 – Oct 2018) (358 points, 84 comments)
  16. 311 points, 5 submissions: TheGreatMuffin
    1. Bitfinex' statement on fiat deposits/withdrawals (tldr: fiat and crypto withdrawals working, fiat deposits temporarily paused) (103 points, 52 comments)
    2. Bitfinex suspends all fiat deposits, “expects the situation to normalize within a week” (78 points, 62 comments)
    3. Fidelity gives a nod to OG cypherpunks (mentioning Adam Back, Nick Szabo, David Chaum) and bitcoin's precursors in their newest blog post (78 points, 0 comments)
    4. full video of the US Senate hearing on cryptocurrency: with P. Van Valkenburgh and N. Roubini as witnesses (starts at minute 16) (31 points, 5 comments)
    5. Interview with one of the creators of the Samourai wallet (21 points, 1 comment)
  17. 305 points, 1 submission: 6maud
    1. Jamie Dimon: Bitcoin is a scam. Also Jamie Dimon: Let's file 20 blockchain patents so we don't miss out on this blockchain thing. facepalm (305 points, 93 comments)
  18. 274 points, 2 submissions: undertheradar48
    1. $6.9 trillion of assets just got access to the world of crypto! (169 points, 24 comments)
    2. 1.65 Million people are attending over 5,000 Bitcoin meetups around the world. Organic interest/curiosity is real! (105 points, 41 comments)
  19. 265 points, 1 submission: NoGooderr
    1. Shorters, are you okay? (265 points, 123 comments)
  20. 253 points, 5 submissions: _smudger_
    1. Bakkt CEO: We're About To See A Cryptocurrency Revolution (130 points, 29 comments)
    2. Our team, launch and advocacy – Bakkt Blog – Medium (104 points, 33 comments)
    3. Coinbase's Adam White is joining Bakkt as its COO - The Block (16 points, 1 comment)
    4. The Bright Side of the 2018 Bitcoin Bear Market – Wes Carlson – Medium (2 points, 0 comments)
    5. Analysis: ErisX & Bakkt Are All in on the Battle for Institutional Cash (1 point, 0 comments)
  21. 247 points, 1 submission: Fly115
    1. It would be impossible for every Fidelity brokerage customer to own even one Bitcoin. This is why Bitcoins are worth thousands of dollars, while a dollar is only worth one dollar (and only until next year when when it's worth 97 cents). - Erik Voorhees (247 points, 129 comments)
  22. 237 points, 1 submission: manfromnantucket1984
    1. Bear markets are for building! 🐻⚡ While the price is doing what it does, we continue to build the #LightningNetwork at the #LightningHackdayNYC in New York on October 27th/28th 2018. Speakers like Christian Decker, Matt Corallo and Peter Todd will take you down the rabbit hole. (237 points, 15 comments)
  23. 232 points, 1 submission: TheMidnightMatinee
    1. Guys lets rally and show your support for an BTC ETF! Here's why! (232 points, 63 comments)
  24. 231 points, 2 submissions: installeris
    1. Fidelity just made it easier for hedge funds and other pros to invest in cryptocurrencies (169 points, 36 comments)
    2. Nouriel Roubini has always been talking sh*t about Bitcoin. And he's always wrong. (62 points, 29 comments)
  25. 226 points, 1 submission: lewtr
    1. An easter egg in the Bitcoin genesis block code (226 points, 40 comments)
  26. 218 points, 1 submission: Unusual_Mountain
    1. Bitcoin as a safe haven from monetary policy can help keep governments and banks honest. It doesn't have to replace them. (218 points, 85 comments)
  27. 214 points, 1 submission: Mobilenewsflash
    1. Roubini (214 points, 50 comments)
  28. 212 points, 1 submission: CardCollector1
    1. Getting Started with BTCPay Server - Free and Open Source Bitcoin and Lightning Network payment processor (212 points, 75 comments)
  29. 201 points, 1 submission: yonstonston
    1. Sorry guys, i bought BTC yesterday... (201 points, 72 comments)
  30. 161 points, 2 submissions: linzex
    1. A Bitcoin Lesson From A Yogi Master (93 points, 6 comments)
    2. ChangeNow Exchange Accused of $70,000 Theft (68 points, 8 comments)
  31. 159 points, 3 submissions: zappadoing
    1. greetings from holidays - I thought I won't have to read anything about bitcoin this time... (130 points, 12 comments)
    2. Telegram down! Lots of Bitcoin-Groups not accessible. We need something decentralized. (19 points, 26 comments)
    3. Colleges Are Baffled by Bitcoin Donations (10 points, 0 comments)
  32. 159 points, 1 submission: Crevative
    1. Zimbabwe spirals into economic chaos as fears of another round of hyperinflation begin to spark - another fiat currency fails! (159 points, 20 comments)
  33. 147 points, 1 submission: lexihayes99
    1. Just wanted to remind people of a simpler time :) (147 points, 196 comments)
  34. 146 points, 1 submission: Rare_Ad
    1. Bitcoin was a tool that was born of the economic crisis some 10 years ago, does that mean another big recession or banking collapse could catapult it forward? (146 points, 87 comments)
  35. 146 points, 1 submission: vmrey
    1. Buda, the largest crypto exchange by volume in Chile, is one of the first to incorporate Lightning network. (146 points, 14 comments)
  36. 145 points, 1 submission: wwwdata
    1. I own crypto but not Bitcoin. (145 points, 243 comments)
  37. 141 points, 9 submissions: expertbit
    1. This E-Bike Accepts Payments With Bitcoin's Lightning Network (51 points, 3 comments)
    2. Bitcoin [BTC] transfers will become a lot faster with Liquid Network, says Jimmy Song (37 points, 58 comments)
    3. Top Universities Are Now Investing in Cryptocurrency Funds (18 points, 0 comments)
    4. Indian Exchange Unocoin Could Launch Crypto ATMs (17 points, 0 comments)
    5. Bitcoin Price Stability -- A Bullish Or Bearish Sign? (15 points, 1 comment)
    6. Don’t Underestimate China’s Power In Bitcoin (2 points, 3 comments)
    7. Bitcoin Price Analysis: Bulls Defend Yearly Support Amidst Wall Street Slump (1 point, 0 comments)
    8. Bitcoin Network Comes To A Standstill In China (0 points, 2 comments)
    9. Bitcoin Price Jumps by $600 to Reach One-Month High Above $6.9k (0 points, 0 comments)
  38. 137 points, 1 submission: diditmakesound
    1. Everyone still buying right now (137 points, 30 comments)
  39. 135 points, 1 submission: gattacibus
    1. POLONIEX suspends Bitcoin withdrawals (135 points, 86 comments)
  40. 129 points, 3 submissions: nopara73
    1. Wasabi Wallet added OSX support. Please consider testing it. (55 points, 25 comments)
    2. Scoring Bitcoin Wallets (38 points, 25 comments)
    3. A Technical Overview of Wasabi Wallet, Future Ideas, Plans and Strategy (36 points, 1 comment)
  41. 123 points, 1 submission: Big_Bluefin
    1. Live from Fremont Street in Las Vegas (123 points, 20 comments)
  42. 121 points, 1 submission: agustinf
    1. Latin American Exchange Buda.com adds Lightning Network payments for all. (121 points, 17 comments)
  43. 118 points, 2 submissions: TheCrunk1
    1. Fidelity launches new company for trading, storing cryptocurrencies (98 points, 26 comments)
    2. Binance launches fiat-to-crypto exchange in Uganda (20 points, 7 comments)
  44. 112 points, 1 submission: Thinkmoreaboutit
    1. "Over the weekend I sent a bitcoin transaction to a relay 12.6km away with no cell network or internet connection. Here's a tweetstorm about how I used @gotenna and @SamouraiWallet to do it" [email protected] (112 points, 20 comments)
  45. 111 points, 1 submission: Jackieknows
    1. When it comes to your coins, keep it quiet. – Trezor Blog (111 points, 10 comments)
  46. 110 points, 1 submission: 100ravp
    1. Someone solved the 310.00 BTC challenge (110 points, 87 comments)
  47. 110 points, 1 submission: loulan
    1. There was an attempt (110 points, 78 comments)
  48. 106 points, 1 submission: king-only
    1. Breez, a Lightning Network mobile client, is now fully open sourced (106 points, 19 comments)
  49. 101 points, 2 submissions: HodlingToTheMoon
    1. Websites using Joomla (second most popular platform after Wordpress), can now be enabled with Bitcoin payments - In less than 5 min! (98 points, 5 comments)
    2. Got business on your mind? Here are 7 easy and genuine ideas to start a Bitcoin-centric e-commerce store! (3 points, 0 comments)
  50. 98 points, 1 submission: ubunt2
    1. Fidelity Starts Crypto Unit to Serve Wall Street Customers (98 points, 4 comments)
  51. 97 points, 1 submission: CosmicHemorroid
    1. Lightning Powered E-bike #Reckless (97 points, 22 comments)
  52. 96 points, 3 submissions: DesignerAccount
    1. Bitcoin is all grown up! (83 points, 6 comments)
    2. [Bitcoin OpSec - Keep your coins safe] Detailed breakdown of sophisticated scam (12 points, 6 comments)
    3. Infographic - How do UTXOs work? (1 point, 0 comments)
  53. 96 points, 1 submission: bowlingfries
    1. Bitcoin kiosk in Portland OR weed dispensary (96 points, 21 comments)
  54. 94 points, 1 submission: nassimmontreal
    1. #roubinilovescrypto (94 points, 37 comments)
  55. 92 points, 2 submissions: ella11price
    1. Selling goods and items for Bitcoin should be easy. I built a marketplace similar to eBay so people can sell anything for crypto. This video explains it. (91 points, 63 comments)
    2. The best ways to earn bitcoin and cryptocurrency. Includes how to spot a scam (1 point, 0 comments)
  56. 91 points, 1 submission: ytcoinartist
    1. The Golden Pineapple, a 3D combination puzzle for all ages and free to play. Be the first to solve the final level and win 1 BTC, courtesy of The Pineapple Fund. http://pineapplearcade.net/arcade-game/pineapple (91 points, 25 comments)
  57. 89 points, 1 submission: Rachsuchtig
    1. An BTC ATM at Austria/Salzburg Shopping Arena, totally surprised to see (89 points, 11 comments)
  58. 87 points, 2 submissions: Ishan1121
    1. Bitcoin proves once again its the best way to transfer money! $194 million transferred for 10 cents. (87 points, 18 comments)
    2. Discussion: So Bitcoin rises as fake news on Binance delisting Tether (USDT) goes viral...removing Tether completley will affect the market positively? THoughts? (0 points, 6 comments)
  59. 87 points, 1 submission: Blixx87
    1. I finally figured it out! We have been forming a Dorito Pattern and it’s on it’s way to the cheese dip. (87 points, 49 comments)
  60. 86 points, 8 submissions: EffigyBoy
    1. Venezuelans Play RuneScape To Make Small Profit In Bitcoin (31 points, 4 comments)
    2. CFTC Chair On Bitcoin Expansion: "We Are Seeing More Institutional Movement Into This Area" (26 points, 0 comments)
    3. The Indian Government is Considering to Launch Its Own Cryptocurrency to Avoid Citizens Using Bitcoin (13 points, 14 comments)
    4. The Congress Is Groping In The Dark To Handle Cryptocurrencies. Bitcoin has come into the mainstream. (6 points, 0 comments)
    5. After Stock Markets Plunge Cryptocurrency Whale Dumps over 22 100 BTC (5 points, 11 comments)
    6. Scientific Journal 'Chaos' Favors Bitcoin – As stable as Oil and Dollar Markets (2 points, 1 comment)
    7. The First Physical Cryptocurrency Store in The U.S. Launches on October 20 (2 points, 1 comment)
    8. Omniex and Gemini Struck A Partnership to Support Institutional Investors (1 point, 0 comments)
  61. 85 points, 2 submissions: jakesonwu
    1. Release - Eclair v0.2-beta7 - Compatible with Bitcoin Core 0.17.0 (75 points, 8 comments)
    2. Lord Keynes Would Be Proud (10 points, 1 comment)
  62. 84 points, 2 submissions: renepickhardt
    1. ECDSA is not that bad: two-party signing without Schnorr or BLS (by Stepan Snigirev) (53 points, 7 comments)
    2. Last week in Lightning Network: A weekly collection of lightning network (and related) news on Twitter (31 points, 6 comments)
  63. 83 points, 3 submissions: OldCarpet54
    1. [GIVEAWAY] Crypto Invest Summit – Wozniak, Gupta, Morehead (82 points, 1 comment)
    2. blockchain news: from SF Blockchain Week and XBlockchain (1 point, 0 comments)
    3. Buterin | SpankChain | Kambria: San Francisco Blockchain Week (0 points, 0 comments)
  64. 83 points, 1 submission: -elektro-pionir-
    1. AMA with Bitcoin engineer Jameson Lopp (83 points, 21 comments)
  65. 80 points, 3 submissions: ysangkok
    1. Bitcoin script discussion at Scaling Bitcoin: "Sporks are probabilistic soft-forks [...] where instead of [...] version bits if the blockhash has some [...] PoW below some threshold, it activates. [...] [E.g.] you have an expectation of 6 months to get your shit together. Doing it live." (28 points, 3 comments)
    2. Multi-Hop Locks for Secure, Privacy-Preserving and Interoperable Payment-Channel Networks (27 points, 8 comments)
    3. Scaling Bitcoin Kaizen - Scriptless scripts, adaptor signatures and their applications (25 points, 2 comments)
  66. 78 points, 3 submissions: mkuraja
    1. What's the difference between Lightning Network and Liquid Network? (57 points, 41 comments)
    2. Need some fresh, new FOMO in your life? Reenter, Trace Mayer. (15 points, 1 comment)
    3. This American tourist thought I'd see "Bitcoin Accepted Here" all over Tokyo, Japan but not one place found yet. (6 points, 17 comments)
  67. 77 points, 1 submission: Miladran
    1. Fidelity Says It Will Trade Bitcoin for Hedge Funds (77 points, 1 comment)
  68. 77 points, 1 submission: pandaman200
    1. Swiss Crypto Fund Obtains Country’s First Crypto Asset Management License (77 points, 4 comments)
  69. 75 points, 3 submissions: mickhick95
    1. I purchased a goTenna to broadcast my BTC transactions with TxTenna and Samourai Wallet. (44 points, 15 comments)
    2. I saw a Bitcoin ATM and I had to make a purchase. (28 points, 41 comments)
    3. 303-ish Days in the BTC Bear Market, This Sideways Motion Looks Like A Turn Around!!! (3 points, 16 comments)
  70. 75 points, 1 submission: hcarpach
    1. Venezuelan cryptocurrency miner: “we are police’s most wanted” (75 points, 21 comments)
  71. 73 points, 6 submissions: WorkCoin_Team
    1. “Bitcoin enables certain uses that are very unique. I think it offers possibilities that no other currency allows. For example the ability to spend a coin that only occurs when two separate parties agree to spend the coin; with a third party that couldn’t run away with the coin itself.” – Pieter Wui (66 points, 14 comments)
    2. Revolution of Bitcoin (5 points, 3 comments)
    3. A Funny Bitcoin Thought (2 points, 20 comments)
    4. Getting started with Bitcoin (0 points, 1 comment)
    5. Make your foundation strong (0 points, 0 comments)
    6. What are you not willing to compromise? (0 points, 6 comments)
  72. 73 points, 1 submission: ozdixon
    1. Bitcoin accepted at a absenth bar in Prague. (73 points, 11 comments)
  73. 72 points, 1 submission: Itasia
    1. What Are Atomic Swaps? Ultimate Guide (72 points, 16 comments)
  74. 71 points, 1 submission: MannyAndDrChurchShow
    1. I wonder if they would still honor this card.... (71 points, 9 comments)
  75. 68 points, 4 submissions: grittygatorr
    1. Liquid Network - the world’s first production Bitcoin sidechain has officially gone live (65 points, 100 comments)
    2. XDEX Advertises Commission-Free Bitcoin Trading in Brazil (2 points, 0 comments)
    3. Coinfloor to Cut on Staff and Reorganize Amid Volume Fluctuations in the Crypto Markets (1 point, 0 comments)
    4. Barclays Temporarily Suspends Work on Cryptocurrency Trading Project (0 points, 1 comment)
  76. 68 points, 1 submission: WouterGlorieux
    1. Introducing 'The Bitcoin Spellbook': an open-source REST API server for the back-end of (almost) any Bitcoin application. (Think of it as your own IfThisThenThat server but for Bitcoin) (68 points, 3 comments)
  77. 67 points, 1 submission: Vaultoro_official
    1. Leading up to the LightingNetwork Hackathon in NY, I thought I would post the talks we filmed at the Berlin lightningHackDay. Some amazing talks! (67 points, 1 comment)
  78. 65 points, 1 submission: Komodor123
    1. Do you speak more than one language? Then help spread Bitcoin around the world by translating Bitcoin.org! (65 points, 28 comments)
  79. 63 points, 1 submission: Sandiegosurf1
    1. Fidelity Launches Institutional Crypto Trading and Clearing. Let the institutional money flow! (63 points, 1 comment)
  80. 63 points, 1 submission: TearAnus-SoreAssRekt
    1. Buying PC Games With Bitcoin: Site Reviews (with some accepting Lightning!) (63 points, 7 comments)
  81. 62 points, 1 submission: CryptoCloaks
    1. We finally got our RaspiBlitz case to a level we love! Time for load testing to check thermals, final mods are almost done! (62 points, 10 comments)
  82. 61 points, 1 submission: sagiher
    1. #Liberte#CaribbeanBitcoin#ShoutOutToAllBitcoinDeveloperOutThere (61 points, 9 comments)

Top Commenters

  1. PragmaticParadox (465 points, 7 comments)
  2. ikarienator (462 points, 1 comment)
  3. Hanspanzer (434 points, 106 comments)
  4. Toyake (434 points, 71 comments)
  5. uglymelt (394 points, 3 comments)
  6. UsherTechs (377 points, 1 comment)
  7. isdudu (345 points, 4 comments)
  8. TyroneTheDriver (307 points, 1 comment)
  9. Rattlesnake_Mullet (296 points, 11 comments)
  10. andycam7 (282 points, 3 comments)
  11. dmdeemer (275 points, 1 comment)
  12. BTCkoning (266 points, 114 comments)
  13. CP70 (257 points, 7 comments)
  14. ascension8438 (239 points, 7 comments)
  15. Fly115 (226 points, 9 comments)
  16. haribo_2016 (220 points, 4 comments)
  17. dsmid (214 points, 1 comment)
  18. i_gotta_say (208 points, 87 comments)
  19. TheGreatMuffin (206 points, 56 comments)
  20. ebaley (198 points, 34 comments)
  21. bitsteiner (185 points, 86 comments)
  22. Redditridder (181 points, 5 comments)
  23. KupKhunKrap (173 points, 36 comments)
  24. 45sbvad (169 points, 3 comments)
  25. c3corvette (165 points, 2 comments)
  26. killerstorm (163 points, 8 comments)
  27. evilgrinz (158 points, 48 comments)
  28. chronic_nervosa (140 points, 1 comment)
  29. bigdaddysdick (136 points, 7 comments)
  30. castorfromtheva (129 points, 27 comments)
  31. Touchmyhandle (125 points, 12 comments)
  32. Euphoricsoul (122 points, 1 comment)
  33. WaterMac27 (122 points, 1 comment)
  34. DSXIII (118 points, 1 comment)
  35. RIMS_REAL_BIG (117 points, 24 comments)
  36. cryptogrip (112 points, 39 comments)
  37. WalterRyan (108 points, 10 comments)
  38. sudophant (107 points, 5 comments)
  39. NotSeeTroll (104 points, 37 comments)
  40. deadleg22 (104 points, 10 comments)
  41. shared_makes_it_real (103 points, 26 comments)
  42. alexiglesias007 (103 points, 7 comments)
  43. Buttoshi (102 points, 68 comments)
  44. flunderbossanova (102 points, 59 comments)
  45. lexihayes99 (101 points, 28 comments)
  46. mabezard (101 points, 2 comments)
  47. peniswithahoodie (98 points, 1 comment)
  48. beloboi (96 points, 65 comments)
  49. vovr (89 points, 3 comments)
  50. segells4soulsmogoblo (89 points, 1 comment)
  51. damchi (87 points, 21 comments)
  52. smadgerano (81 points, 14 comments)
  53. time_wasted504 (80 points, 34 comments)
  54. joeknowswhoiam (80 points, 16 comments)
  55. diydude2 (79 points, 26 comments)
  56. sQtWLgK (79 points, 17 comments)
  57. 989x4000 (78 points, 22 comments)
  58. sreaka (78 points, 16 comments)
  59. YoungScholar89 (78 points, 6 comments)
  60. Ellipso (76 points, 2 comments)
  61. HitsABlunt (76 points, 1 comment)
  62. almkglor (75 points, 39 comments)
  63. MrRGnome (75 points, 37 comments)
  64. Daddeus65 (75 points, 28 comments)
  65. whalecheetah (75 points, 25 comments)
  66. BCash_BeTrash (75 points, 23 comments)
  67. cipher-space (75 points, 19 comments)
  68. bnuttall (72 points, 2 comments)
  69. chrisrico (71 points, 26 comments)
  70. esdraelon (71 points, 8 comments)
  71. ale1ormont (71 points, 2 comments)
  72. igadjeed (70 points, 42 comments)
  73. Holographiks (70 points, 19 comments)
  74. frankieboy07 (70 points, 2 comments)
  75. snazzycoins (69 points, 12 comments)
  76. dmar198 (69 points, 11 comments)
  77. protoman86 (69 points, 7 comments)
  78. bitbug42 (68 points, 5 comments)
  79. CardCollector1 (66 points, 16 comments)
  80. hawks5999 (66 points, 7 comments)
  81. DefiantVerse (65 points, 12 comments)
  82. psionides (65 points, 8 comments)
  83. btc-forextrader (64 points, 37 comments)
  84. UniqueNewQuark (63 points, 5 comments)
  85. imaducksfan (63 points, 1 comment)
  86. bitusher (62 points, 23 comments)
  87. homad (62 points, 13 comments)
  88. torbitonsa (62 points, 7 comments)
  89. violencequalsbad (62 points, 7 comments)
  90. wwwdata (61 points, 20 comments)
  91. LadyRosedancer (61 points, 1 comment)
  92. Nunoyabiznes (60 points, 22 comments)
  93. pg3crypto (60 points, 13 comments)
  94. XxArmadaxX (60 points, 4 comments)
  95. awertheim (59 points, 27 comments)
  96. Ploxxx69 (59 points, 1 comment)
  97. TheGlassStone (59 points, 1 comment)
  98. moodytomatoes (58 points, 39 comments)
  99. Sneakybobo (58 points, 13 comments)
  100. UniqueCandy (58 points, 8 comments)

Top Submissions

  1. Anti-crypto propaganda... promoted by American Express by Alexsayzz (4526 points, 513 comments)
  2. Someone just paid $0.10 to move $194M (29,999 BTC). Think about how powerful that is for a second. by MoonMan_666 (2369 points, 380 comments)
  3. When your boss thanks you for staying late at work but you were just watching the Bitcoin price and lost track of time by _Logicrypto (2077 points, 69 comments)
  4. ⚡Lightning Network at the Senate - Counterargument to Roubini's speech that Bitcoin can never scale to serve the planet by bitbug42 (1496 points, 186 comments)
  5. Why sell and pay capital gains, why not wait for mass adoption? That's my motto. by opencoins (1417 points, 244 comments)
  6. Took a while but finally part of the picture club (had to wait on the web browser update!) by awertheim (1174 points, 127 comments)
  7. Feeling good? by Hodl_it (853 points, 215 comments)
  8. Bitcoin ATM operator gets the $62,500 that police confiscated back by cointastical (833 points, 110 comments)
  9. Congratulations US senators for understanding crypto better than this guy by JandyJammer (748 points, 125 comments)
  10. ...in case you missed the laura shill burn today by lesbiansareoverrated (704 points, 100 comments)

Top Comments

  1. 462 points: ikarienator's comment in Feeling good?
  2. 456 points: PragmaticParadox's comment in Anti-crypto propaganda... promoted by American Express
  3. 387 points: uglymelt's comment in ⚡Lightning Network at the Senate - Counterargument to Roubini's speech that Bitcoin can never scale to serve the planet
  4. 377 points: UsherTechs's comment in When your boss thanks you for staying late at work but you were just watching the Bitcoin price and lost track of time
  5. 342 points: isdudu's comment in Anti-crypto propaganda... promoted by American Express
  6. 307 points: TyroneTheDriver's comment in Anti-crypto propaganda... promoted by American Express
  7. 276 points: andycam7's comment in Why sell and pay capital gains, why not wait for mass adoption? That's my motto.
  8. 275 points: dmdeemer's comment in Someone just paid $0.10 to move $194M (29,999 BTC). Think about how powerful that is for a second.
  9. 268 points: Rattlesnake_Mullet's comment in Someone moved 12,220 BTC ($82M) in block 545,877
  10. 244 points: CP70's comment in Anti-crypto propaganda... promoted by American Express
Generated with BBoe's Subreddit Stats
submitted by subreddit_stats to subreddit_stats [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]

Bitcoinj 0.11 released

Mike Hearn posted this on the Bitcoin Developer Mailing List:
I'm pleased to announce the release of bitcoinj 0.11, a library for writing Bitcoin applications that run on the JVM. BitcoinJ is widely used across the Bitcoin community; some users include Bitcoin Wallet for Android, MultiBit, Hive, blockchain.info, the biteasy.com block explorer (written in Lisp!), Circle, Neo/Bee (Cypriot payment network), bitpos.me, Bitcoin Touch, BlueMatt's relay network and DNS crawler, academic advanced contracts research and more.
The release-0.11 git tag is signed by Andreas Schildbach's GPG key. The commit hash is 410d4547a7dd. This paragraph is signed by the same Bitcoin key as with previous releases (check their release announcements to establish continuity). Additionally, this email is signed using DKIM and for the first time, a key that was ID verified by the Swiss government.
Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m
Signature for last paragraph: H3DvWBqFHPxKW/cdYUdZ6OHjbq6ZtC5PHK4ebpeiE+FqTHyRLJ58BItbC0R2vo77h+DthpQigdEZ0V8ivSM7VIg=
Notable changes and new features
Smaller improvements
Notable bug fixes
API changes
New documentation
Announcement: https://groups.google.com/forum/?fromgroups#!topic/bitcoinj-announce/3LW0uXhlRZY
Message on Bitcoin Developer Mailing List: http://www.mail-archive.com/[email protected]/msg03873.html
Google Code: https://code.google.com/p/bitcoinj/
GitHub: https://github.com/bitcoinj/bitcoinj
Edit: Added links to articles about BIP39 and BIP70 which were included in the original announcement.
submitted by alsomahler to Bitcoin [link] [comments]

Compact Block Relay BIP | Matt Corallo | May 02 2016

Matt Corallo on May 02 2016:
Hi all,
The following is a BIP-formatted design spec for compact block relay
designed to limit on wire bytes during block relay. You can find the
latest version of this document at
https://github.com/TheBlueMatt/bips/blob/mastebip-TODO.mediawiki.
There are several TODO items left on the document as indicated.
Additionally, the implementation linked at the bottom of the document
has a few remaining TODO items as well:
time, as the spec requires.
spec, up to 10K in transactions.
Luke (CC'd): Can you assign a BIP number?
Thanks,
Matt
BIP: TODO
Title: Compact block relay
Author: Matt Corallo
Status: Draft
Type: Standards Track
Created: 2016-04-27
==Abstract==
Compact blocks on the wire as a way to save bandwidth for nodes on the
P2P network.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
==Motivation==
Historically, the Bitcoin P2P protocol has not been very bandwidth
efficient for block relay. Every transaction in a block is included when
relayed, even though a large number of the transactions in a given block
are already available to nodes before the block is relayed. This causes
moderate inbound bandwidth spikes for nodes when receiving blocks, but
can cause very significant outbound bandwidth spikes for some nodes
which receive a block before their peers. When such spikes occur, buffer
bloat can make consumer-grade internet connections temporarily unusable,
and can delay the relay of blocks to remote peers who may choose to wait
instead of redundantly requesting the same block from other, less
congested, peers.
Thus, decreasing the bandwidth used during block relay is very useful
for many individuals running nodes.
While the goal of this work is explicitly not to reduce block transfer
latency, it does, as a side effect reduce block transfer latencies in
some rather significant ways. Additionally, this work forms a foundation
for future work explicitly targeting low-latency block transfer.
==Specification==
===Intended Protocol Flow===
TODO: Diagrams
The protocol is intended to be used in two ways, depending on the peers
and bandwidth available, as discussed [[#Implementation_Details|later]].
The "high-bandwidth" mode, which nodes may only enable for a few of
their peers, is enabled by setting the first boolean to 1 in a
"sendcmpct" message. In this mode, peers send new block announcements
with the short transaction IDs already, possibly even before fully
validating the block. In some cases no further round-trip is needed, and
the receiver can reconstruct the block and process it as usual
immediately. When some transactions were not available from local
sources (ie mempool), a getblocktxn/blocktxn roundtrip is neccessary,
bringing the best-case latency to the same 1.5*RTT minimum time that
nodes take today, though with significantly less bandwidth usage.
The "low-bandwidth" mode is enabled by setting the first boolean to 0 in
a "sendcmpct" message. In this mode, peers send new block announcements
with the usual inv/headers announcements (as per BIP130, and after fully
validating the block). The receiving peer may then request the block
using a MSG_CMPCT_BLOCK getdata reqeuest, which will receive a response
of the header and short transaction IDs. In some cases no further
round-trip is needed, and the receiver can reconstruct the block and
process it as usual, taking the same 1.5*RTT minimum time that nodes
take today, though with significantly less bandwidth usage. When some
transactions were not available from local sources (ie mempool), a
getblocktxn/blocktxn roundtrip is neccessary, bringing the best-case
latency to 2.5*RTT, again with significantly less bandwidth usage than
today. Because TCP often exhibits worse transfer latency for larger data
sizes (as a multiple of RTT), total latency is expected to be reduced
even when full the 2.5*RTT transfer mechanism is used.
===New data structures===
Several new data structures are added to the P2P network to relay
compact blocks: PrefilledTransaction, HeaderAndShortIDs,
BlockTransactionsRequest, and BlockTransactions. Additionally, we
introduce a new variable-length integer encoding for use in these data
structures.
For the purposes of this section, CompactSize refers to the
variable-length integer encoding used across the existing P2P protocol
to encode array lengths, among other things, in 1, 3, 5 or 9 bytes.
====New VarInt====
TODO: I just copied this out of the src...Something that is
wiki-formatted and more descriptive should be used here isntead.
Variable-length integers: bytes are a MSB base-128 encoding of the number.
The high bit in each byte signifies whether another digit follows. To make
sure the encoding is one-to-one, one is subtracted from all but the last
digit.
Thus, the byte sequence a[] with length len, where all but the last byte
has bit 128 set, encodes the number:
(a[len-1] & 0x7F) + sum(i=1..len-1, 128i*((a[len-i-1] & 0x7F)+1))
Properties:
0: [0x00] 256: [0x81 0x00]
1: [0x01] 16383: [0xFE 0x7F]
127: [0x7F] 16384: [0xFF 0x00]
128: [0x80 0x00] 16511: [0x80 0xFF 0x7F]
255: [0x80 0x7F] 65535: [0x82 0xFD 0x7F]
232: [0x8E 0xFE 0xFE 0xFF 0x00]
Several uses of New VarInts below are "differentially encoded". For
these, instead of using raw indexes, the number encoded is the
difference between the current index and the previous index, minus one.
For example, a first index of 0 implies a real index of 0, a second
index of 0 thereafter refers to a real index of 1, etc.
====PrefilledTransaction====
A PrefilledTransaction structure is used in HeaderAndShortIDs to provide
a list of a few transactions explicitly.
{|
|Field Name||Type||Size||Encoding||Purpose
|-
|index||New VarInt||1-3 bytes||[[#New_VarInt|New VarInt]],
differentially encoded since the last PrefilledTransaction in a
list||The index into the block at which this transaction is
|-
|tx||Transaction||variable||As encoded in "tx" messages||The transaction
which is in the block at index index.
|}
====HeaderAndShortIDs====
A HeaderAndShortIDs structure is used to relay a block header, the short
transactions IDs used for matching already-available transactions, and a
select few transactions which we expect a peer may be missing.
{|
|Field Name||Type||Size||Encoding||Purpose
|-
|header||Block header||80 bytes||First 80 bytes of the block as defined
by the encoding used by "block" messages||The header of the block being
provided
|-
|nonce||uint64_t||8 bytes||Little Endian||A nonce for use in short
transaction ID calculations
|-
|shortids_length||CompactSize||1, 3, 5, or 9 bytes||As used elsewhere to
encode array lengths||The number of short transaction IDs in shortids
|-
|shortids||List of uint64_ts||8*shortids_length bytes||Little
Endian||The short transaction IDs calculated from the transactions which
were not provided explicitly in prefilledtxn
|-
|prefilledtxn_length||CompactSize||1, 3, 5, or 9 bytes||As used
elsewhere to encode array lengths||The number of prefilled transactions
in prefilledtxn
|-
|prefilledtxn||List of PrefilledTransactions||variable
size*prefilledtxn_length||As defined by PrefilledTransaction definition,
above||Used to provide the coinbase transaction and a select few which
we expect a peer may be missing
|}
====BlockTransactionsRequest====
A BlockTransactionsRequest structure is used to list transaction indexes
in a block being requested.
{|
|Field Name||Type||Size||Encoding||Purpose
|-
|blockhash||Binary blob||32 bytes||The output from a double-SHA256 of
the block header, as used elsewhere||The blockhash of the block which
the transactions being requested are in
|-
|indexes_length||New VarInt||1-3 bytes||As defined in [[#New_VarInt|New
VarInt]]||The number of transactions being requested
|-
|indexes||List of New VarInts||1-3 bytes*indexes_length||As defined in
[[#New_VarInt|New VarInt]], differentially encoded||The indexes of the
transactions being requested in the block
|}
====BlockTransactions====
A BlockTransactions structure is used to provide some of the
transactions in a block, as requested.
{|
|Field Name||Type||Size||Encoding||Purpose
|-
|blockhash||Binary blob||32 bytes||The output from a double-SHA256 of
the block header, as used elsewhere||The blockhash of the block which
the transactions being provided are in
|-
|transactions_length||New VarInt||1-3 bytes||As defined in
[[#New_VarInt|New VarInt]]||The number of transactions provided
|-
|transactions||List of Transactions||variable||As encoded in "tx"
messages||The transactions provided
|}
====Short transaction IDs====
Short transaction IDs are used to represent a transaction without
sending a full 256-bit hash. They are calculated by:

single-SHA256 hashing the block header with the nonce appended (in

little-endian)

XORing each 8-byte chunk of the double-SHA256 transaction hash with

each correspondi...[message truncated here by reddit bot]...
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012624.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-11-12)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
transaction priority for 0.12 Opt-in replace-by-fee Versionbits Chain limits
transaction priority for 0.12
Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which currently makes some transactions free. This currently has a large amount of code, which makes it harder to maintain, and is not that optimal since you can't expect miners to include 0-fee transactions.
Most people seem fine with removing priority in the mempool, but people should be notified ahead of time this is coming. sdaftuar proposed a staggered approach, setting the default value for priority to 0, and remove it entirely in the next release. petertodd notes there will be a natural staggered process since not everyone will upgrade to 0.12 instantly and some implementations might not remove priority at all. Most wallet-software outside of bitcoin-core don't implement priority calculations. As fee estimation becomes more important and many wallet providers use the bitcoin-core fee estimation, improvements on that are welcome. Luke-Jr doesn't agree with removing priority, particularly with changing the mining code to use the priority a transaction has when it enters the mempool. Sipa has the idea to add a small fraction of bitcoin days destroyed divided by the average UTXO age to the fee, so that non-spam-attack transactions are viewed as if they have a larger fee.
While most agree with the proposal to remove the current priority, there's still much debate on whether it needs to be replaced for 0.13, and if so, how.
Review "Improve usage of fee estimation code" BlueMatt will mail the developer mailinglist announcing the changes. ( https://www.mail-archive.com/[email protected]/msg02790.html )
Opt-in replace-by-fee
Currently when a node sees a transaction that spends the same output it ignores it. With replace-by-fee it replaces the current transaction in the mempool if it has a higher fee. This allows for things like spending "stuck" transactions, adding more recipients to a transaction in order to prevent chaining, etc.
Since there are people that accept 0-confirmation transactions and this would make it extremely easy to double spend them, this is made opt-in. The sender can choose to opt-in to replace-by-fee by changing an input in the nSequence field.
Peter Todd wrote some tools to use replace-by-fee. link It would be nice to have opt-in per output instead of the whole transaction, however that would be very hard to implement and would have some privacy concerns. Luke-Jr would like to see an option to toggle between first-seen-safe/full RBF and neveopt-in/always. Since there are possibly some objections with the "always" toggle it should be a separate pull-request.
review and merge nSequence-based Full-RBF opt-in Peter Todd will write a mail to the list to explain how it works and how people can not accept opt-in transactions.
Versionbits
BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than Y the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.
There are 2 different implementations. One from Codeshark and one from Rusty jtimon thinks both implementations are more complicated than they need to be. There needs to be a minor revision namely a starting time for proposals. In general we'd like to get this in soon, but existing softforks need to complete first.
CodeShark adds a starting time to versionbits.
Chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent malleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
Wumpus doesn't feel comfortable with merging it because there's some controversy from companies who exceed the limits (or could be/want to). jgarzik does feel comfortable with it, and many think it should be merged as it's easy to revert if needed. There's little choice as it's not safe from attacks without limits. We should communicate the replace-by-fee sendmany alternative to long chains (adding new recipients on existing non-confirmed transactions), although it won't show up in users wallet yet and block-explorers probably aren't ready to display it correctly. Emphasis on the fact it's a change in default values, not a consensus change, however default values have a lot of power. The final limits are 25 transactions and 101kb total size for both ancestor and descendant packages.
jgarzik will merge the pull-request. Morcos will mail the list once it's merged.
Participants
BlueMatt Matt Corallo petertodd Peter Todd morcos Alex Morcos jgarzik Jeff Garzik gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan Luke-Jr Luke Dashjr jtimon Jorge Timón btcdrak btcdrak phantomcircuit Patrick Strateman sipa Pieter Wuille CodeShark Eric Lombrozo sdaftuar Suhas Daftuar jg_taxi jg_taxi gavinandresen Gavin Andresen cfields Cory Fields bsm1175321 Bob McElrath 
Comic relief
19:53 sipa new topic? 19:53 wumpus any other topics? 19:53 petertodd  19:53 jgarzik did we cover jonas while I was in the taxi? 19:54 sdaftuar ? 19:54 jtimon ? 19:54 CodeShark not sure I want to know 19:54 jgarzik proposal for new GUI maintainer 19:54 CodeShark sounds kinky, though 19:54 petertodd CodeShark: GUI's are pretty kinky 19:56 BlueMatt ok, end meeting? 19:56 btcdrak if we can remember the command this week :-) 19:56 wumpus #meetingend 19:56 gmaxwell #destroymeeting 19:56 wumpus #endmeeting 19:56 Luke-Jr #endmeeting 19:56 lightningbot Meeting ended Thu Nov 12 19:56:42 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 19:56 BlueMatt #magicmeetbotincantation 19:57 petertodd #DoWhatIMean 
submitted by G1lius to btc [link] [comments]

Macavity the Mystery Cat: He's not there!

[bitcoin-dev] Block size: It's economics & user preparation & moral hazard Jeff Garzik
[bitcoin-dev] Block size: It's economics & user preparation & moral hazard Pieter While
[bitcoin-dev] Block size: It's economics & user preparation & moral hazard jl2012
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Jeff Garzik
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Matt Corallo
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Pieter Wuille
[bitcoin-dev] Block size: It's economics & user preparation & moral hazard Jeff Garzik
[bitcoin-dev] Block size: It's economics & user preparation & moral hazard Pieter Wuille
[bitcoin-dev] Block size: It's economics & user preparation & moral hazard Jorge Timón
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Jeff Garzik
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Pieter Wuille
[bitcoin-dev] Block size: It's economics & user preparation & moral hazard Jeff Garzik
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Jeff Garzik
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Jeff Garzik
[bitcoin-dev] Block size: It's economics & user preparation & moral hazard Jeff Garzik
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Matt Corallo
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Matt Corallo
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Jeff Garzik
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Eric Lombrozo
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Jeff Garzik
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Adam Back
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Anthony Towns
[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin jl2012
[bitcoin-dev] Block size: It's economics & user preparation & moral hazard Dave Scotese
https://en.wikipedia.org/wiki/Macavity
submitted by solex1 to btc [link] [comments]

Bitcoin Core 0.10.0 released | Wladimir | Feb 16 2015

Wladimir on Feb 16 2015:
Bitcoin Core version 0.10.0 is now available from:
https://bitcoin.org/bin/0.10.0/
This is a new major version release, bringing both new features and
bug fixes.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
The whole distribution is also available as torrent:
https://bitcoin.org/bin/0.10.0/bitcoin-0.10.0.torrent
magnet:?xt=urn:btih:170c61fe09dafecfbb97cb4dccd32173383f4e68&dn;=0.10.0&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Fopen.demonii.com%3A1337&ws;=https%3A%2F%2Fbitcoin.org%2Fbin%2F
Upgrading and downgrading

How to Upgrade
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).
Downgrading warning
Because release 0.10.0 makes use of headers-first synchronization and parallel
block download (see further), the block files and databases are not
backwards-compatible with older versions of Bitcoin Core or other software:
  • Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.
  • The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.
If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.
This does not affect wallet forward or backward compatibility.
Notable changes

Faster synchronization
Bitcoin Core now uses 'headers-first synchronization'. This means that we first
ask peers for block headers (a total of 27 megabytes, as of December 2014) and
validate those. In a second stage, when the headers have been discovered, we
download the blocks. However, as we already know about the whole chain in
advance, the blocks can be downloaded in parallel from all available peers.
In practice, this means a much faster and more robust synchronization. On
recent hardware with a decent network link, it can be as little as 3 hours
for an initial full synchronization. You may notice a slower progress in the
very first few minutes, when headers are still being fetched and verified, but
it should gain speed afterwards.
A few RPCs were added/updated as a result of this:
  • getblockchaininfo now returns the number of validated headers in addition to
the number of validated blocks.
  • getpeerinfo lists both the number of blocks and headers we know we have in
common with each peer. While synchronizing, the heights of the blocks that we
have requested from peers (but haven't received yet) are also listed as
'inflight'.
  • A new RPC getchaintips lists all known branches of the block chain,
including those we only have headers for.
Transaction fee changes
This release automatically estimates how high a transaction fee (or how
high a priority) transactions require to be confirmed quickly. The default
settings will create transactions that confirm quickly; see the new
'txconfirmtarget' setting to control the tradeoff between fees and
confirmation times. Fees are added by default unless the 'sendfreetransactions'
setting is enabled.
Prior releases used hard-coded fees (and priorities), and would
sometimes create transactions that took a very long time to confirm.
Statistics used to estimate fees and priorities are saved in the
data directory in the fee_estimates.dat file just before
program shutdown, and are read in at startup.
New command line options for transaction fee changes:
  • -txconfirmtarget=n : create transactions that have enough fees (or priority)
so they are likely to begin confirmation within n blocks (default: 1). This setting
is over-ridden by the -paytxfee option.
  • -sendfreetransactions : Send transactions as zero-fee transactions if possible
(default: 0)
New RPC commands for fee estimation:
  • estimatefee nblocks : Returns approximate fee-per-1,000-bytes needed for
a transaction to begin confirmation within nblocks. Returns -1 if not enough
transactions have been observed to compute a good estimate.
  • estimatepriority nblocks : Returns approximate priority needed for
a zero-fee transaction to begin confirmation within nblocks. Returns -1 if not
enough free transactions have been observed to compute a good
estimate.
RPC access control changes
Subnet matching for the purpose of access control is now done
by matching the binary network address, instead of with string wildcard matching.
For the user this means that -rpcallowip takes a subnet specification, which can be
  • a single IP address (e.g. 1.2.3.4 or fe80::0012:3456:789a:bcde)
  • a network/CIDR (e.g. 1.2.3.0/24 or fe80::0000/64)
  • a network/netmask (e.g. 1.2.3.4/255.255.255.0 or fe80::0012:3456:789a:bcde/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
An arbitrary number of -rpcallow arguments can be given. An incoming connection will be accepted if its origin address
matches one of them.
For example:
| 0.9.x and before | 0.10.x |
|--------------------------------------------|---------------------------------------|
| -rpcallowip=192.168.1.1 | -rpcallowip=192.168.1.1 (unchanged) |
| -rpcallowip=192.168.1.* | -rpcallowip=192.168.1.0/24 |
| -rpcallowip=192.168.* | -rpcallowip=192.168.0.0/16 |
| -rpcallowip=* (dangerous!) | -rpcallowip=::/0 (still dangerous!) |
Using wildcards will result in the rule being rejected with the following error in debug.log:
 Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). 
REST interface
A new HTTP API is exposed when running with the -rest flag, which allows
unauthenticated access to public node data.
It is served on the same port as RPC, but does not need a password, and uses
plain HTTP instead of JSON-RPC.
Assuming a local RPC server running on port 8332, it is possible to request:
In every case, EXT can be bin (for raw binary data), hex (for hex-encoded
binary) or json.
For more details, see the doc/REST-interface.md document in the repository.
RPC Server "Warm-Up" Mode
The RPC server is started earlier now, before most of the expensive
intialisations like loading the block index. It is available now almost
immediately after starting the process. However, until all initialisations
are done, it always returns an immediate error with code -28 to all calls.
This new behaviour can be useful for clients to know that a server is already
started and will be available soon (for instance, so that they do not
have to start it themselves).
Improved signing security
For 0.10 the security of signing against unusual attacks has been
improved by making the signatures constant time and deterministic.
This change is a result of switching signing to use libsecp256k1
instead of OpenSSL. Libsecp256k1 is a cryptographic library
optimized for the curve Bitcoin uses which was created by Bitcoin
Core developer Pieter Wuille.
There exist attacks[1] against most ECC implementations where an
attacker on shared virtual machine hardware could extract a private
key if they could cause a target to sign using the same key hundreds
of times. While using shared hosts and reusing keys are inadvisable
for other reasons, it's a better practice to avoid the exposure.
OpenSSL has code in their source repository for derandomization
and reduction in timing leaks that we've eagerly wanted to use for a
long time, but this functionality has still not made its
way into a released version of OpenSSL. Libsecp256k1 achieves
significantly stronger protection: As far as we're aware this is
the only deployed implementation of constant time signing for
the curve Bitcoin uses and we have reason to believe that
libsecp256k1 is better tested and more thoroughly reviewed
than the implementation in OpenSSL.
[1] https://eprint.iacr.org/2014/161.pdf
Watch-only wallet support
The wallet can now track transactions to and from wallets for which you know
all addresses (or scripts), even without the private keys.
This can be used to track payments without needing the private keys online on a
possibly vulnerable system. In addition, it can help for (manual) construction
of multisig transactions where you are only one of the signers.
One new RPC, importaddress, is added which functions similarly to
importprivkey, but instead takes an address or script (in hexadecimal) as
argument. After using it, outputs credited to this address or script are
considered to be received, and transactions consuming these outputs will be
considered to be sent.
The following RPCs have optional support for watch-only:
getbalance, listreceivedbyaddress, listreceivedbyaccount,
listtransactions, listaccounts, listsinceblock, gettransaction. See the
RPC documentation for those methods for more information.
Compared to using getrawtransaction, this mechanism does not require
-txindex, scales better, integrates better with the wallet, and is compatible
with future block chain pruning functionality. It does mean that all relevant
addresses need to added to the wallet before the payment, though.
Consensus library
Starting from 0.10.0, the Bitcoin Core distribution includes a consensus library.
The purpose of this library is to make the verification functionality that is
critical to Bitcoin's consensus available to other applications, e.g. to language
bindings such as [python-bitcoinlib](https://pypi.python.org/pypi/python-bitcoinlib) or
alternative node implementations.
This library is called libbitcoinconsensus.so (or, .dll for Windows).
Its interface is defined in the C header [bitcoinconsensus.h](https://github.com/bitcoin/bitcoin/blob/0.10/src/script/bitcoinconsensus.h).
In its initial version the API includes two functions:
  • bitcoinconsensus_verify_script verifies a script. It returns whether the indicated input of the provided serialized transaction
correctly spends the passed scriptPubKey under additional constraints indicated by flags
  • bitcoinconsensus_version returns the API version, currently at an experimental 0
The functionality is planned to be extended to e.g. UTXO management in upcoming releases, but the interface
for existing methods should remain stable.
Standard script rules relaxed for P2SH addresses
The IsStandard() rules have been almost completely removed for P2SH
redemption scripts, allowing applications to make use of any valid
script type, such as "n-of-m OR y", hash-locked oracle addresses, etc.
While the Bitcoin protocol has always supported these types of script,
actually using them on mainnet has been previously inconvenient as
standard Bitcoin Core nodes wouldn't relay them to miners, nor would
most miners include them in blocks they mined.
bitcoin-tx
It has been observed that many of the RPC functions offered by bitcoind are
"pure functions", and operate independently of the bitcoind wallet. This
included many of the RPC "raw transaction" API functions, such as
createrawtransaction.
bitcoin-tx is a newly introduced command line utility designed to enable easy
manipulation of bitcoin transactions. A summary of its operation may be
obtained via "bitcoin-tx --help" Transactions may be created or signed in a
manner similar to the RPC raw tx API. Transactions may be updated, deleting
inputs or outputs, or appending new inputs and outputs. Custom scripts may be
easily composed using a simple text notation, borrowed from the bitcoin test
suite.
This tool may be used for experimenting with new transaction types, signing
multi-party transactions, and many other uses. Long term, the goal is to
deprecate and remove "pure function" RPC API calls, as those do not require a
server round-trip to execute.
Other utilities "bitcoin-key" and "bitcoin-script" have been proposed, making
key and script operations easily accessible via command line.
Mining and relay policy enhancements
Bitcoin Core's block templates are now for version 3 blocks only, and any mining
software relying on its getblocktemplate must be updated in parallel to use
libblkmaker either version 0.4.2 or any version from 0.5.1 onward.
If you are solo mining, this will affect you the moment you upgrade Bitcoin
Core, which must be done prior to BIP66 achieving its 951/1001 status.
If you are mining with the stratum mining protocol: this does not affect you.
If you are mining with the getblocktemplate protocol to a pool: this will affect
you at the pool operator's discretion, which must be no later than BIP66
achieving its 951/1001 status.
The prioritisetransaction RPC method has been added to enable miners to
manipulate the priority of transactions on an individual basis.
Bitcoin Core now supports BIP 22 long polling, so mining software can be
notified immediately of new templates rather than having to poll periodically.
Support for BIP 23 block proposals is now available in Bitcoin Core's
getblocktemplate method. This enables miners to check the basic validity of
their next block before expending work on it, reducing risks of accidental
hardforks or mining invalid blocks.
Two new options to control mining policy:
  • -datacarrier=0/1 : Relay and mine "data carrier" (OP_RETURN) transactions
if this is 1.
  • -datacarriersize=n : Maximum size, in bytes, we consider acceptable for
"data carrier" outputs.
The relay policy has changed to more properly implement the desired behavior of not
relaying free (or very low fee) transactions unless they have a priority above the
AllowFreeThreshold(), in which case they are relayed subject to the rate limiter.
BIP 66: strict DER encoding for signatures
Bitcoin Core 0.10 implements BIP 66, which introduces block version 3, and a new
consensus rule, which prohibits non-DER signatures. Such transactions have been
non-standard since Bitcoin v0.8.0 (released in February 2013), but were
technically still permitted inside blocks.
This change breaks the dependency on OpenSSL's signature parsing, and is
required if implementations would want to remove all of OpenSSL from the
consensus code.
The same miner-voting mechanism as in BIP 34 is used: when 751 out of a
sequence of 1001 blocks have version number 3 or higher, the new consensus
rule becomes active for those blocks. When 951 out of a sequence of 1001
blocks have version number 3 or higher, it becomes mandatory for all blocks.
Backward compatibility with current mining software is NOT provided, thus miners
should read the first paragraph of "Mining and relay policy enhancements" above.
0.10.0 Change log

Detailed release notes follow. This overview includes changes that affect external
behavior, not code moves, refactors or string updates.
RPC:
  • f923c07 Support IPv6 lookup in bitcoin-cli even when IPv6 only bound on localhost
  • b641c9c Fix addnode "onetry": Connect with OpenNetworkConnection
  • 171ca77 estimatefee / estimatepriority RPC methods
  • b750cf1 Remove cli functionality from bitcoind
  • f6984e8 Add "chain" to getmininginfo, improve help in getblockchaininfo
  • 99ddc6c Add nLocalServices info to RPC getinfo
  • cf0c47b Remove getwork() RPC call
  • 2a72d45 prioritisetransaction
  • e44fea5 Add an option -datacarrier to allow users to disable relaying/mining data carrier transactions
  • 2ec5a3d Prevent easy RPC memory exhaustion attack
  • d4640d7 Added argument to getbalance to include watchonly addresses and fixed errors in balance calculation
  • 83f3543 Added argument to listaccounts to include watchonly addresses
  • 952877e Showing 'involvesWatchonly' property for transactions returned by 'listtransactions' and 'listsinceblock'. It is only appended when the transaction involves a watchonly address
  • d7d5d23 Added argument to listtransactions and listsinceblock to include watchonly addresses
  • f87ba3d added includeWatchonly argument to 'gettransaction' because it affects balance calculation
  • 0fa2f88 added includedWatchonly argument to listreceivedbyaddress/...account
  • 6c37f7f getrawchangeaddress: fail when keypool exhausted and wallet locked
  • ff6a7af getblocktemplate: longpolling support
  • c4a321f Add peerid to getpeerinfo to allow correlation with the logs
  • 1b4568c Add vout to ListTransactions output
  • b33bd7a Implement "getchaintips" RPC command to monitor blockchain forks
  • 733177e Remove size limit in RPC client, keep it in server
  • 6b5b7cb Categorize rpc help overview
  • 6f2c26a Closely track mempool byte total. Add "getmempoolinfo" RPC
  • aa82795 Add detailed network info to getnetworkinfo RPC
  • 01094bd Don't reveal whether password is <20 or >20 characters in RPC
  • 57153d4 rpc: Compute number of confirmations of a block from block height
  • ff36cbe getnetworkinfo: export local node's client sub-version string
  • d14d7de SanitizeString: allow '(' and ')'
  • 31d6390 Fixed setaccount accepting foreign address
  • b5ec5fe update getnetworkinfo help with subversion
  • ad6e601 RPC additions after headers-first
  • 33dfbf5 rpc: Fix leveldb iterator leak, and flush before gettxoutsetinfo
  • 2aa6329 Enable customising node policy for datacarrier data size with a -datacarriersize option
  • f877aaa submitblock: Use a temporary CValidationState to determine accurately the outcome of ProcessBlock
  • e69a587 submitblock: Support for returning specific rejection reasons
  • af82884 Add "warmup mode" for RPC server
  • e2655e0 Add unauthenticated HTTP REST interface to public blockchain data
  • 683dc40 Disable SSLv3 (in favor of TLS) for the RPC client and server
  • 44b4c0d signrawtransaction: validate private key
  • 9765a50 Implement BIP 23 Block Proposal
  • f9de17e Add warning comment to getinfo
Command-line options:
  • ee21912 Use netmasks instead of wildcards for IP address matching
  • deb3572 Add -rpcbind option to allow binding RPC port on a specific interface
  • 96b733e Add -version option to get just the version
  • 1569353 Add -stopafterblockimport option
  • 77cbd46 Let -zapwallettxes recover transaction meta data
  • 1c750db remove -tor compatibility code (only allow -onion)
  • 4aaa017 rework help messages for fee-related options
  • 4278b1d Clarify error message when invalid -rpcallowip
  • 6b407e4 -datadir is now allowed in config files
  • bdd5b58 Add option -sysperms to disable 077 umask (create new files with system default umask)
  • cbe39a3 Add "bitcoin-tx" command line utility and supporting modules
  • dbca89b Trigger -alertnotify if network is upgrading without you
  • ad96e7c Make -reindex cope with out-of-order blocks
  • 16d5194 Skip reindexed blocks individually
  • ec01243 --tracerpc option for regression tests
  • f654f00 Change -genproclimit default to 1
  • 3c77714 Make -proxy set all network types, avoiding a connect leak
  • 57be955 Remove -printblock, -printblocktree, and -printblockindex
  • ad3d208 remove -maxorphanblocks config parameter since it is no longer functional
Block and transaction handling:
  • 7a0e84d ProcessGetData(): abort if a block file is missing from disk
  • 8c93bf4 LoadBlockIndexDB(): Require block db reindex if any blk*.dat files are missing
  • 77339e5 Get rid of the static chainMostWork (optimization)
  • 4e0eed8 Allow ActivateBestChain to release its lock on cs_main
  • 18e7216 Push cs_mains down in ProcessBlock
  • fa126ef Avoid undefined behavior using CFlatData in CScript serialization
  • 7f3b4e9 Relax IsStandard rules for pay-to-script-hash transactions
  • c9a0918 Add a skiplist to the CBlockIndex structure
  • bc42503 Use unordered_map for CCoinsViewCache with salted hash (optimization)
  • d4d3fbd Do not flush the cache after every block outside of IBD (optimization)
  • ad08d0b Bugfix: make CCoinsViewMemPool support pruned entries in underlying cache
  • 5734d4d Only remove actualy failed blocks from setBlockIndexValid
  • d70bc52 Rework block processing benchmark code
  • 714a3e6 Only keep setBlockIndexValid entries that are possible improvements
  • ea100c7 Reduce maximum coinscache size during verification (reduce memory usage)
  • 4fad8e6 Reject transactions with excessive numbers of sigops
  • b0875eb Allow BatchWrite to destroy its input, reducing copying (optimization)
  • 92bb6f2 Bypass reloading blocks from disk (optimization)
  • 2e28031 Perform CVerifyDB on pcoinsdbview instead of pcoinsTip (reduce memory usage)
  • ab15b2e Avoid copying undo data (optimization)
  • 341735e Headers-first synchronization
  • afc32c5 Fix rebuild-chainstate feature and improve its performance
  • e11b2ce Fix large reorgs
  • ed6d1a2 Keep information about all block files in memory
  • a48f2d6 Abstract context-dependent block checking from acceptance
  • 7e615f5 Fixed mempool sync after sending a transaction
  • 51ce901 Improve chainstate/blockindex disk writing policy
  • a206950 Introduce separate flushing modes
  • 9ec75c5 Add a locking mechanism to IsInitialBlockDownload to ensure it never goes from false to true
  • 868d041 Remove coinbase-dependant transactions during reorg
  • 723d12c Remove txn which are invalidated by coinbase maturity during reorg
  • 0cb8763 Check against MANDATORY flags prior to accepting to mempool
  • 8446262 Reject headers that build on an invalid parent
  • 008138c Bugfix: only track UTXO modification after lookup
P2P protocol and network code:
  • f80cffa Do not trigger a DoS ban if SCRIPT_VERIFY_NULLDUMMY fails
  • c30329a Add testnet DNS seed of Alex Kotenko
  • 45a4baf Add testnet DNS seed of Andreas Schildbach
  • f1920e8 Ping automatically every 2 minutes (unconditionally)
  • 806fd19 Allocate receive buffers in on the fly
  • 6ecf3ed Display unknown commands received
  • aa81564 Track peers' available blocks
  • caf6150 Use async name resolving to improve net thread responsiveness
  • 9f4da19 Use pong receive time rather than processing time
  • 0127a9b remove SOCKS4 support from core and GUI, use SOCKS5
  • 40f5cb8 Send rejects and apply DoS scoring for errors in direct block validation
  • dc942e6 Introduce whitelisted peers
  • c994d2e prevent SOCKET leak in BindListenPort()
  • a60120e Add built-in seeds for .onion
  • 60dc8e4 Allow -onlynet=onion to be used
  • 3a56de7 addrman: Do not propagate obviously poor addresses onto the network
  • 6050ab6 netbase: Make SOCKS5 negotiation interruptible
  • 604ee2a Remove tx from AlreadyAskedFor list once we receive it, not when we process it
  • efad808 Avoid reject message feedback loops
  • 71697f9 Separate protocol versioning from clientversion
  • 20a5f61 Don't relay alerts to peers before version negotiation
  • b4ee0bd Introduce preferred download peers
  • 845c86d Do not use third party services for IP detection
  • 12a49ca Limit the number of new addressses to accumulate
  • 35e408f Regard connection failures as attempt for addrman
  • a3a7317 Introduce 10 minute block download timeout
  • 3022e7d Require sufficent priority for relay of free transactions
  • 58fda4d Update seed IPs, based on bitcoin.sipa.be crawler data
  • 18021d0 Remove bitnodes.io from dnsseeds.
Validation:
  • 6fd7ef2 Also switch the (unused) verification code to low-s instead of even-s
  • 584a358 Do merkle root and txid duplicates check simultaneously
  • 217a5c9 When transaction outputs exceed inputs, show the offending amounts so as to aid debugging
  • f74fc9b Print input index when signature validation fails, to aid debugging
  • 6fd59ee script.h: set_vch() should shift a >32 bit value
  • d752ba8 Add SCRIPT_VERIFY_SIGPUSHONLY (BIP62 rule 2) (test only)
  • 698c6ab Add SCRIPT_VERIFY_MINIMALDATA (BIP62 rules 3 and 4) (test only)
  • ab9edbd script: create sane error return codes for script validation and remove logging
  • 219a147 script: check ScriptError values in script tests
  • 0391423 Discourage NOPs reserved for soft-fork upgrades
  • 98b135f Make STRICTENC invalid pubkeys fail the script rather than the opcode
  • 307f7d4 Report script evaluation failures in log and reject messages
  • ace39db consensus: guard against openssl's new strict DER checks
  • 12b7c44 Improve robustness of DER recoding code
  • 76ce5c8 fail immediately on an empty signature
Build system:
  • f25e3ad Fix build in OS X 10.9
  • 65e8ba4 build: Switch to non-recursive make
  • 460b32d build: fix broken boost chrono check on some platforms
  • 9ce0774 build: Fix windows configure when using --with-qt-libdir
  • ea96475 build: Add mention of --disable-wallet to bdb48 error messages
  • 1dec09b depends: add shared dependency builder
  • c101c76 build: Add --with-utils (bitcoin-cli and bitcoin-tx, default=yes). Help string consistency tweaks. Target sanity check fix
  • e432a5f build: add option for reducing exports (v2)
  • 6134b43 Fixing condition 'sabotaging' MSVC build
  • af0bd5e osx: fix signing to make Gatekeeper happy (again)
  • a7d1f03 build: fix dynamic boost check when --with-boost= is used
  • d5fd094 build: fix qt test build when libprotobuf is in a non-standard path
  • 2cf5f16 Add libbitcoinconsensus library
  • 914868a build: add a deterministic dmg signer
  • 2d375fe depends: bump openssl to 1.0.1k
  • b7a4ecc Build: Only check for boost when building code that requires it
Wallet:
  • b33d1f5 Use fee/priority estimates in wallet CreateTransaction
  • 4b7b1bb Sanity checks for estimates
  • c898846 Add support for watch-only addresses
  • d5087d1 Use script matching rather than destination matching for watch-only
  • d88af56 Fee fixes
  • a35b55b Dont run full check every time we decrypt wallet
  • 3a7c348 Fix make_change to not create half-satoshis
  • f606bb9 fix a possible memory leak in CWalletDB::Recover
  • 870da77 fix possible memory leaks in CWallet::EncryptWallet
  • ccca27a Watch-only fixes
  • 9b1627d [Wallet] Reduce minTxFee for transaction creation to 1000 satoshis
  • a53fd41 Deterministic signing
  • 15ad0b5 Apply AreSane() checks to the fees from the network
  • 11855c1 Enforce minRelayTxFee on wallet created tx and add a maxtxfee option
GUI:
  • c21c74b osx: Fix missing dock menu with qt5
  • b90711c Fix Transaction details shows wrong To:
  • 516053c Make links in 'About Bitcoin Core' clickable
  • bdc83e8 Ensure payment request network matches client network
  • 65f78a1 Add GUI view of peer information
  • 06a91d9 VerifyDB progress reporting
  • fe6bff2 Add BerkeleyDB version info to RPCConsole
  • b917555 PeerTableModel: Fix potential deadlock. #4296
  • dff0e3b Improve rpc console history behavior
  • 95a9383 Remove CENT-fee-rule from coin control completely
  • 56b07d2 Allow setting listen via GUI
  • d95ba75 Log messages with type>QtDebugMsg as non-debug
  • 8969828 New status bar Unit Display Control and related changes
  • 674c070 seed OpenSSL PNRG with Windows event data
  • 509f926 Payment request parsing on startup now only changes network if a valid network name is specified
  • acd432b Prevent balloon-spam after rescan
  • 7007402 Implement SI-style (thin space) thoudands separator
  • 91cce17 Use fixed-point arithmetic in amount spinbox
  • bdba2dd Remove an obscure option no-one cares about
  • bd0aa10 Replace the temporary file hack currently used to change Bitcoin-Qt's dock icon (OS X) with a buffer-based solution
  • 94e1b9e Re-work overviewpage UI
  • 8bfdc9a Better looking trayicon
  • b197bf3 disable tray interactions when client model set to 0
  • 1c5f0af Add column Watch-only to transactions list
  • 21f139b Fix tablet crash. closes #4854
  • e84843c Broken addresses on command line no longer trigger testnet
  • a49f11d Change splash screen to normal window
  • 1f9be98 Disable App Nap on OSX 10.9+
  • 27c3e91 Add proxy to options overridden if necessary
  • 4bd1185 Allow "emergency" shutdown during startup
  • d52f072 Don't show wallet options in the preferences menu when running with -disablewallet
  • 6093aa1 Qt: QProgressBar CPU-Issue workaround
  • 0ed9675 [Wallet] Add global boolean whether to send free transactions (default=true)
  • ed3e5e4 [Wallet] Add global boolean whether to pay at least the custom fee (default=true)
  • e7876b2 [Wallet] Prevent user from paying a non-sense fee
  • c1c9d5b Add Smartfee to GUI
  • e0a25c5 Make askpassphrase dialog behave more sanely
  • 94b362d On close of splashscreen interrupt verifyDB
  • b790d13 English translation update
  • 8543b0d Correct tooltip on address book page
Tests:
  • b41e594 Fix script test handling of empty scripts
  • d3a33fc Test CHECKMULTISIG with m == 0 and n == 0
  • 29c1749 Let tx (in)valid tests use any SCRIPT_VERIFY flag
  • 6380180 Add rejection of non-null CHECKMULTISIG dummy values
  • 21bf3d2 Add tests for BoostAsioToCNetAddr
  • b5ad5e7 Add Python test for -rpcbind and -rpcallowip
  • 9ec0306 Add CODESEPARATOFindAndDelete() tests
  • 75ebced Added many rpc wallet tests
  • 0193fb8 Allow multiple regression tests to run at once
  • 92a6220 Hook up sanity checks
  • 3820e01 Extend and move all crypto tests to crypto_tests.cpp
  • 3f9a019 added list/get received by address/ account tests
  • a90689f Remove timing-based signature cache unit test
  • 236982c Add skiplist unit tests
  • f4b00be Add CChain::GetLocator() unit test
  • b45a6e8 Add test for getblocktemplate longpolling
  • cdf305e Set -discover=0 in regtest framework
  • ed02282 additional test for OP_SIZE in script_valid.json
  • 0072d98 script tests: BOOLAND, BOOLOR decode to integer
  • 833ff16 script tests: values that overflow to 0 are true
  • 4cac5db script tests: value with trailing 0x00 is true
  • 89101c6 script test: test case for 5-byte bools
  • d2d9dc0 script tests: add tests for CHECKMULTISIG limits
  • d789386 Add "it works" test for bitcoin-tx
  • df4d61e Add bitcoin-tx tests
  • aa41ac2 Test IsPushOnly() with invalid push
  • 6022b5d Make script_{valid,invalid}.json validation flags configurable
  • 8138cbe Add automatic script test generation, and actual checksig tests
  • ed27e53 Add coins_tests with a large randomized CCoinViewCache test
  • 9df9cf5 Make SCRIPT_VERIFY_STRICTENC compatible with BIP62
  • dcb9846 Extend getchaintips RPC test
  • 554147a Ensure MINIMALDATA invalid tests can only fail one way
  • dfeec18 Test every numeric-accepting opcode for correct handling of the numeric minimal encoding rule
  • 2b62e17 Clearly separate PUSHDATA and numeric argument MINIMALDATA tests
  • 16d78bd Add valid invert of invalid every numeric opcode tests
  • f635269 tests: enable alertnotify test for Windows
  • 7a41614 tests: allow rpc-tests to get filenames for bitcoind and bitcoin-cli from the environment
  • 5122ea7 tests: fix forknotify.py on windows
  • fa7f8cd tests: remove old pull-tester scripts
  • 7667850 tests: replace the old (unused since Travis) tests with new rpc test scripts
  • f4e0aef Do signature-s negation inside the tests
  • 1837987 Optimize -regtest setgenerate block generation
  • 2db4c8a Fix node ranges in the test framework
  • a8b2ce5 regression test only setmocktime RPC call
  • daf03e7 RPC tests: create initial chain with specific timestamps
  • 8656dbb Port/fix txnmall.sh regression test
  • ca81587 Test the exact order of CHECKMULTISIG sig/pubkey evaluation
  • 7357893 Prioritize and display -testsafemode status in UI
  • f321d6b Add key generation/verification to ECC sanity check
  • 132ea9b miner_tests: Disable checkpoints so they don't fail the subsidy-change test
  • bc6cb41 QA RPC tests: Add tests block block proposals
  • f67a9ce Use deterministically generated script tests
  • 11d7a7d [RPC] add rpc-test for http keep-alive (persistent connections)
  • 34318d7 RPC-test based on invalidateblock for mempool coinbase spends
  • 76ec867 Use actually valid transactions for script tests
  • c8589bf Add actual signature tests
  • e2677d7 Fix smartfees test for change to relay policy
  • 263b65e tests: run sanity checks in tests too
Miscellaneous:
  • 122549f Fix incorrect checkpoint data for testnet3
  • 5bd02cf Log used config file to debug.log on startup
  • 68ba85f Updated Debian example bitcoin.conf with config from wiki + removed some cruft and updated comments
  • e5ee8f0 Remove -beta suffix
  • 38405ac Add comment regarding experimental-use service bits
  • be873f6 Issue warning if collecting RandSeed data failed
  • 8ae973c Allocate more space if necessary in RandSeedAddPerfMon
  • 675bcd5 Correct comment for 15-of-15 p2sh script size
  • fda3fed libsecp256k1 integration
  • 2e36866 Show nodeid instead of addresses in log (for anonymity) unless otherwise requested
  • cd01a5e Enable paranoid corruption checks in LevelDB >= 1.16
  • 9365937 Add comment about never updating nTimeOffset past 199 samples
  • 403c1bf contrib: remove getwork-based pyminer (as getwork API call has been removed)
  • 0c3e101 contrib: Added systemd .service file in order to help distributions integrate bitcoind
  • 0a0878d doc: Add new DNSseed policy
  • 2887bff Update coding style and add .clang-format
  • 5cbda4f Changed LevelDB cursors to use scoped pointers to ensure destruction when going out of scope
  • b4a72a7 contrib/linearize: split output files based on new-timestamp-year or max-file-size
  • e982b57 Use explicit fflush() instead of setvbuf()
  • 234bfbf contrib: Add init scripts and docs for Upstart and OpenRC
  • 01c2807 Add warning about the merkle-tree algorithm duplicate txid flaw
  • d6712db Also create pid file in non-daemon mode
  • 772ab0e contrib: use batched JSON-RPC in linarize-hashes (optimization)
  • 7ab4358 Update bash-completion for v0.10
  • 6e6a36c contrib: show pull # in prompt for github-merge script
  • 5b9f842 Upgrade leveldb to 1.18, make chainstate databases compatible between ARM and x86 (issue #2293)
  • 4e7c219 Catch UTXO set read errors and shutdown
  • 867c600 Catch LevelDB errors during flush
  • 06ca065 Fix CScriptID(const CScript& in) in empty script case
Credits

Thanks to everyone who contributed to this release:
  • 21E14
  • Adam Weiss
  • Aitor Pazos
  • Alexander Jeng
  • Alex Morcos
  • Alon Muroch
  • Andreas Schildbach
  • Andrew Poelstra
  • Andy Alness
  • Ashley Holman
  • Benedict Chan
  • Ben Holden-Crowther
  • Bryan Bishop
  • BtcDrak
  • Christian von Roques
  • Clinton Christian
  • Cory Fields
  • Cozz Lovan
  • daniel
  • Daniel Kraft
  • David Hill
  • Derek701
  • dexX7
  • dllud
  • Dominyk Tiller
  • Doug
  • elichai
  • elkingtowa
  • ENikS
  • Eric Shaw
  • Federico Bond
  • Francis GASCHET
  • Gavin Andresen
  • Giuseppe Mazzotta
  • Glenn Willen
  • Gregory Maxwell
  • gubatron
  • HarryWu
  • himynameismartin
  • Huang Le
  • Ian Carroll
  • imharrywu
  • Jameson Lopp
  • Janusz Lenar
  • JaSK
  • Jeff Garzik
  • JL2035
  • Johnathan Corgan
  • Jonas Schnelli
  • jtimon
  • Julian Haight
  • Kamil Domanski
  • kazcw
  • kevin
  • kiwigb
  • Kosta Zertsekel
  • LongShao007
  • Luke Dashjr
  • Mark Friedenbach
  • Mathy Vanvoorden
  • Matt Corallo
  • Matthew Bogosian
  • Micha
  • Michael Ford
  • Mike Hearn
  • mrbandrews
  • mruddy
  • ntrgn
  • Otto Allmendinger
  • paveljanik
  • Pavel Vasin
  • Peter Todd
  • phantomcircuit
  • Philip Kaufmann
  • Pieter Wuille
  • pryds
  • randy-waterhouse
  • R E Broadley
  • Rose Toomey
  • Ross Nicoll
  • Roy Badami
  • Ruben Dario Ponticelli
  • Rune K. Svendsen
  • Ryan X. Charles
  • Saivann
  • sandakersmann
  • SergioDemianLerner
  • shshshsh
  • sinetek
  • Stuart Cardall
  • Suhas Daftuar
  • Tawanda Kembo
  • Teran McKinney
  • tm314159
  • Tom Harding
  • Trevin Hofmann
  • Whit J
  • Wladimir J. van der Laan
  • Yoichi Hirai
  • Zak Wilcox
As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
Also lots of thanks to the bitcoin.org website team David A. Harding and Saivann Carignan.
Wladimir
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007480.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Fungibility Overview by Adam Back and Matt Corallo (Scaling Bitcoin Milan 2016) SF Bitcoin Devs Seminar: The Bitcoin Relay Network SF Bitcoin Devs Seminar: A Special Presentation By Matt Corallo of Blockstream Matt Corallo - Better Hashing Through BetterHash Matt Corallo-DevCore Draper University

Square Crypto, a division of the mobile payments company of the same name co-founded in 2009 by Jack Dorsey, Twitter’s founder recently announced the hiring of Matt Corallo.. Last June, in fact, the company hired its first person to actively contribute to bitcoin. The first member to join the team was Steve Lee, former Google project manager and active bitcoin contributor. Mike Hearn, Matt Corallo Standard Final 38: Applications Passphrase-protected private key Mike Caldwell, Aaron Voisine Standard Draft 39: Applications Mnemonic code for generating deterministic keys Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe Standard Accepted 42: Consensus (soft fork) A finite monetary supply for Bitcoin Pieter Wuille From Bitcoin.com Wiki Jump to: navigation , search BIP: 111 Title: NODE_BLOOM service bit Author: Matt Corallo <[email protected]>, Peter Todd <[email protected]> Status: Draft Type: Standards Track Created: 2015-08-20 Bitcoin original designer Wladimir J. van der Laan Yes No No No No No No Pieter Wuille Yes No No No No No No Gavin Andresen: Retired No No Author No No No Cory Fields Yes No No No No No No Matt Corallo Yes Yes No No No No No Jonas Schnelli Yes No No No No No No Marco Falke Yes No No No No No No Luke Dashjr Yes No Lead No Yes Yes Mark Karpeles aka MagicalTux- Former owner of Mt.Gox and this wiki. Martti Malmi aka Sirius- Former Bitcoin developer. Operates the domain names bitcoin.org and bitcointalk.org. Matt Corallo aka BlueMatt- Satoshi client and Bitcoinj developer. Michael Hendrix aka mndrix- creator of the now defunct CoinPal and CoinCard services

[index] [25309] [1842] [5560] [13740] [31155] [21503] [22708] [25508] [12961] [8469]

Fungibility Overview by Adam Back and Matt Corallo (Scaling Bitcoin Milan 2016)

This feature is not available right now. Please try again later. How to Tell If You're a Bitcoin Wizard - Matt Corallo - Duration: 6:21. CoinDesk 1,474 views. 6:21. Meditations of Marcus Aurelius - SUMMARIZED - (22 Stoic Principles to Live by) ... How to Tell If You're a Bitcoin Wizard - Matt Corallo - Duration: 6:21. CoinDesk 1,434 views. 6:21. BetterHash vs NiceHash vs HoneyMiner vs CudoMiner Profitability - Duration: 7:26. Stratum V2 is next generation protocol for pooled mining in Bitcoin, designed by Slush Pool CEOs Pavel Moravec and Jan Čapek in collaboration with Matt Corallo of Square Crypto and other industry ... Matt Corallo, Bitcoin Developer and Blockstream Co-Founder, spoke about the Bitcoin Relay Network. In his talk, Matt discussed the problems associated with global routing and latency, and how the ...

Flag Counter