Bitcoin Cash mining pool BTC.TOP may be mining

Could it be We Just Need a Way to Veto Amaury? An Idea for Community Governance, Which May Solve Current IFP Too: Introducing The Governance Council

So I was inspired by a recent comment by u/jtoomim running this way:
"Everyone is wrong some of the time. We need a system in which one person being wrong about something doesn't doom us all. [...] In the USA, if the President vetos a bill, it can still be made into law of the Senate and House vote to override the veto with a two-thirds majority. Something like that could be helpful to BCH, too."
I think this is 100% spot on.
We face many challenges with Bitcoin Cash. The good news is we have some caring, amazing talent in this community, giving us the ability to overcome most if not any obstacle. However, our firepower isn't focused. We're far less capable/effective than we might be because of it. The problem is governance. If we can improve governance I think we can improve our chances at success at least ten times.
So I came up with an idea: The Governance Council
The idea behind the GC is giving us a powerful representative body for making community decisions. As the BCH community emerged from the split I think we were too busy putting out fires (cough CSW) to get something like this done. Now, however, I think it's more doable, maybe imperative. Think about how much admiration and respectful consideration we have for people like Roger Ver, Jonald Fyookball, Mark Lundeberg, Jonathan Toomim etc. Now imagine these people have zero official power to stand up against any decision Amaury makes. To be sure, they have political sway. They can publish blog or reddit posts to give people a sense where they stand, and that's something. However, it's not enough. For example, as it stands, because we recognize Amaury as technical decision maker, even if the overall sentiment of the community, including everyone I named, is against the BIP 9 IFP activation by hashpower, it doesn't matter because Amaury has sole recognized tech authority. Miners like Jiang reading/following along, as they said they would do, can only estimate at best what the community wants, and even then may unilaterally decide to go the other way for whatever reason. Worse, as has been mentioned, our fate may be determined by hashpower not even community friendly!
So, again, I think a GC can help. Imagine people as named were elected through a process (which I'll detail a little later what I have in mind), to form a council where their published votes formed a recognized resolution. Now, instead of selling coins, sitting depressed by the screen, debating the efficacy of yet another read.cash article to attempt to influence things as disjointed individuals, the chatter is 'how do you think so and so will vote?' 'when will the council vote?' 'have we had the vote yet?'. Everyone channels their focus to the Council making it far more clear to see, as a community, where we stand, because our individual positions are reflected cumulatively through empowered representatives.
This thing can have teeth too. For example, I foresee 9 seats total, elected annually. There can be a matching multisig address attached. So for a given resolution donated funding can be made available. This means the Council can erect things on its own, such as mining pools and or dev teams etc as needed to, if necessary, combat a rogue or enemy force. There really isn't a limit on what it can do, marketing, you name it. In this way, it can also help the IFP situation, by for example first coming up with a plan that is actually approved, and then if necessary funding it.
What do we think? Good idea? Move forward? I have much more in mind.
Edit: this doesn't eliminate the Lead Developer / Reference Implementation role now filled by Amaury. It works alongside it. This is a Separation of Powers. For example, the president of the United States can't just spend 1 billion dollars. He first asks Congress to approve it, then he spends it. What I have in mind works in a similar way for development. I just didn't go into details (for brevity) yet.
submitted by cryptos4pz to btc [link] [comments]

Could it be We Just Need a Way to Veto Amaury? An Idea for Community Governance, Which May Solve Current IFP Too: Introducing The Governance Council

So I was inspired by a recent comment by u/jtoomim running this way:
"Everyone is wrong some of the time. We need a system in which one person being wrong about something doesn't doom us all. [...] In the USA, if the President vetos a bill, it can still be made into law of the Senate and House vote to override the veto with a two-thirds majority. Something like that could be helpful to BCH, too."
I think this is 100% spot on.
We face many challenges with Bitcoin Cash. The good news is we have some caring, amazing talent in this community, giving us the ability to overcome most if not any obstacle. However, our firepower isn't focused. We're far less capable/effective than we might be because of it. The problem is governance. If we can improve governance I think we can improve our chances at success at least ten times.
So I came up with an idea: The Governance Council
The idea behind the GC is giving us a powerful representative body for making community decisions. As the BCH community emerged from the split I think we were too busy putting out fires (cough CSW) to get something like this done. Now, however, I think it's more doable, maybe imperative. Think about how much admiration and respectful consideration we have for people like Roger Ver, Jonald Fyookball, Mark Lundeberg, Jonathan Toomim etc. Now imagine these people have zero official power to stand up against any decision Amaury makes. To be sure, they have political sway. They can publish blog or reddit posts to give people a sense where they stand, and that's something. However, it's not enough. For example, as it stands, because we recognize Amaury as technical decision maker, even if the overall sentiment of the community, including everyone I named, is against the BIP 9 IFP activation by hashpower, it doesn't matter because Amaury has sole recognized tech authority. Miners like Jiang reading/following along, as they said they would do, can only estimate at best what the community wants, and even then may unilaterally decide to go the other way for whatever reason. Worse, as has been mentioned, our fate may be determined by hashpower not even community friendly!
So, again, I think a GC can help. Imagine people as named were elected through a process (which I'll detail a little later what I have in mind), to form a council where their published votes formed a recognized resolution. Now, instead of selling coins, sitting depressed by the screen, debating the efficacy of yet another read.cash article to attempt to influence things as disjointed individuals, the chatter is 'how do you think so and so will vote?' 'when will the council vote?' 'have we had the vote yet?'. Everyone channels their focus to the Council making it far more clear to see, as a community, where we stand, because our individual positions are reflected cumulatively through empowered representatives.
This thing can have teeth too. For example, I foresee 9 seats total, elected annually. There can be a matching multisig address attached. So for a given resolution donated funding can be made available. This means the Council can erect things on its own, such as mining pools and or dev teams etc as needed to, if necessary, combat a rogue or enemy force. There really isn't a limit on what it can do, marketing, you name it. In this way, it can also help the IFP situation, by for example first coming up with a plan that is actually approved, and then if necessary funding it.
What do we think? Good idea? Move forward? I have much more in mind.
submitted by cryptos4pz to Bitcoincash [link] [comments]

Subreddit Stats: btc top posts from 2019-01-06 to 2020-01-05 11:19 PDT

Period: 363.85 days
Submissions Comments
Total 1000 86748
Rate (per day) 2.75 237.19
Unique Redditors 317 7747
Combined Score 194633 356658

Top Submitters' Top Submissions

  1. 31014 points, 162 submissions: Egon_1
    1. Vitalik Buterin to Core Maxi: “ok bitcoiner” .... (515 points, 206 comments)
    2. These men are serving life without parole in max security prison for nonviolent drug offenses. They helped me through a difficult time in a very dark place. I hope 2019 was their last year locked away from their loved ones. FreeRoss.org/lifers/ Happy New Year. (502 points, 237 comments)
    3. "It’s official Burger King just accepted Bitcoin Cash and GoC token as a payment option in Slovenia." (423 points, 112 comments)
    4. "HOLY SATOSHI! 😱😱 I did it! A smart card that produces valid BitcoinCash signatures. Who would love to pay with a card—to a phone?? Tap took less than a second!👟..." (368 points, 105 comments)
    5. Chrome 'Has Become Surveillance Software. It's Time to Switch' -> Brave to support BCH! (330 points, 97 comments)
    6. Gavin Andresen (2017): "Running a network near 100% capacity is irresponsible engineering... " (316 points, 117 comments)
    7. "Evidently @github has banned all the Iranian users without an ability for them to download their repositories. A service like Github must be a public good and must not be controlled by a centralized entity. Another great example of why we as a society need to make web3 a reality" (314 points, 117 comments)
    8. Roger Ver: "Bitcoin Cash acceptance is coming to thousands of physical shops in Korea" (313 points, 120 comments)
    9. Paul Sztorc: “Will people really spend $70-$700 to open/modify a lightning channel when there's an Altcoin down the street which will process a (USD-denominated) payment for $0.05 ? Many people seem to think yes but honestly I just don't get it” (306 points, 225 comments)
    10. Food For Thought (303 points, 105 comments)
  2. 29021 points, 157 submissions: MemoryDealers
    1. Bitcoin Cash is Lightning Fast! (No editing needed) (436 points, 616 comments)
    2. Brains..... (423 points, 94 comments)
    3. Meanwhile in Hong Kong (409 points, 77 comments)
    4. Ross Ulbricht has served 6 years in federal prison. (382 points, 156 comments)
    5. Just another day at the Bitcoin Cash accepting super market in Slovenia. (369 points, 183 comments)
    6. Why I'm not a fan of the SV community: My recent bill for defending their frivolous lawsuit against open source software developers. (369 points, 207 comments)
    7. History Reminder: (354 points, 245 comments)
    8. It's more decentralized this way. (341 points, 177 comments)
    9. The new Bitcoin Cash wallet is so fast!!!!! (327 points, 197 comments)
    10. The IRS wants to subpoena Apple and Google to see if you have downloaded crypto currency apps. (324 points, 178 comments)
  3. 6909 points, 37 submissions: BitcoinXio
    1. Tim Pool on Twitter: “How the fuck are people justifying creating a world like the one's depicted in Fahrenheit 451 and 1984? You realize that censorship and banning information was a key aspect of the dystopian nightmare right?” (435 points, 75 comments)
    2. The creator of the now famous HODL meme says that the HODL term has been corrupted and doesn’t mean what he intended; also mentions that the purpose of Bitcoin is to spend it and that BTC has lost its value proposition. (394 points, 172 comments)
    3. 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.” (302 points, 66 comments)
    4. Bitfinex caught paying a company to astroturf on social media including Reddit, Twitter, Medium and other platforms (285 points, 86 comments)
    5. WARNING: If you try to use the Lightning Network you are at extremely HIGH RISK of losing funds and is not recommended or safe to do at this time or for the foreseeable future (274 points, 168 comments)
    6. Craig Wright seems to have rage quit Twitter (252 points, 172 comments)
    7. No surprise here: Samson Mow among other BTC maxi trolls harassed people to the point of breakdown (with rape threats, etc) (249 points, 85 comments)
    8. 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.” (228 points, 102 comments)
    9. btc is being targeted and attacked, yet again (220 points, 172 comments)
    10. Brian Armstrong CEO of Coinbase using Bitcoin Cash (BCH) to pay for food, video in tweet (219 points, 66 comments)
  4. 6023 points, 34 submissions: money78
    1. BSV in a nutshell... (274 points, 60 comments)
    2. There is something going on with @Bitcoin twitter account: 1/ The URL of the white paper has been changed from bitcoin.com into bitcoin.org! 2/ @Bitcoin has unfollowed all other BCH related accounts. 3/ Most of the posts that refer to "bitcoin cash" have been deleted?!! Is it hacked again?! (269 points, 312 comments)
    3. "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." (262 points, 130 comments)
    4. 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, 170 comments)
    5. Jonathan Toomim: "BCH will not allow block sizes that are large enough to wreak havoc. We do our capacity engineering before lifting the capacity limits. BCH's limit is 32 MB, which the network can handle. BSV does not share this approach, and raises limits before improving actual capacity." (253 points, 255 comments)
    6. What Bitcoin Cash has accomplished so far 💪 (247 points, 55 comments)
    7. Which one is false advertising and misleading people?! Bitcoin.com or Bitcoin.org (232 points, 90 comments)
    8. A message from Lightning Labs: "Don't put more money on lightning than you're willing to lose!" (216 points, 118 comments)
    9. Silk Road’s Ross Ulbricht thanks Bitcoin Cash’s [BCH] Roger Ver for campaigning for his release (211 points, 29 comments)
    10. This account just donated more than $6600 worth of BCH via @tipprbot to multiple organizations! (205 points, 62 comments)
  5. 4514 points, 22 submissions: unstoppable-cash
    1. Reminder: bitcoin mods removed top post: "The rich don't need Bitcoin. The poor do" (436 points, 89 comments)
    2. Peter R. Rizun: "LN User walks into a bank, says "I need a loan..." (371 points, 152 comments)
    3. It was SO simple... Satoshi had the answer to prevent full-blocks back in 2010! (307 points, 150 comments)
    4. REMINDER: "Bitcoin isn't for people that live on less than $2/day" -Samson Mow, CSO of BlockStream (267 points, 98 comments)
    5. "F'g insane... waited 5 hrs and still not 1 confirmation. How does anyone use BTC over BCH BitcoinCash?" (258 points, 222 comments)
    6. Irony:"Ave person won't be running LN routing node" But CORE/BTC said big-blocks bad since everyone can't run their own node (256 points, 161 comments)
    7. BitPay: "The Wikimedia Foundation had been accepting Bitcoin for several years but recently switched pmt processors to BitPay so they can now accept Bitcoin Cash" (249 points, 61 comments)
    8. FreeTrader: "Decentralization is dependent on widespread usage..." (195 points, 57 comments)
    9. The FLIPPENING: Fiat->OPEN Peer-to-Peer Electronic Cash! Naomi Brockwell earning more via BitBacker than Patreon! (193 points, 12 comments)
    10. LN Commentary from a guy that knows a thing or 2 about Bitcoin (Gavin Andresen-LEAD developer after Satoshi left in 2010) (182 points, 80 comments)
  6. 3075 points, 13 submissions: BeijingBitcoins
    1. Last night's BCH & BTC meetups in Tokyo were both at the same restaurant (Two Dogs). We joined forces for this group photo! (410 points, 166 comments)
    2. Chess.com used to accept Bitcoin payments but, like many other businesses, disabled the option. After some DMs with an admin there, I'm pleased to announce that they now accept Bitcoin Cash! (354 points, 62 comments)
    3. WSJ: Bitfinex Used Tether Reserves to Mask Missing $850 Million, Probe Finds (348 points, 191 comments)
    4. Bitcoiners: Then and Now [MEME CONTEST - details in comments] (323 points, 72 comments)
    5. I'd post this to /Bitcoin but they would just remove it right away (also I'm banned) (320 points, 124 comments)
    6. So this is happening at the big protest in Hong Kong right now (270 points, 45 comments)
    7. /Bitcoin mods are censoring posts that explain why BitPay has to charge an additional fee when accepting BTC payments (219 points, 110 comments)
    8. The guy who won this week's MillionaireMakers drawing has received ~$55 in BCH and ~$30 in BTC. It will cost him less than $0.01 to move the BCH, but $6.16 (20%) in fees to move the BTC. (164 points, 100 comments)
    9. The Bitcoin whitepaper was published 11 years ago today. Check out this comic version of the whitepaper, one of the best "ELI5" explanations out there. (153 points, 12 comments)
    10. Two Years™ is the new 18 Months™ (142 points, 113 comments)
  7. 2899 points, 18 submissions: jessquit
    1. Oh, the horror! (271 points, 99 comments)
    2. A few days ago I caught flak for reposting a set of graphs that didn't have their x-axes correctly labeled or scaled. tvand13 made an updated graph with correct labeling and scaling. I am reposting it as I promised. I invite the viewer to draw their own conclusions. (214 points, 195 comments)
    3. Do you think Bitcoin needs to increase the block size? You're in luck! It already did: Bitcoin BCH. Avoid the upcoming controversial BTC block size debate by trading your broken Bitcoin BTC for upgraded Bitcoin BCH now. (209 points, 194 comments)
    4. Master list of evidence regarding Bitcoin's hijacking and takeover by Blockstream (185 points, 113 comments)
    5. PSA: BTC not working so great? Bitcoin upgraded in 2017. The upgraded Bitcoin is called BCH. There's still time to upgrade! (185 points, 192 comments)
    6. Nobody uses Bitcoin Cash (182 points, 88 comments)
    7. Double-spend proofs, SPV fraud proofs, and Cashfusion improvements all on the same day! 🏅 BCH PLS! 🏅 (165 points, 36 comments)
    8. [repost] a reminder on how btc and Bitcoin Cash came to be (150 points, 102 comments)
    9. Holy shit the entire "negative with gold" sub has become a shrine devoted to the guilded astroturfing going on in rbtc (144 points, 194 comments)
    10. This sub is the only sub in all of Reddit that allows truly uncensored discussion of BTC. If it turns out that most of that uncensored discussion is negative, DON'T BLAME US. (143 points, 205 comments)
  8. 2839 points, 13 submissions: SwedishSalsa
    1. With Bitcoin, for the first time in modern history, we have a way to opt out. (356 points, 100 comments)
    2. In this age of rampant censorship and control, this is why I love Bitcoin. (347 points, 126 comments)
    3. The crypto expert (303 points, 29 comments)
    4. Satoshi reply to Mike Hearn, April 2009. Everybody, especially newcomers and r-bitcoin-readers should take a step back and read this. (284 points, 219 comments)
    5. Bitcoin Cash looking good lately. (235 points, 33 comments)
    6. Roger Ver bad (230 points, 61 comments)
    7. History of the BTC scaling debate (186 points, 54 comments)
    8. MFW i read Luke Jr wants to limit BTC blocks to 300k. (183 points, 116 comments)
    9. Meanwhile over at bitcoinsv... (163 points, 139 comments)
    10. Listen people... (155 points, 16 comments)
  9. 2204 points, 10 submissions: increaseblocks
    1. China bans Bitcoin again, and again, and again (426 points, 56 comments)
    2. China bans Bitcoin (again) (292 points, 35 comments)
    3. Bitcoin Cash Network has now been upgraded! (238 points, 67 comments)
    4. So you want small blocks with high fees to validate your own on chain transactions that happen OFF CHAIN? (212 points, 112 comments)
    5. It’s happening - BTC dev Luke jr writing code to Bitcoin BTC codebase to fork to lower the block size to 300kb! (204 points, 127 comments)
    6. Former BTC maximalist admits that maxi's lied cheated and stealed to get SegWit and Lightning (201 points, 135 comments)
    7. Just 18 more months to go! (172 points, 86 comments)
    8. Bitcoin Cash ring - F*CK BANKS (167 points, 51 comments)
    9. LTC Foundation chat leaked: no evidence of development, lack of transparency (155 points, 83 comments)
    10. A single person controls nearly half of all the Lightning Network’s capacity (137 points, 109 comments)
  10. 2138 points, 12 submissions: JonyRotten
    1. 'Craig Is a Liar' – Early Adopter Proves Ownership of Bitcoin Address Claimed by Craig Wright (309 points, 165 comments)
    2. 200,000 People Have Signed Ross Ulbricht's Clemency Petition (236 points, 102 comments)
    3. Street Artist Hides $1,000 in BTC Inside a Mural Depicting Paris Protests (236 points, 56 comments)
    4. Craig Wright Ordered to Produce a List of Early Bitcoin Addresses in Kleiman Lawsuit (189 points, 66 comments)
    5. Ross Ulbricht Clemency Petition Gathers 250,000 Signatures (163 points, 24 comments)
    6. Ross Ulbricht Letter Questions the Wisdom of Imprisoning Non-Violent Offenders (160 points, 50 comments)
    7. Expert Witness in Satoshi Case Claims Dr Wright's Documents Were Doctored (155 points, 44 comments)
    8. California City Official Uses Bitcoin Cash to Purchase Cannabis (151 points, 36 comments)
    9. Money Transmitter License Not Required for Crypto Businesses in Pennsylvania (141 points, 9 comments)
    10. McAfee to Launch Decentralized Token Exchange With No Restrictions (137 points, 35 comments)

Top Commenters

  1. jessquit (16708 points, 2083 comments)
  2. Ant-n (7878 points, 1517 comments)
  3. MemoryDealers (7366 points, 360 comments)
  4. Egon_1 (6205 points, 1001 comments)
  5. 500239 (5745 points, 735 comments)
  6. BitcoinXio (4640 points, 311 comments)
  7. LovelyDay (4353 points, 457 comments)
  8. chainxor (4293 points, 505 comments)
  9. MobTwo (3420 points, 174 comments)
  10. ShadowOfHarbringer (3388 points, 478 comments)

Top Submissions

  1. The perfect crypto t-shirt by Korben (742 points, 68 comments)
  2. The future of Libra Coin by themadscientistt (722 points, 87 comments)
  3. when you become a crypto trader... by forberniesnow (675 points, 54 comments)
  4. A Reminder Why You Shouldn’t Use Google. by InMyDayTVwasBooks (637 points, 209 comments)
  5. Imagine if in 2000 Apple just sat around all day shit-talking Microsoft. Apple would have never gone anywhere. Apple succeeded because they learned from their mistakes, improved, and got better. BCH should do the same. by guyfawkesfp (552 points, 255 comments)
  6. Bitcoin made The Simpsons intro! Sorry for the potato quality by Johans_wilgat (521 points, 44 comments)
  7. Vitalik Buterin to Core Maxi: “ok bitcoiner” .... by Egon_1 (515 points, 206 comments)
  8. Can't stop won't stop by Greentoboggan (514 points, 78 comments)
  9. These men are serving life without parole in max security prison for nonviolent drug offenses. They helped me through a difficult time in a very dark place. I hope 2019 was their last year locked away from their loved ones. FreeRoss.org/lifers/ Happy New Year. by Egon_1 (502 points, 237 comments)
  10. Blockchain? by unesgt (479 points, 103 comments)

Top Comments

  1. 211 points: fireduck's comment in John Mcafee on the run from IRS Tax Evasion charges, running 2020 Presidential Campaign from Venezuela in Exile
  2. 203 points: WalterRothbard's comment in I am a Bitcoin supporter and developer, and I'm starting to think that Bitcoin Cash could be better, but I have some concerns, is anyone willing to discuss them?
  3. 179 points: Chris_Pacia's comment in The BSV chain has just experienced a 6-block reorg
  4. 163 points: YourBodyIsBCHn's comment in I made this account specifically to tip in nsfw/gonewild subreddits
  5. 161 points: BeijingBitcoins's comment in Last night's BCH & BTC meetups in Tokyo were both at the same restaurant (Two Dogs). We joined forces for this group photo!
  6. 156 points: hawks5999's comment in You can’t make this stuff up. This is how BTC supporters actually think. From bitcoin: “What you can do to make BTC better: check twice if you really need to use it!” 🤦🏻‍♂️
  7. 155 points: lowstrife's comment in Steve Wozniak Sold His Bitcoin at Its Peak $20,000 Valuation
  8. 151 points: kdawgud's comment in The government is taking away basic freedoms we each deserve
  9. 147 points: m4ktub1st's comment in BCH suffered a 51% attack by colluding miners to re-org the chain in order to reverse transactions - why is nobody talking about this? Dangerous precident
  10. 147 points: todu's comment in Why I'm not a fan of the SV community: My recent bill for defending their frivolous lawsuit against open source software developers.
Generated with BBoe's Subreddit Stats
submitted by subreddit_stats to subreddit_stats [link] [comments]

A technical dive into CTOR

Over the last several days I've been looking into detail at numerous aspects of the now infamous CTOR change to that is scheduled for the November hard fork. I'd like to offer a concrete overview of what exactly CTOR is, what the code looks like, how well it works, what the algorithms are, and outlook. If anyone finds the change to be mysterious or unclear, then hopefully this will help them out.
This document is placed into public domain.

What is TTOR? CTOR? AOR?

Currently in Bitcoin Cash, there are many possible ways to order the transactions in a block. There is only a partial ordering requirement in that transactions must be ordered causally -- if a transaction spends an output from another transaction in the same block, then the spending transaction must come after. This is known as the Topological Transaction Ordering Rule (TTOR) since it can be mathematically described as a topological ordering of the graph of transactions held inside the block.
The November 2018 hard fork will change to a Canonical Transaction Ordering Rule (CTOR). This CTOR will enforce that for a given set of transactions in a block, there is only one valid order (hence "canonical"). Any future blocks that deviate from this ordering rule will be deemed invalid. The specific canonical ordering that has been chosen for November is a dictionary ordering (lexicographic) based on the transaction ID. You can see an example of it in this testnet block (explorer here, provided this testnet is still alive). Note that the txids are all in dictionary order, except for the coinbase transaction which always comes first. The precise canonical ordering rule can be described as "coinbase first, then ascending lexicographic order based on txid".
(If you want to have your bitcoin node join this testnet, see the instructions here. Hopefully we can get a public faucet and ElectrumX server running soon, so light wallet users can play with the testnet too.)
Another ordering rule that has been suggested is removing restrictions on ordering (except that the coinbase must come first) -- this is known as the Any Ordering Rule (AOR). There are no serious proposals to switch to AOR but it will be important in the discussions below.

Two changes: removing the old order (TTOR->AOR), and installing a new order (AOR->CTOR)

The proposed November upgrade combines two changes in one step:
  1. Removing the old causal rule: now, a spending transaction can come before the output that it spends from the same block.
  2. Adding a new rule that fixes the ordering of all transactions in the block.
In this document I am going to distinguish these two steps (TTOR->AOR, AOR->CTOR) as I believe it helps to clarify the way different components are affected by the change.

Code changes in Bitcoin ABC

In Bitcoin ABC, several thousand lines of code have been changed from version 0.17.1 to version 0.18.1 (the current version at time of writing). The differences can be viewed here, on github. The vast majority of these changes appear to be various refactorings, code style changes, and so on. The relevant bits of code that deal with the November hard fork activation can be found by searching for "MagneticAnomaly"; the variable magneticanomalyactivationtime sets the time at which the new rules will activate.
The main changes relating to transaction ordering are found in the file src/validation.cpp:
There are other changes as well:

Algorithms

Serial block processing (one thread)

One of the most important steps in validating blocks is updating the unspent transaction outputs (UTXO) set. It is during this process that double spends are detected and invalidated.
The standard way to process a block in bitcoin is to loop through transactions one-by-one, removing spent outputs and then adding new outputs. This straightforward approach requires exact topological order and fails otherwise (therefore it automatically verifies TTOR). In pseudocode:
for tx in transactions: remove_utxos(tx.inputs) add_utxos(tx.outputs) 
Note that modern implementations do not apply these changes immediately, rather, the adds/removes are saved into a commit. After validation is completed, the commit is applied to the UTXO database in batch.
By breaking this into two loops, it becomes possible to update the UTXO set in a way that doesn't care about ordering. This is known as the outputs-then-inputs (OTI) algorithm.
for tx in transactions: add_utxos(tx.outputs) for tx in transactions: remove_utxos(tx.inputs) 
Benchmarks by Jonathan Toomim with Bitcoin ABC, and by myself with ElectrumX, show that the performance penalty of OTI's two loops (as opposed to the one loop version) is negligible.

Concurrent block processing

The UTXO updates actually form a significant fraction of the time needed for block processing. It would be helpful if they could be parallelized.
There are some concurrent algorithms for block validation that require quasi-topological order to function correctly. For example, multiple workers could process the standard loop shown above, starting at the beginning. A worker temporarily pauses if the utxo does not exist yet, since it's possible that another worker will soon create that utxo.
There are issues with such order-sensitive concurrent block processing algorithms:
In contrast, the OTI algorithm's loops are fully parallelizable: the worker threads can operate in an independent manner and touch transactions in any order. Until recently, OTI was thought to be unable to verify TTOR, so one reason to remove TTOR was that it would allow changing to parallel OTI. It turns out however that this is not true: Jonathan Toomim has shown that TTOR enforcement is easily added by recording new UTXOs' indices within-block, and then comparing indices during the remove phase.
In any case, it appears to me that any concurrent validation algorithm would need such additional code to verify that TTOR is being exactly respected; thus for concurrent validation TTOR is a hindrance at best.

Advanced parallel techniques

With Bitcoin Cash blocks scaling to large sizes, it may one day be necessary to scale onto advanced server architectures involving sharding. A lot of discussion has been made over this possibility, but really it is too early to start optimizing for sharding. I would note that at this scale, TTOR is not going to be helpful, and CTOR may or may not lead to performance optimizations.

Block propagation (graphene)

A major bottleneck that exists in Bitcoin Cash today is block propagation. During the stress test, it was noticed that the largest blocks (~20 MB) could take minutes to propagate across the network. This is a serious concern since propagation delays mean increased orphan rates, which in turn complicate the economics and incentives of mining.
'Graphene' is a set reconciliation technique using bloom filters and invertible bloom lookup tables. It drastically reduces the amount of bandwidth required to communicate a block. Unfortunately, the core graphene mechanism does not provide ordering information, and so if many orderings are possible then ordering information needs to be appended. For large blocks, this ordering information makes up the majority of the graphene message.
To reduce the size of ordering information while keeping TTOR, miners could optionally decide to order their transactions in a canonical ordering (Gavin's order, for example) and the graphene protocol could be hard coded so that this kind of special order is transmitted in one byte. This would add a significant technical burden on mining software (to create blocks in such a specific unusual order) as well as graphene (which must detect this order, and be able to reconstruct it). It is not clear to me whether it would be possible to efficiently parallelize sorting algortithms that reconstruct these orderings.
The adoption of CTOR gives an easy solution to all this: there is only one ordering, so no extra ordering information needs to be appended. The ordering is recovered with a comparison sort, which parallelizes better than a topological sort. This should simplify the graphene codebase and it removes the need to start considering supporting various optional ordering encodings.

Reversibility and technical debt

Can the change to CTOR be undone at a later time? Yes and no.
For block validators / block explorers that look over historical blocks, the removal of TTOR will permanently rule out usage of the standard serial processing algorithm. This is not really a problem (aside from the one-time annoyance), since OTI appears to be just as efficient in serial, and it parallelizes well.
For anything that deals with new blocks (like graphene, network protocol, block builders for mining, new block validation), it is not a problem to change the ordering at a later date (to AOR / TTOR or back to CTOR again, or something else). These changes would add no long term technical debt, since they only involve new blocks. For past-block validation it can be retroactively declared that old blocks (older than a few months) have no ordering requirement.

Summary and outlook

Taking a broader view, graphene is not the magic bullet for network propagation. Even with the CTOR-improved graphene, we might not see vastly better performance right away. There is also work needed in the network layer to simply move the messages faster between nodes. In the last stress test, we also saw limitations on mempool performance (tx acceptance and relaying). I hope both of these fronts see optimizations before the next stress test, so that a fresh set of bottlenecks can be revealed.
submitted by markblundeberg to btc [link] [comments]

Some advice for everybody at this point in time

Hi all. I'm taking the liberty to share some hard-won experience at this point in time.

Some advice for Core and supporters

It's easy to feel resentment at this stage, having done so much work and written so much high-quality code, and yet getting a shitstorm for it. When I was leading the Swedish Pirate Party into the European Parliament, I was gradually getting used to getting a barrage of criticism grenades for everything I did and didn't do every single day, starting with when I did or didn't get out of bed in the morning.
It's very hard to explain what this does to your psyche to somebody who hasn't experienced it. Imagine everybody was out to get you, every single day, and giving you high-pitched screaming blame for everything from an orange being round to some Mongolian guy's utter misinterpretation of what you said three years ago.
I'm not exaggerating when I say that people could probably snap and go restraining-shirt-insane for much less.
But the crucial thing when you're in a leadership position like that, getting criticism for absolutely everything, is to maintain your ability to sort the relevant criticism apart from the back seat drivers who make a living out of complaining but not contributing. You've also got to trust your inner compass of the vision you want to accomplish.
From what I can tell, Core has made the common but crucial mistake of isolating itself from the community and taking on an expert attitude toward everybody else in trusting this inner vision compass over external criticism, where Core is somehow right by definition - the development happens as Core wants it, period. This is very dangerous in any open-source / free software project. Other people are just as intelligent and may have considerable experience and ability to evaluate the claims made, and these should - no, must - be taken seriously.
To illustrate just one point, let's take a look at Core's scaling solution here, Segregated Witness.
When I apply my nontrivial experience in coding and systems design - I started coding 37 years ago - I see these two options for scaling bitcoin near-term:
OPTION ONE - Change the blocksize upper limit to two megabytes. One line of code for the constant, about ten LOCs for activation trigger logic. Requires upgrading of a majority server software.
OPTION TWO - Introduce Segwit. About 500 lines of new code, of which at least 100 in the hypersensitive consensus code. Requires upgrading a majority of server software and all client/wallet software and client/wallet hardware, especially those needing to pay money to an arbitrary address (as Segwit introduces a new type of address).
When proponents of Core's scaling tell me that Option Two here is the better because it's safer, and I try to comprehend that statement, I am either utterly insane or the statement is the equivalent of "black is white and up is down". It's just not completely counter to all experience in software engineering risk management, it's so far out it doesn't reflect sunlight anymore.
When I try to understand more and challenge the assertion that option two is safer - on what I must say are very good grounds - I'm told that I should be leaving design to the experts and that I don't understand enough of the complex machine that is bitcoin. I know I am capable of learning complexities, but I am firmly told off from even trying.
That's just not how you succeed in maintaining a community. That's not how you make people want to run your code.
Of course, people are free to run whatever code they like. But the checks and balances in an open source community is simple: if the leadership for a project builds something different from what people want to run, they will run something else. It's therefore in the interest of the leadership to listen to the community to understand what software a majority wants to run. These competing interests provide the checks and balances.
Now, I understand the complexity of block transfer times through the Chinese firewall and that preliminary tests indicate that a typical full node is saturated at a blocksize of 32 megabytes. However, none of these limits will be hit by this particular scaling. Also, when blazing a trail like this, you work one problem at a time, you solve one bottleneck at a time. People have been flagging for the necessity of increasing the blocksize for ... I don't have dates here at hand, but it should be the better part of a year if not more. Further down the road, scaling node throughput capacity can be done in a number of ways from GPUing ECDSA to specialized hardware, but it's not the imminent bottleneck.
When such an enormous amount of crucial data (on the need to raise the blocksize limit) is ignored, that is done at the peril of the project.
People in the bitcoin community are intelligent geeks, capable of inhaling absurd amounts of information and cross-referencing all of it. If you are unable to explain why your solution is better than another proposed solution, people will be utterly dissatisfied with the response "because we are the experts" - for you must assume that other people in the community, in the general case, are at least as intelligent and capable of learning as you are. It's even possible that if you can't explain your solution to an open and intelligent mind, it's not a good solution.

Some advice for Classic and supporters

So it appears the hard fork is happening. A lot of people have fought hard to raise the blocksize limit for a long time, using a variety of means, and it seems to be happening at long last.
Core didn't take the last available opportunity to include a blocksize limit lift in 0.12, but have announced the release candidate without that feature. So this is it, this is when the fork happens or doesn't happen. Right now, based on announced support, the fork appears to be moving forward. A lot of people supporting Classic are feeling a lot of relief, even if people know that this effort is not done until the blocksize trigger has activated on the network. It's far from there at this point - there's not even deployed code. But everything seems to be going the right way.
It's important to reflect on how this is more than a discussion on features. This is an election of what people decide get to decide on the features, direction, quality, and vision moving forward. And as Satoshi declared, there's only one thing determining the outcome of the election: what code is producing the longest chain. That's how bitcoin's democracy works, right there.
This is not a selection of features. It's much bigger than that. It's an election of governance and stewardship into the future.
As in most elections, there has been a lot of animosity - in both directions. As heels have been dug in, ditches turned to trenches, and preferences turned into prestige, people are starting to call out each other and accuse the other side of not working for what's best for bitcoin, and actively naming specific names in negative contexts.
When those in power do this to you, you're feeling everything in the book between resentment, belittling, and outrage. It's easy to do the same thing back. There have even been suggestions that Core is deliberately sabotaging bitcoin to the benefit of ... a selection of actors.
This creates a toxic culture leading up to the election point, where people are afraid to take bitcoin-positive initiatives in anticipation of all the negative attention that follows - for in such an environment, practically all attention will be negative.
It doesn't help that people incumbent in positions of power tend to "do what they must, because they can" in order to safeguard the status quo, however small or insignificant that incumbency is - this includes everything from Theymos' deletion of discussions, via the silly DDoS attacks on XT nodes, to LukeJR's poison pull request to Classic about killing all miner hardware investment. Actions such as these are not really excusable, but they are still human: people tend to do the very human mistake of letting the ends justify the means, with the ends being what they believe is best for the bitcoin network.
Of course, other people disagree of what's best for the bitcoin network, and toxicity follows until the conflict is resolved. And beyond. The toxicity will remain until actively removed by leadership.
It is the responsibility of the winner in any rift to end a toxic animosity culture of hostilities and personal adversarialism. I cannot stress this enough.
History is full of examples where the winners refused to live alongside the losers and rebuild the world together once the conflict was resolved. It never ends well. On the other hand, where the opposite has been true - South Africa's end of segregation with Mandela as president comes to mind as a good example of leadership here - people learn to put animosity behind them.
A lot of people who have submitted code to Core (and previously) are skilled coders, after all, working from their vision. This vision doesn't have to be incompatible with Classic's vision in the slightest - it may just be a matter of slightly different feature priorities, with people intending to get everything in there anyway.
(I'd also therefore like to praise Jonathan Toomim for not engaging in the rifting but focusing on solving the problem to most people's acceptance. Real MVP right there.)

Finally, some personal reflections

Unfortunately, I believe bitcoin development has lost touch with large-scale rollout necessities over the past year or so. At the moment, there are three use cases which all new features should seek to improve:
Remittance. The act of sending money between individuals in different countries.
Drop-in credit card replacement, from the perspectives of both the payer and the merchant (two different use cases). This means that a payment must be instant, easy, and much cheaper than a credit card settlement.
These three use cases must be front left, right, and center when doing any design on the bitcoin network, as far as I'm concerned. They also reinforce each other when funds received by remittance don't have to go via fiat to be used for purchasing something.
If there's no profit to be made in using bitcoin as a drop-in replacement for credit card payments, bitcoin will not be deployed at scale. Deployment and outcompeting legacy systems depend entirely on merchant financial gains from rollout. The story begins and ends with this observation.
That's why I'm concerned when I'm looking at the features of 0.12. I don't see any features targeting one of these three use cases. Fact is, I see at least one feature severely degrading the drop-in capability of credit card replacement - RBF - and the lack of scaling severely jeopardizing, not to say ultimately removing, the profitability in replacing credit cards.
What I see is instead engineering for the sake of engineering. The question of "who's the customer?" seems to have gotten lost in the process. While it's arguable that there's no customer as such in an open source project, there's nevertheless an importance in understanding where the front bowling pins are for a disruptive technology like this - and it's certainly not in the one-time initialization time of starting up a new node. I'd argue that the front bowling pins instead are the three use cases I listed above, and would love to see a stronger focus on tangible use cases moving forward even if people disagree with my choice of cases.
Onward and upward. Bitcoin will recover and move on. Let's learn from this experience.
submitted by Falkvinge 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]

Some advice for everybody at this point in time

Hi all. I'm taking the liberty to share some hard-won experience at this point in time.

Some advice for Classic and supporters

So it appears the hard fork is happening. A lot of people have fought hard to raise the blocksize limit for a long time, using a variety of means, and it seems to be happening at long last.
Core didn't take the last available opportunity to include a blocksize limit lift in 0.12, but have announced the release candidate without that feature. So this is it, this is when the fork happens or doesn't happen. Right now, based on announced support, the fork appears to be moving forward. A lot of people supporting Classic are feeling a lot of relief, even if people know that this effort is not done until the blocksize trigger has activated on the network. It's far from there at this point - there's not even deployed code. But everything seems to be going the right way.
It's important to reflect on how this is more than a discussion on features. This is an election of what people decide get to decide on the features, direction, quality, and vision moving forward. And as Satoshi declared, there's only one thing determining the outcome of the election: what code is producing the longest chain. That's how bitcoin's democracy works, right there.
This is not a selection of features. It's much bigger than that. It's an election of governance and stewardship into the future.
As in most elections, there has been a lot of animosity - in both directions. As heels have been dug in, ditches turned to trenches, and preferences turned into prestige, people are starting to call out each other and accuse the other side of not working for what's best for bitcoin, and actively naming specific names in negative contexts.
When those in power do this to you, you're feeling everything in the book between resentment, belittling, and outrage. It's easy to do the same thing back. There have even been suggestions that Core is deliberately sabotaging bitcoin to the benefit of ... a selection of actors.
This creates a toxic culture leading up to the election point, where people are afraid to take bitcoin-positive initiatives in anticipation of all the negative attention that follows - for in such an environment, practically all attention will be negative.
It doesn't help that people incumbent in positions of power tend to "do what they must, because they can" in order to safeguard the status quo, however small or insignificant that incumbency is - this includes everything from Theymos' deletion of discussions, via the silly DDoS attacks on XT nodes, to LukeJR's poison pull request to Classic about killing all miner hardware investment. Actions such as these are not really excusable, but they are still human: people tend to do the very human mistake of letting the ends justify the means, with the ends being what they believe is best for the bitcoin network.
Of course, other people disagree of what's best for the bitcoin network, and toxicity follows until the conflict is resolved. And beyond. The toxicity will remain until actively removed by leadership.
It is the responsibility of the winner in any rift to end a toxic animosity culture of hostilities and personal adversarialism. I cannot stress this enough.
History is full of examples where the winners refused to live alongside the losers and rebuild the world together once the conflict was resolved. It never ends well. On the other hand, where the opposite has been true - South Africa's end of segregation with Mandela as president comes to mind as a good example of leadership here - people learn to put animosity behind them.
There's a highly-upvoted thread already about keeping the moral high ground in /btc, which makes me happy. However, an effort like the one I'm describing goes beyond not behaving badly. The winning side must actively take responsibility for reconciliation.
A lot of people who have submitted code to Core (and previously) are skilled coders, after all, working from their vision. This vision doesn't have to be incompatible with Classic's vision in the slightest - it may just be a matter of slightly different feature priorities, with people intending to get everything in there anyway.
This assumes, of course, that the hard fork happens. We're not there yet. Do not take success for granted; many projects have fallen on taking success for granted.
(I'd also therefore like to praise Jonathan Toomim for not engaging in the rifting but focusing on solving the problem to most people's acceptance. Real MVP right there.)

Some advice for Core and supporters

It's easy to feel resentment at this stage, having done so much work and written so much high-quality code, and yet getting a shitstorm for it. When I was leading the Swedish Pirate Party into the European Parliament, I was gradually getting used to getting a barrage of criticism grenades for everything I did and didn't do every single day, starting with when I did or didn't get out of bed in the morning.
It's very hard to explain what this does to your psyche to somebody who hasn't experienced it. Imagine everybody was out to get you, every single day, and giving you high-pitched screaming blame for everything from an orange being round to some Mongolian guy's utter misinterpration of what you said three years ago.
I'm not exaggerating when I say that people could probably snap and go restraining-shirt-insane for much less.
But the crucial thing when you're in a leadership position like that, getting criticism for absolutely everything, is to maintain your ability to sort the relevant criticism apart from the back seat drivers who make a living out of complaining but not contributing. You've also got to trust your inner compass of the vision you want to accomplish.
From what I can tell, Core has made the common but crucial mistake of isolating itself from the community and taking on an expert attitude toward everybody else in trusting this inner vision compass over external criticism, where Core is somehow right by definition - the development happens as Core wants it, period. This is very dangerous in any open-source / free software project. Other people are just as intelligent and may have considerable experience and ability to evaluate the claims made, and these should - no, must - be taken seriously.
To illustrate just one point, let's take a look at Core's scaling solution here, Segregated Witness.
When I apply my nontrivial experience in coding and systems design - I started coding 37 years ago - I see these two options for scaling bitcoin near-term:
OPTION ONE - Change the blocksize upper limit to two megabytes. One line of code for the constant, about ten LOCs for activation trigger logic. Requires upgrading of a majority server software.
OPTION TWO - Introduce Segwit. About 500 lines of new code, of which at least 100 in the hypersensitive consensus code. Requires upgrading a majority of server software and all client/wallet software and client/wallet hardware, especially those needing to pay money to an arbitrary address (as Segwit introduces a new type of address that both sender and receiver must handle).
When proponents of Core's scaling tell me that Option Two here is the better because it's safer, and I try to comprehend that statement, I am either utterly insane or the statement is the equivalent of "black is white and up is down". It's just not completely counter to all experience in software engineering risk management, it's so far out it doesn't reflect sunlight anymore.
When I try to understand more and challenge the assertion that option two is safer - on what I must say are very good grounds - I'm told that I should be leaving design to the experts and that I don't understand enough of the complex machine that is bitcoin. I know I am capable of learning complexities, but I am firmly told off from even trying.
That's just not how you succeed in maintaining a community. That's not how you make people want to run your code.
Of course, people are free to run whatever code they like. But the checks and balances in an open source community is simple: if the leadership for a project builds something different from what people want to run, they will run something else. It's therefore in the interest of the leadership to listen to the community to understand what software a majority wants to run. These competing interests provide the checks and balances.
Now, I understand the complexity of block transfer times through the Chinese firewall and that preliminary tests indicate that a typical full node is saturated at a blocksize of 32 megabytes. However, none of these limits will be hit by this particular scaling. Also, when blazing a trail like this, you work one problem at a time, you solve one bottleneck at a time. People have been flagging for the necessity of increasing the blocksize for ... I don't have dates here at hand, but it should be the better part of a year if not more. Further down the road, scaling node throughput capacity can be done in a number of ways from GPUing ECDSA to specialized hardware, but it's not the imminent bottleneck.
When such an enormous amount of crucial data (on the need to raise the blocksize limit) is ignored, that is done at the peril of the project.
People in the bitcoin community are intelligent geeks, capable of inhaling absurd amounts of information and cross-referencing all of it. If you are unable to explain why your solution is better than another proposed solution, people will be utterly dissatisfied with the response "because we are the experts" - for you must assume that other people in the community, in the general case, are at least as intelligent and capable of learning as you are. It's even possible that if you can't explain your solution to an open and intelligent mind, it's not a good solution.

Finally, some personal reflections

Unfortunately, I believe bitcoin development has lost touch with large-scale rollout necessities over the past year or so. At the moment, there are three use cases which all new features should seek to improve:
Remittance. The act of sending money between individuals in different countries.
Drop-in credit card replacement, from the perspectives of both the payer and the merchant (two different use cases). This means that a payment must be instant, easy, and much cheaper than a credit card settlement.
These three use cases must be front left, right, and center when doing any design on the bitcoin network, as far as I'm concerned. They also reinforce each other when funds received by remittance don't have to go via fiat to be used for purchasing something.
If there's no profit to be made in using bitcoin as a drop-in replacement for credit card payments, bitcoin will not be deployed at scale. Deployment and outcompeting legacy systems depend entirely on merchant financial gains from rollout. The story begins and ends with this observation.
That's why I'm concerned when I'm looking at the features of 0.12. I don't see any features targeting one of these three use cases. Fact is, I see at least one feature severely degrading the drop-in capability of credit card replacement - RBF - and the lack of scaling severely jeopardizing, not to say ultimately removing, the profitability in replacing credit cards.
What I see is instead engineering for the sake of engineering. The question of "who's the customer?" seems to have gotten lost in the process. While it's arguable that there's no customer as such in an open source project, there's nevertheless an importance in understanding where the front bowling pins are for a disruptive technology like this - and it's certainly not in the one-time initialization time of starting up a new node. I'd argue that the front bowling pins instead are the three use cases I listed above, and would love to see a stronger focus on tangible use cases moving forward even if people disagree with my choice of cases.
Onward and upward. Bitcoin will recover and move on. Let's learn from this experience.
submitted by Falkvinge to btc [link] [comments]

P2Pool upgrade for segwit compatibility

In order for P2Pool to produce segwit blocks an upgrade is needed. Forrest Voight (forrestv), the P2Pool creator, has been inactive in the project for years so an unofficial upgrade is provided by me:
https://github.com/veqtrus/p2pool/releases/tag/16.1-segwit
GPG public key

Background

In a few days segwit is activating so every mining pool needs to upgrade. This also applies to P2Pool. With P2Pool though being a decentralized mining protocol this is more complex than simply updating your mining software as P2Pool forms its own blockchain, the "sharechain", which is used to track payouts to miners. Any change to how P2Pool works which affects the validity of each share, as is the case with any upgrade to the chain being mined i.e. Bitcoin, requires coordination from the majority of P2Pool miners.
Last year I posted a pull request to the main P2Pool repository with a patch to enable segwit compatibility. After testing on my part the patch was included in the Vertcoin P2Pool and has been working with great success making P2Pool among the largest Vertcoin pools. In fact after P2Pool's rise in popularity a second P2Pool network was introduced for smaller miners.
Meanwhile big block populist Jonathan Toomim (jtoomim) has made a P2Pool fork and increased the share size limit from 50 kB per 30 seconds to 1 MB. While an increase was reasonable and in fact I included one in the segwit patch (to 100 kB) before him the excessive increase on jtoomim's fork is compatible with the BU vision campaigned by him and contradicts the decentralized nature of P2Pool. Now jtoomim has merged my segwit patch and made it a requirement [edit: albeit it can be manually overriden] to use btc1 (segwit2x) misleading users that his fork is a segwit upgrade.
submitted by veqtrus to Bitcoin [link] [comments]

ETC should NOT be trying to distinguish itself with its own dev team, its own roadmap, etc

I am starting to see the ETC make the same mistake that caused Bitcoin Classic to lose support: focusing on differences other than the one which is the entire reason for the project's existence.
People are largely drawn to ETC because they oppose the bailout. They believe ETC is Ethereum, and ETHF is a compromised imitation of the real Ethereum.
The more other junk gets added to the ETC message, the lower the support will be.
If ETC becomes the dominant chain, Vitalik and all the other prominent Ethereum folks will start treating ETC as the real fork. There is no need to create a new dev roadmap. Focusing on differences other than "ETC is the real chain, ETHF is the bailout chain" will just dilute the message.
Once ETC becomes dominant, that is the time for the discussion in the entire Ethereum community to turn to any change in dev direction that the community wants.
I personally am happy with Vitalik and the rest of the devs, except for their decision to support ETHF. If it becomes a matter of me having to support Vitalik and the old devs vs. some ragtag group of devs that come out of the woodwork now, my support for ETC gets significantly weaker. Again, this is a false choice because the ETHF devs will become ETC devs if ETC wins.
Brief history lesson: Bitcoin Classic initially had a lot of support from miners, exchanges, and users for their Core idea: "upgrade the existing Bitcoin network to 2 MB blocks." However, things started going south when the Toomim brothers mistook support for Bitcoin Classic for support for their other ideas about Bitcoin governance and what the dev roadmap should be.
Miners, businesses, and investors looked at Toomim's community voting site to determine the direction of the project, and looked at the people who were leading Classic in a different direction (especially Jonathan's brother, Michael Toomim), and said "No thanks. I like the 2 MB block size idea, but I don't want these people changing all this other stuff."
The ETC community doesn't need to make investors choose between different dev teams. ETC can win this battle by focusing on the fundamental choice of "do you think the bailout chain should be the main chain, or the original chain?"
submitted by go1111111 to EthereumClassic [link] [comments]

Influential Bitcoin Core Developer proposes controversial POW algorithm change..

In an unprecedented move on 1/15/16 Influential Bitcoin Core developer Luke Dashjr proposes a controversial POW algorithm change dubbed:

Bitcoin Core's Luke Dashjr Stating:
This solves mining centralisation[sic] by enabling GPU miners to be the leading-edge again. (Hopefully the next generation of ASIC miners will have learned their lesson, so we don't need to do this again.)
 
In a show of non-support User jcliff quickly states:
NACK. This renders hundreds of millions of dollars worth of equipment useless. It will leave a bad taste in the miners' mouth.
 
Taking the community by surprise, Bitcoin Core's Luke Dashjr entered the realm of Bitcoin Classic's github in order to propose the controversial change, which was quickly shut down:
 
Bitcoin Classic's Jonathan Toomim Stating:
if you think we should change the PoW function, going straight to Github is not the correct method. This is better discussed on Consider.it or reddit or something like that.
Jonathan Toomim later states:
I have unsubscribed from this thread. We will not be changing the PoW function in Classic.
 
Results of the consider.it poll can be found here:
Bitcoin Core's Luke Dashjr's Bitcoin Classic Pull Request can be found here:
 

Classic not interested in a POW algorithm change.

It seems Bitcoin Classic's team is not even remotely interested in changing the POW algorithm choosing instead to honor the very miners who have helped to secure bitcoin for so long. (At least not without large community support and that does not seem likely at this point in time.)
 

Is a POW change in Core's future?

Being that this POW algorithm change proposal came from a Bitcoin Core developer, are we likely to see a bitcoin core POW change attempt in the future?
The question of Bitcoin Core future POW algorithm seems to now be up in the air.
 
Yes, it would be possible to do that. Candidate code is already written.
Eh, Luke-Jr isn't trolling here - he genuinely believes we should discuss this possibility, in part to remind miners that we're all in this together and its much better for everyone if we continue to move forward with consensus. I agree with sipa that his statements may be politically inadvisable, but let's not throw people under the bus for being bad at PR and politics.
 
So not only does it seem the idea of a POW change been discussed between Core developers, the code exists & there seems to be a very likely chance it could get implemented.
 

Story still developing...

 

Edit: Additional Information

 
Provided by u/BitcoinXio:
In the interest of the full timeline, I found some other links to maybe add to your post as well. I find these to be very interesting.
Two days ago: there was this post, which accompanies your nullc post which is a log record of Luke Jr attempting to introduce the PoW algorithm change into Core too https://np.reddit.com/Bitcoin/comments/41vqbo/bitcoindev_pieter_wuillle_its_ridiculous_to/
After the PoW change attempt by Luke-Jr on Classic, which was an obvious troll attempt, some things transpired afterward.
One day ago: this is strange, as rumors begin to swirl about Chinese miners are no longer wanting to support Classic https://np.reddit.com/btc/comments/41zitw/aaron_van_wirdum_on_twitter_confirmed_chinese/
One day ago: then later it's "confirmed" that Chinese miners aren't supporting Classic (but it wasn't all miners, it was just HaoBTC only) https://np.reddit.com/btc/comments/420ydt/f2pool_and_haobtc_confirm_chinese_pools_will/cz6ptaf
Today (1 hour ago!): it seems that four Chinese miners are to have said to support Classic afterall! https://np.reddit.com/btc/comments/42893g/pretend_bitcoin_journalist_aaron_vanderplums_gets/
submitted by SouperNerd to btc [link] [comments]

The Toomin brothers, Bitcoin Classic's main devs are debating Core devs and trying to show them the light. It gets quite fishy at the end.

Join here: http://slack.bitcoincore.org
Start somewhere here: https://bitcoincore.slack.com/archives/general/p1453096627008444
Some extracts:
Michael Toomim [8:06 AM] Satoshi believed the only way to prevent control is to give everyone a copy of the ledger.
[8:06] Give everyone an opportunity to vote.
eric-ledger [8:06 AM] @mtoomim: I think you are delusional
Michael Toomim [8:06 AM] Give everyone an opportunity to transact.
anduck [8:06 AM] mtoomim: bitcoin classic is against that, too.
[8:06] as you very well know.(edited)
Michael Toomim [8:06 AM] We give everyone an opportunity to upgrade the protocol.
Adam Back [8:06 AM] mtoomim: do you understand why the developers of bitcoin used to propose a HF but switched to a SF once it became clear that it was possible because it is safer and faster?
Michael Toomim [8:06 AM] You can take part in bitcoin.
[8:06] You can add yourself to it.
[8:06] Express yourself on consider.it.
anduck [8:06 AM] are you a bot?
Michael Toomim [8:07 AM] Are you a bot?
dts [8:07 AM] I'm convinced, I welcome our new pot smoking master
James Hillard [8:07 AM] @opet: when did I ever refer to you as being part of the uneducated masses?
Michael Toomim [8:07 AM] Do you wanna speak bot? Bleep Bleep Bloop!
[8:07] 1010111
Adam Back [8:07 AM] opet: "it's an image and communication problem." this is agreed
Michael Toomim [8:07 AM] What's your favorite wave? Mine's triangle.
eric-ledger [8:07 AM] you sound like a cultist
anduck [8:07 AM] mtoomim: quit advertising your platform
Michael Toomim [8:07 AM] Haha I'm just stoned guys.
Adam Back [8:07 AM] lol
Michael Toomim [8:07 AM] Cultists do get stoned a lot.
[8:07] But I'm just stoned.
Adam Back [8:07 AM] mtoomim: are you serious?
Michael Toomim [8:07 AM] You're mistaking correlation with causation.
dts [8:07 AM] If any miners are here, please pay attention to @mtoomim words
Michael Toomim [8:07 AM] Yes I'm serious. Do you not believe me? Test me!
anduck [8:08 AM] mtoomim: so how much did you pay the miners? 0 or more
Michael Toomim [8:08 AM] I'd love more attention. I love attention!
[8:08] What? I ​am​ the miner!
[8:08] https://toom.im Toomim Bros. Bitcoin Mining Concern Toomim Bros. provides hosting for bitcoin mining. Our mining center is powered by some of the most wallet- and climate-friendly power in the world.
eric-ledger [8:08 AM] meltdown
anduck [8:08 AM] as stated earlier, it's a valid concern that you may have paid miners. you offered money to other to do things that people have been doing for NO money earlier.
Michael Toomim [8:08 AM] I pay myself every day.
anduck [8:08 AM] @mtoomim: did the miners get paid to express support for Classic or not?
Adam Back [8:08 AM] mtoomim: are you literally stoned? you may want to unplug for a while.
Nicolas Bacca [8:09 AM] At that point I think the best course of action is to demonstrate to the miners that segwit works well with multiple wallets and that well, one team is slightly more serious than the other one.
Michael Toomim [8:09 AM] No they didn't get paid. Duh. The miners have all the money. They are the ones who pay.
dts [8:09 AM] It is legal in Washington State as far as I know
taek [8:09 AM] @mtoomim: you keep trying to flatter us. We don't work for free. We are not impressed with the direction you are taking things and we don't feel inclined to work on your vision. Ours is in the process of being shredded to pieces, why do you think we will maintain morale and motivation?
James Hillard [8:09 AM] I hardly consider a sub MW mining operation to be much of anything at this point.
taek [8:09 AM] ugh
anduck [8:09 AM] mtoomim: thanks
Michael Toomim [8:09 AM] Yeah it's legal here. 1
Colin Delargy [8:09 AM] I don’t think I could think of something more off topic. 1
Michael Toomim [8:09 AM] @taek I don't give the vision. YOU give the vision. Come give it.
[8:09] I just create a place for you to talk and listen.
dts [8:09 AM] @mtoomim: you really aren't doing yourself any favors
Michael Toomim [8:10 AM] I'm hosting the forum.
eric-ledger [8:10 AM] this is insane
p2phash [8:10 AM] funny though
dts [8:10 AM] I hope this is saved for posterity
Adam Back [8:10 AM] mtoomim: i dont think yes. i think you should go sleep it off.
Michael Toomim [8:10 AM] This is great! I love this conversation guys!
eric-ledger [8:10 AM] doe anyone know for sure he is the real Michael Toomim?
Michael Toomim [8:10 AM] You are real fun.
dts [8:10 AM] he verified his email as the same one on Classic Slack
Michael Toomim [8:10 AM] Nobody texted me.
[8:10] :stuck_out_tongue:
gamersg [8:10 AM] mtoomim: If SW via SF increases effective block size to 2MB, why are you pushing for a 2MB HF (honest qsn)
Michael Toomim [8:10 AM] Text me a random code at +++++++++++++
Adam Back [8:11 AM] eric-ledger: oh maybe it's a look alike account.
dts [8:11 AM] why do you have an Oakland number
Michael Toomim [8:11 AM] Because the people who voted aren't pushing for it.
[8:11] I went to school at uc berkeley.
Colin Delargy [8:11 AM] content style matches https://www.reddit.com/usetoomim reddit: the front page of the internet
p2phash [8:11 AM] @gamersg: not a full 2mb of transactions really is it?
anduck [8:11 AM] gamersg: that's been asked like hundred times. he refuses to answer.
taek [8:11 AM] I do feel like I've been properly baited. @mtoomim: my vision is a cryptocurrency that is immune to political influence. That vision does not seem to be present in the current ecosystem
Michael Toomim [8:11 AM] @dts are you nearby?
dts [8:11 AM] that explains the pot
Michael Toomim [8:12 AM] haha Yeah it does.
[8:12] And acid
judahmu [8:12 AM] we liked dts better as luke-jr
dts [8:12 AM] I'm flattered
James Hillard [8:12 AM] Is this what future bitcoin development conversations are going to look like? 1
dts [8:12 AM] Yes he is the real deal, not a troll, kind of unbelievable
James Hillard [8:13 AM] This is insane
oneeman [8:13 AM] tomorrow is a holiday
taek [8:13 AM] :}
dts [8:13 AM] He did go to UC berkeley and slack sends you an email to verify it
oneeman [8:13 AM] as good a day as any to cut loose, I guess
drdave [8:14 AM] joined #general
Adam Back [8:15 AM] are we sure mtoomim is actually michael toomim? wasnt it toomim before?
anduck [8:15 AM] it's michael toomim
[8:15] changed nick to mtoomim
Brian Hoffman [8:15 AM] What a cluster fuck
Michael Toomim [8:15 AM] @taek There are politics in every social system. Our job is to improve them. That's why we made Bitcoin Classic. The problem with politics is that they get in the way, and so make political communication more efficient, so it gets out of the way.
Adam Back [8:16 AM] anduck: well he said that, but what if that itself was a spoof?
anduck [8:16 AM] @adam3us: the email looks legit, at least
Adam Back [8:16 AM] mtoomim: what hashrate does toom.im have?
Michael Toomim [8:16 AM] We are the first forum that can visualize over 1,000 opinions on a single page.
dts [8:16 AM] less than 1%
Michael Toomim [8:16 AM] We scale.
Adam Back [8:16 AM] so email him a code see if he can answer it?
Luke-Jr [8:16 AM] what's the invite link again?
Michael Toomim [8:16 AM] @adam3us: We only have a small amount. Most of our capacity goes to customers who host with us.
Adam Back [8:16 AM] slack.bitcoincore.org
Michael Toomim [8:17 AM] We have 750 kW of power capacity.
dino_m [8:17 AM] joined #general
dts [8:17 AM] @btcdrak: should put it on the front page of bitcoincore.org :confused:
Luke-Jr [8:17 AM] thx. what is the share rules for this link?
dts [8:17 AM] it's posted already on there just hidden behind "contribute"
Luke-Jr [8:17 AM] k, so public
Michael Toomim [8:17 AM] So you can multiply 750 kW by the average efficiency to get the hashrate at our facility.
kang [8:18 AM] joined #general
Michael Toomim [8:18 AM] Text me it's faster.
Patrick Strateman [8:18 AM] @mtoomim: well divide by x and carry the... <1%
oneeman [8:18 AM] someone in ##bitcoin asked a day or two ago if maybe bitcoin classic was just a viral marketing ploy for consider.it ... 2
Michael Toomim [8:18 AM] Probably
anduck [8:19 AM] oneeman: well it certainly looks like so
[8:19] mtoomim has advertised it like 10 times in an hour
oneeman [8:19 AM] I thought the question was a joke, but now I'm not so sure
anduck [8:19 AM] and nobody still cares about it.
Michael Toomim [8:19 AM] And we're all a viral marketing campaign for bitcoin! 2
Patrick Strateman [8:19 AM] @oneeman: lold
Michael Toomim [8:19 AM] Ok what am I not answering now?
anduck [8:19 AM] mtoomim: read the log.
[8:19] please.
Michael Toomim [8:19 AM] Come on!
Adam Back [8:19 AM] mtoomim: nice. yes coincidentally i had looked at your hosting service for some miners i had a while back.
Michael Toomim [8:19 AM] It's so long
[8:19] You talk fast
[8:20] I've responded very well to everything I've been able to tackle
anduck [8:20 AM] you're already deeming others to do the btc deving work for you, don't make us read the logs you should read(edited)
Michael Toomim [8:20 AM] I want you to choose
[8:20] There are a lot of options up there
Patrick Strateman [8:20 AM] @mtoomim: Would you be OK with a world in which virtually all Bitcoin users run SPV clients and only a handful of trusted third parties operate full nodes?
alie1 [8:20 AM] joined #general
Michael Toomim [8:20 AM] You get power, you can choose what I talk about!
[8:20] Good question!
[8:21] Ok, so I need to answer this well. Give me these numbers:
  1. The percent of SPV clients
  2. The number of full nodes
[8:21] I'll give you my opinion.
James Hillard [8:21 AM] toomims hosting service is small peanuts in the scheme of things, I manage multiple MW scale large farms in multiple countries and even then have only about 1% of network hashpower
Michael Toomim [8:21 AM] Good job James!
[8:21] Congratulations!
epscy [8:22 AM] joined #general
Michael Toomim [8:22 AM] Hey can someone get Greg Maxwell? I love that guy!
Patrick Strateman [8:22 AM] @mtoomim: 100 full nodes run by say blockstream, coinbase, mit, etc etc everybody else runs spv clients
Michael Toomim [8:22 AM] I want him to work with Classic!
Adam Back [8:22 AM] mtoomim: i sent you an email to auth your slack handle here
dts [8:22 AM] yeah verify
Adam Back [8:22 AM] can you paste or type the code in
dts [8:23 AM] otherwise bravo on excellent trolling
taek [8:23 AM] @phantomcircuit: I don't think conversation with mtoomim is going to go anywhere.
Michael Toomim [8:23 AM] uploaded an image: Cool! Add Comment
dts [8:23 AM] it's listed as his email in the classic slack
Adam Back [8:23 AM] ok then. that's pretty confirmed.
Michael Toomim [8:23 AM] Fuck yeah it is!
Oliver [8:23 AM] @jameshilliard you inadvertently did so when you referred to those voting on consider.it and supporting Classic as the "uneducated masses."
After all, I didn't give up my anonymity and finally get involved with bitcoin dev in any way until Classic arrived on the scene.
There are many more exactly like me who have signed up to finally have our voices heard and votes counted. Some, like me, are incredibly sick of (and saddened) by the Core devs' seeming ignorance of the fact that it's NOT ok to completely ignore the wants of the community.
I'm here now, and I'm here to help. My greatest desire is to somehow help bring Core and Classic together with a compromise. I'd like to see collaboration and an understanding that the road map requires a lot more than Core's blessing.(edited)
Michael Toomim [8:23 AM] That's like, real!
[8:23] It'd be so hard for me to photoshop that in 50 seconds
[8:24] Photoshop sucks
[8:24] I can do better in omnigraffle
[8:24] and built-in OSX screenshotting
[8:24] @phantomcircuit: That scenario is fucked up, dude! Everybody runs an SPV client? Sounds like fucking fascist china man!
Luke-Jr [8:24 AM] considering how quickly my PR for Classic was shot down without discussion...
frankenmint [8:24 AM] joined #general
Michael Toomim [8:25 AM] I lived in china for 6 months man, it wasn't pretty with the government
[8:25] I'm so glad the chinese are finding freedom with bitcoin
eric-ledger [8:25 AM] @mtoomim: You should come back when you are not stoned; you are not helping yourself 3
Michael Toomim [8:25 AM] They need it!
Luke-Jr [8:25 AM] lol
dts [8:25 AM] uploaded an image: Here is his email listed in classic slack Add Comment Michael Toomim [8:25 AM] @eric-ledger: I'm loving this conversation!
[8:25] I'm here to help you guys!
eric-ledger [8:25 AM] well I do also love it
James Hillard [8:25 AM] @opet: I didn't mean to imply that everyone voting on there is uneducated.
Michael Toomim [8:25 AM] I want to make it easier to dev bitcoin!
eric-ledger [8:25 AM] but it may come back and bite you in the ass
Michael Toomim [8:26 AM] Haha
[8:26] That would be fun!
[8:26] Like a snake.
Patrick Strateman [8:26 AM] @mtoomim: Do you not realize that scenario is exactly the one you're moving towards with classic?
Michael Toomim [8:26 AM] Woah! No I don't!
[8:26] Please tell me how that's happening!
[8:26] How are we going to force everyone to use SPV clients?
[8:27] That means that we have to force people not to run a full node.
[8:27] Right now it's pretty easy to run a full node.
[8:27] I run one on this laptop.
[8:27] My laptop's only getting bigger and better every year.
[8:27] And the democracy cares about this!
[8:27] They won't let full nodes stop running on their laptops.
elliotolds [8:27 AM] @opet: what do you think as this (proposed earlier by someone else here) for a compromise: in April we hard fork to 2 MB, then we do segwit later in the year, maybe October or something, but whenever Core is comfortable releasing it? (sooner is fine, even along with the April HF is OK if they want it then)
Michael Toomim [8:27 AM] They want full nodes to run on their laptops!
[8:27] They want it so bad!
Patrick Strateman [8:27 AM] @mtoomim: so four or five tabs? 4
Michael Toomim [8:27 AM] I want it so bad!
[8:27] I love bitcoin on my laptop!
[8:28] It's like a girlfriend in your lap!
[8:28] Isn't it?
eric-ledger [8:28 AM] omg
Michael Toomim [8:28 AM] Who wants to relegate her to the server room?
dinbits [8:28 AM]
I'm here to help you guys! @mtoomim: Do you plan on saying anything helpful?(edited)
Michael Toomim [8:28 AM] That's for herems.
[8:28] I support sexual equality!
[8:28] @dinbits I want to be helpful! What would you like me to help you with?
jdebunt [8:28 AM] joined #general
Michael Toomim [8:28 AM] Or help other people with?
dts [8:29 AM] what he's saying is very illuminating to me 3
Michael Toomim [8:29 AM] @phantomcircuit: I once took 4 tabs and went free-diving off the coast of hawaii.
[8:29] Kapoho tide pools on the big island
[8:29] That was so great!
[8:29] I saw fish world.
[8:29] Like the clan of the little cute white fish with the red stripe that swish you left and right.
[8:29] I came up speaking in a new style. 1 1
justino [8:30 AM] joined #general
Michael Toomim [8:30 AM] Every once in a while my words would disiintegrate into strange snap crackle popping, the sounds of fish world.
[8:30] I called it a flubbergust.
[8:30] It is the moment where your spirit veers into void and disappears.
[8:30] It's when you are wrong.
[8:30] In Bitcoin, we have a problem of admitting when we're wrong.
[8:30] Because there's no data on it.
elliotolds [8:30 AM] I wonder if this is some sort of Machiavellian plot, and later Jonathan will come in here and seem like the most reasonable person in the world in comparison 3
Michael Toomim [8:30 AM] We're giving you social data.
[8:30] bitcoin.consider.it
Nathan Cook [8:30 AM] shh, this is great
Michael Toomim [8:30 AM] It tells you when you're right and wrong
[8:31] So that you can learn
[8:31] When you learn, you get better
[8:31] And you get shit done
[8:31] You can make changes to bitcoin
dts [8:31 AM] I still can't quite believe it's you even with the proof
Michael Toomim [8:31 AM] We are hardforking the blocksize limit to 2mb
[8:31] Join us.
anduck [8:31 AM] why not 6 mb?
Adam Back [8:31 AM] i think it's him
anduck [8:31 AM] it would allow more transactions
Michael Toomim [8:31 AM] @dts wanna video chat me?
Nicolas Bacca [8:31 AM] is there drug for everybody ?
dts [8:31 AM] like my mind can't make the two parts fit together
eric-ledger [8:31 AM] a selfie maybe?
Michael Toomim [8:31 AM] Guys come meet me in tawk.space. I'll be online in 5 minutes.
taek [8:31 AM] Things have gotten terribly off topic, I would like to request that people stop responding to the nonsense, and also stop encouraging it. There is more valuable conversation that is being blocked by the ridiculousness happening right now.
Michael Toomim [8:32 AM] That's https://tawk.space. Use chrome or go home.
dts [8:32 AM] let's rename this chat mtoomim's magical bus trip and make a new channel 4
kang [8:32 AM] Not before that selfie plz
Michael Toomim [8:33 AM] hahaha
jake7849 [8:33 AM] joined #general
alie1 [8:33 AM] is this a joke ?
jwade [8:34 AM] joined #general
Michael Toomim [8:34 AM] Fuck! Tawk.space is down! Karthik!!!!!!!!
[8:34] Can we make a group video chat in skype?
[8:34] Oh a hangout
submitted by bahatassafus to btc [link] [comments]

BlockTorrent: The famous algorithm which BitTorrent uses for SHARING BIG FILES. Which you probably thought Bitcoin *also* uses for SHARING NEW BLOCKS (which are also getting kinda BIG). But Bitcoin *doesn't* torrent *new* blocks (while relaying). It only torrents *old* blocks (while sync-ing). Why?

This post is being provided to further disseminate an existing proposal:
This proposal was originally presented by jtoomim back in September of 2015 - on the bitcoin_dev mailing list (full text at the end of this OP), and on reddit:
https://np.reddit.com/btc/comments/3zo72i/fyi_ujtoomim_is_working_on_a_scaling_proposal/cyomgj3
Here's a TL;DR, in his words:
BlockTorrenting
For initial block sync, [Bitcoin] sort of works [like BitTorrent] already.
You download a different block from each peer. That's fine.
However, a mechanism does not currently exist for downloading a portion of each [new] block from a different peer.
That's what I want to add.
~ jtoomim
The more detailed version of this "BlockTorrenting" proposal (as presented by jtoomim on the bitcoin_dev mailing list) is linked and copied / reformatted at the end of this OP.
Meanwhile here are some observations from me as a concerned member of the Bitcoin-using public.
Questions:
Whoa??
WTF???
Bitcoin doesn't do this kind of "blocktorrenting" already??
But.. But... I thought Bitcoin was "p2p" and "based on BitTorrent"...
... because (as we all know) Bitcoin has to download giant files.
Oh...
Bitcoin only "torrents" when sharing one certain kind of really big file: the existing blockchain, when a node is being initialized.
But Bitcoin doesn't "torrent" when sharing another certain kind of moderately big file (a file whose size, by the way, has been notoriously and steadily growing over the years to the point where the system running the legacy "Core"/Blockstream Bitcoin implementation is starting to become dangerously congested - no matter what some delusional clowns "Core" devs may say): ie, the world's most wildly popular, industrial-strength "p2p file sharing algorithm" is mysteriously not being used where the Bitcoin network needs it the most in order to get transactions confirmed on-chain: when a a newly found block needs to be shared among nodes, when a node is relaying new blocks.
https://np.reddit.com/Bitcoin+bitcoinxt+bitcoin_uncensored+btc+bitcoin_classic/search?q=blocktorrent&restrict_sr=on
How many of you (honestly) just simply assumed that this algorithm was already being used in Bitcoin - since we've all been told that "Bitcoin is p2p, like BitTorrent"?
As it turns out - the only part of Bitcoin which has been p2p up until now is the "sync-ing a new full-node" part.
The "running an existing full-node" part of Bitcoin has never been implemented as truly "p2p2" yet!!!1!!!
And this is precisely the part of the system that we've been wasting all of our time (and destroying the community) fighting over for the past few months - because the so-called "experts" from the legacy "Core"/Blockstream Bitcoin implementation ignored this proposal!
Why?
Why have all the so-called "experts" at "Core"/Blockstream ignored this obvious well-known effective & popular & tested & successful algorithm for doing "blocktorrenting" to torrent each new block being relayed?
Why have the "Core"/Blockstream devs failed to p2p-ize the most central, fundamental networking aspect of Bitcoin - the part where blocks get propagated, the part we've been fighting about for the past few years?
This algorithm for "torrenting" a big file in parallel from peers is the very definition of "p2p".
It "surgically" attacks the whole problem of sharing big files in the most elegant and efficient way possible: right at the lowest level of the bottleneck itself, cleverly chunking a file and uploading it in parallel to multiple peers.
Everyone knows torrenting works. Why isn't Bitcoin using it for its new blocks?
As millions of torrenters already know (but evidently all the so-called "experts" at Core/Blocsktream seem to have conveniently forgotten), "torrenting" a file (breaking a file into chunks and then offering a different chunk to each peer to "get it out to everyone fast" - before your particular node even has the entire file) is such a well-known / feasible / obvious / accepted / battle-tested / highly efficient algorithm for "parallelizing" (and thereby significantly accelerating) the sharing of big files among peers, that many people simply assumed that Bitcoin had already been doing this kind of "torrenting of new-blocks" these whole past 7 years.
But Bitcoin doesn't do this - yet!
None of the Core/Blockstream devs (and the Chinese miners who follow them) have prioritized p2p-izing the most central and most vital and most resource-consuming function of the Bitcoin network - the propagation of new blocks!
Maybe it took someone who's both a miner and a dev to "scratch" this particular "itch": Jonathan Toomim jtoomim.
  • A miner + dev who gets very little attention / respect from the Core/Blockstream devs (and from the Chinese miners who follow them) - perhaps because they feel threatened by a competing implementation?
  • A miner + dev who may have come up with the simplest and safest and most effective algorithmic (ie, software-based, not hardware-consuming) scaling proposal of anyone!
  • A dev who who is not paid by Blockstream, and who is therefore free from the secret, undisclosed corporate restraints / confidentiality agreements imposed by the shadowy fiat venture-capitalists and legacy power elite who appear to be attempting to cripple our code and muzzle our devs.
  • A miner who has the dignity not to let himself be forced into signing a loyalty oath to any corporate overlords after being locked in a room until 3 AM.
Precisely because jtoomim is both a indepdendent miner and an independent dev...
  • He knows what needs to be done.
  • He knows how to do it.
  • He is free to go ahead and do it - in a permissionless, decentralized fashion.
Possible bonus: The "blocktorrent" algorithm would help the most in the upload direction - which is precisely where Bitcoin scaling needs the most help!
Consider the "upload" direction for a relatively slow full-node - such as Luke-Jr, who reports that his internet is so slow, he has not been able to run a full-node since mid-2015.
The upload direction is the direction which everyone says has been the biggest problem with Bitcoin - because, in order for a full-node to be "useful" to the network:
  • it has to able to upload a new block to (at least) 8 peers,
  • which places (at least) 8x more "demand" on the full-node's upload bandwidth.
The brilliant, simple proposed "blocktorrent" algorithm from jtoomim (already proven to work with Bram Cohen's BitTorrent protocol, and also already proven to work for initial sync-ing of Bitcoin full-nodes - but still un-implemented for ongoing relaying among full-nodes) looks like it would provide a significant performance improvement precisely at this tightest "bottleneck" in the system, the crucial central nexus where most of the "traffic" (and the congestion) is happening: the relaying of new blocks from "slower" full-nodes.
The detailed explanation for how this helps "slower" nodes when uploading, is as follows.
Say you are a "slower" node.
You need to send a new block out to (at least) 8 peers - but your "upload" bandwidth is really slow.
If you were to split the file into (at least) 8 "chunks", and then upload a different one of these (at least) 8 "chunks" to each of your (at least) 8 peers - then (if you were using "blocktorrenting") it only would take you 1/8 (or less) of the "normal" time to do this (compared to the naïve legacy "Core" algorithm).
Now the new block which your "slower" node was attempting to upload is already "out there" - in 1/8 (or less) of the "normal" time compared to the naïve legacy "Core" algorithm.[ 1 ]
... [ 1 ] There will of course also be a tiny amount of extra overhead involved due to the "housekeeping" performed by the "blocktorrent" algorithm itself - involving some additional processing and communicating to decompose the block into chunks and to organize the relaying of different chunks to different peers and the recompose the chunks into a block again (all of which, depending on the size of the block and the latency of your node's connections to its peers, would in most cases be negligible compared to the much-greater speed-up provided by the "blocktorrent" algorithm itself).
Now that your block is "out there" at those 8 (or more) peer nodes to whom you just blocktorrented it in 1/8 (or less) of the time - it has now been liberated from the "bottleneck" of your "slower" node.
In fact, its further propagation across the net may now be able to leverage much faster upload speeds from some other node(s) which have "blocktorrent"-downloaded it in pieces from you (and other peers) - and which might be faster relaying it along, than your "slower" node.
For some mysterious reason, the legacy Bitcoin implementation from "Core"/Blockstream has not been doing this kind of "blocktorrenting" for new blocks.
It's only been doing this torrenting for old blocks. The blocks that have already been confirmed.
Which is fine.
But we also obviously need this sort of "torrenting" to be done for each new block is currently being confirmed.
And this is where the entire friggin' "scaling bottleneck" is occurring, which we just wasted the past few years "debating" about.
Just sit down and think about this for a minute.
We've had all these so-called "experts" (Core/Blockstream devs and other small-block proponents) telling us for years that guys like Hearn and Gavin and repos like Classic and XT and BU were "wrong" or at least "unserious" because they "merely" proposed "brute-force" scaling: ie, scaling which would simply place more demands on finite resources (specifically: on the upload bandwidth from full-nodes - who need to relay to at least 8 peer full-nodes in order to be considered "useful" to the network).
These "experts" have been beating us over the head this whole time, telling us that we have to figure out some (really complicated, unproven, inefficient and centralized) clever scaling algorithms to squeeze more efficiency out of existing infrastructure.
And here is the most well-known / feasible / obvious / accepted / battle-tested algorithm for "parallelizing" (and thereby massively accelerating) the sharing of big file among peers - the BitTorrent algorithm itself, the gold standard of p2p relaying par excellence, which has been a major success on the Internet for decades, at one point accounting for nearly 1/3 of all traffic on the Internet itself - and which is also already being used in one part of Bitcoin: during the phase of sync-ing a new node.
And apparently pretty much only jtoomim has been talking about using it for the actual relaying of new blocks - while Core/Blockstream devs have so far basically ignored this simple and safe and efficient proposal.
And then the small-block sycophants (reddit users or wannabe C/C++ programmers who have beaten into submission and/or by the FUD and "technological pessimism" of the Core/Blockstream devs, and by the censorhip on their legacy forum), they all "laugh" at Classic and proclaim "Bitcoin doesn't need another dev team - all the 'experts' are at Core / Blockstream"...
...when in fact it actually looks like jtoomim (an independent minedev, free from the propaganda and secret details of the corporate agenda of Core/Blockstream - who works on the Classic Bitcoin implementation) may have proposed the simplest and safest and most effective scaling algorithm in this whole debate.
By the way, his proposal estimates that we could get about 1 magnitude greater throughput, based on the typical latency and blocksize for blocks of around 20 MB and bandwidth of around 8 Mbps (which seems like a pretty normal scenario).
So why the fuck isn't this being done yet?
This is such a well-known / feasible / obvious / accepted / battle-tested algorithm for "parallelizing" (and thereby significantly accelerating) the sharing of big files among peers:
  • It's already being used for the (currently) 65 gigabytes of "blocks in the existing blockchain" itself - the phase where a new node has to sync with the blockchain.
  • It's already being used in BitTorrent - although the BitTorrent protocol has been optimized more to maximize throughput, whereas it would probably be a good idea to optimize the BlockTorrent protocol to minimize latency (since avoiding orphans is the big issue here) - which I'm fairly sure should be quite doable.
This algorithm is so trivial / obvious / straightforward / feasible / well-known / proven that I (and probably many others) simply assumed that Bitcoin had been doing this all along!
But it has never been implemented.
There is however finally a post about it today on the score-hidden forum /Bitcoin, from eragmus:
[bitcoin-dev] BlockTorrent: Torrent-style new-block propagation on Merkle trees
https://np.reddit.com/Bitcoin/comments/484nbx/bitcoindev_blocktorrent_torrentstyle_newblock/
And, predictably, the top-voted comment there is a comment telling us why it will never work.
And the comment after that comment is from the author of the proposal, jtoomim, explaining why it would work.
Score hidden on all those comments.
Because the immature tyrant theymos still doesn't understand the inherent advantages of people using reddit's upvoting & downvoting tools to hold decentralized, permissionless debates online.
Whatever.
Questions:
(1) Would this "BlockTorrenting" algorithm from jtoomim really work?
(2) If so, why hasn't it been implemented yet?
(3) Specifically: With all the "dev firepower" (and $76 million in venture capital) available at Core/Blockstream, why have they not prioritized implementing this simple and safe and highly effective solution?
(4) Even more specifically: Are there undisclosed strategies / agreements / restraints imposed by Blockstream financial investors on Bitcoin "Core" devs which have been preventing further discussion and eventual implementation of this possible simple & safe & efficient scaling solution?
Here is the more-detailed version of this proposal, presented by Jonathan Toomim jtoomim back in September of 2015 on the bitcoin-dev mailing list (and pretty much ignored for months by almost all the "experts" there):
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe011176.html
As I understand it, the current block propagation algorithm is this:
  1. A node mines a block.
  2. It notifies its peers that it has a new block with an inv. Typical nodes have 8 peers.
  3. The peers respond that they have not seen it, and request the block with getdata [hash].
  4. The node sends out the block in parallel to all 8 peers simultaneously. If the node's upstream bandwidth is limiting, then all peers will receive most of the block before any peer receives all of the block. The block is sent out as the small header followed by a list of transactions.
  5. Once a peer completes the download, it verifies the block, then enters step 2.
(If I'm missing anything, please let me know.)
The main problem with this algorithm is that it requires a peer to have the full block before it does any uploading to other peers in the p2p mesh. This slows down block propagation to:
O( p • log_p(n) ) 
where:
  • n is the number of peers in the mesh,
  • p is the number of peers transmitted to simultaneously.
It's like the Napster era of file-sharing. We can do much better than this.
Bittorrent can be an example for us.
Bittorrent splits the file to be shared into a bunch of chunks, and hashes each chunk.
Downloaders (leeches) grab the list of hashes, then start requesting their peers for the chunks out-of-order.
As each leech completes a chunk and verifies it against the hash, it begins to share those chunks with other leeches.
Total propagation time for large files can be approximately equal to the transmission time for an FTP upload.
Sometimes it's significantly slower, but often it's actually faster due to less bottlenecking on a single connection and better resistance to packet/connection loss.
(This could be relevant for crossing the Chinese border, since the Great Firewall tends to produce random packet loss, especially on encrypted connections.)
Bitcoin uses a data structure for transactions with hashes built-in. We can use that in lieu of Bittorrent's file chunks.
A Bittorrent-inspired algorithm might be something like this:
  1. (Optional steps to build a Merkle cache; described later)
  2. A seed node mines a block.
  3. It notifies its peers that it has a new block with an extended version of inv.
  4. The leech peers request the block header.
  5. The seed sends the block header. The leech code path splits into two.
  6. (a) The leeches verify the block header, including the PoW. If the header is valid,
  7. (a) They notify their peers that they have a header for an unverified new block with an extended version of inv, looping back to 2. above. If it is invalid, they abort thread (b).
  8. (b) The leeches request the Nth row (from the root) of the transaction Merkle tree, where N might typically be between 2 and 10. That corresponds to about 1/4th to 1/1024th of the transactions. The leeches also request a bitfield indicating which of the Merkle nodes the seed has leaves for. The seed supplies this (0xFFFF...).
  9. (b) The leeches calculate all parent node hashes in the Merkle tree, and verify that the root hash is as described in the header.
  10. The leeches search their Merkle hash cache to see if they have the leaves (transaction hashes and/or transactions) for that node already.
  11. The leeches send a bitfield request to the node indicating which Merkle nodes they want the leaves for.
  12. The seed responds by sending leaves (either txn hashes or full transactions, depending on benchmark results) to the leeches in whatever order it decides is optimal for the network.
  13. The leeches verify that the leaves hash into the ancestor node hashes that they already have.
  14. The leeches begin sharing leaves with each other.
  15. If the leaves are txn hashes, they check their cache for the actual transactions. If they are missing it, they request the txns with a getdata, or all of the txns they're missing (as a list) with a few batch getdatas.
Features and benefits
The main feature of this algorithm is that a leech will begin to upload chunks of data as soon as it gets them and confirms both PoW and hash/data integrity instead of waiting for a fully copy with full verification.
Inefficient cases, and mitigations
This algorithm is more complicated than the existing algorithm, and won't always be better in performance.
Because more round trip messages are required for negotiating the Merkle tree transfers, it will perform worse in situations where the bandwidth to ping latency ratio is high relative to the blocksize.
Specifically, the minimum per-hop latency will likely be higher.
This might be mitigated by reducing the number of round-trip messages needed to set up the BlockTorrent by using larger and more complex inv-like and getdata-like messages that preemptively send some data (e.g. block headers).
This would trade off latency for bandwidth overhead from larger duplicated inv messages.
Depending on implementation quality, the latency for the smallest block size might be the same between algorithms, or it might be 300% higher for the torrent algorithm.
For small blocks (perhaps < 100 kB), the BlockTorrent algorithm will likely be slightly slower.
Sidebar from the OP: So maybe this would discourage certain miners (cough Dow cough) from mining blocks that aren't full enough:
Why is [BTCC] limiting their block size to under 750 all of a sudden?
https://np.reddit.com/Bitcoin/comments/486o1u/why_is_bttc_limiting_their_block_size_to_unde

For large blocks (e.g. 8 MB over 20 Mbps), I expect the BlockTorrent algo will likely be around an order of magnitude faster in the worst case (adversarial) scenarios, in which none of the block's transactions are in the caches.

One of the big benefits of the BlockTorrent algorithm is that it provides several obvious and straightforward points for bandwidth saving and optimization by caching transactions and reconstructing the transaction order.

Future work: possible further optimizations
A cooperating miner [could] pre-announce Merkle subtrees with some of the transactions they are planning on including in the final block.
Other miners who see those subtrees [could] compare the transactions in those subtrees to the transaction sets they are mining with, and can rearrange their block prototypes to use the same subtrees as much as possible.
In the case of public pools supporting the getblocktemplate protocol, it might be possible to build Merkle subtree caches without the pool's help by having one or more nodes just scraping their getblocktemplate results.
Even if some transactions are inserted or deleted, it [might] be possible to guess a lot of the tree based on the previous ordering.
Once a block header and the first few rows of the Merkle tree [had] been published, they [would] propagate through the whole network, at which time full nodes might even be able to guess parts of the tree by searching through their txn and Merkle node/subtree caches.
That might be fun to think about, but probably not effective due to O( n2 ) or worse scaling with transaction count.
Might be able to make it work if the whole network cooperates on it, but there are probably more important things to do.
Leveraging other features from BitTorrent
There are also a few other features of Bittorrent that would be useful here, like:
  • prioritizing uploads to different peers based on their upload capacity,
  • banning peers that submit data that doesn't hash to the right value.
Sidebar from the OP: Hmm...maybe that would be one way to deal with the DDoS-ing we're experiencing right now? I know the DDoSer is using a rotating list of proxies, but still it could be a quick-and-dirty way to mitigate against his attack.
DDoS started again. Have a nice day, guys :)
https://np.reddit.com/Bitcoin_Classic/comments/47zglz/ddos_started_again_have_a_nice_day_guys/d0gj13y
(It might be good if we could get Bram Cohen to help with the implementation.)
Using the existing BitTorrent algorithm as-is - versus tailoring a new algorithm optimized for Bitcoin
Another possible option would be to just treat the block as a file and literally Bittorrent it.
But I think that there should be enough benefits to integrating it with the existing bitcoin p2p connections and also with using bitcoind's transaction caches and Merkle tree caches to make a native implementation worthwhile.
Also, BitTorrent itself was designed to optimize more for bandwidth than for latency, so we will have slightly different goals and tradeoffs during implementation.
Concerns, possible attacks, mitigations, related work
One of the concerns that I initially had about this idea was that it would involve nodes forwarding unverified block data to other nodes.
At first, I thought this might be useful for a rogue miner or node who wanted to quickly waste the whole network's bandwidth.
However, in order to perform this attack, the rogue needs to construct a valid header with a valid PoW, but use a set of transactions that renders the block as a whole invalid in a manner that is difficult to detect without full verification.
However, it will be difficult to design such an attack so that the damage in bandwidth used has a greater value than the 240 exahashes (and 25.1 BTC opportunity cost) associated with creating a valid header.
Related work: IBLT (Invertible Bloom Lookup Tables)
As I understand it, the O(1) IBLT approach requires that blocks follow strict rules (yet to be fully defined) about the transaction ordering.
If these are not followed, then it turns into sending a list of txn hashes, and separately ensuring that all of the txns in the new block are already in the recipient's mempool.
When mempools are very dissimilar, the IBLT approach performance degrades heavily and performance becomes worse than simply sending the raw block.
This could occur if a node just joined the network, during chain reorgs, or due to malicious selfish miners.
Also, if the mempool has a lot more transactions than are included in the block, the false positive rate for detecting whether a transaction already exists in another node's mempool might get high for otherwise reasonable bucket counts/sizes.
With the BlockTorrent approach, the focus is on transmitting the list of hashes in a manner that propagates as quickly as possible while still allowing methods for reducing the total bandwidth needed.
Remark
The BlockTorrent algorithm does not really address how the actual transaction data will be obtained because, once the leech has the list of txn hashes, the standard Bitcoin p2p protocol can supply them in a parallelized and decentralized manner.
Thoughts?
-jtoomim
submitted by ydtm to btc [link] [comments]

[Free Bitcoin Step by Step Guide] BigPoolSearcher Bitcoin Miner - Mine for bitcoin with personal PC BITCOIN GENERATOR FREE BITCOIN MINER 2020 100% LEGIT BITCOIN MONEY ADD BITCOIN AND ETHEREUM Miner Heat Exhaust System Bitcoin Mining freezer GPU rigs THE COOLEST BITCOIN MINE

Jonathan Toomim - Bitcoin Miner Original Poster 9 points · 1 month ago Here is the list of all blocks since 613500 that took more than 1 hour to mine (according to their timestamps), what the exact delay was (in seconds), and whether they were mined by BTC.top. According to Bitcoin miner Jonathan Toomim, mining BTC is around 10% more profitable during these BCH ‘dry spells’ and BTC.TOP has been mining at a loss to reduce these long validation times. His estimates suggest that they have lost around $16,400 already and are en route to losing $20,000 this month. Miner and programmer Jonathan Toomim has announced a new block propagation program he’s been working on recently. Toomim first discussed his new concept called Xthinner this past September, in order to exemplify the advantages of the Bitcoin Cash network’s lexical transaction ordering system often referred to as LTOR. Miner and programmer Jonathan Toomim has announced a new block propagation program he’s been working on recently. Toomim first discussed his new concept called Xthinner this past September, in order to exemplify the advantages of the Bitcoin Cash network’s lexical transaction ordering system often referred to as LTOR. Jonathan Toomim - Bitcoin Miner 33 points · 6 days ago · edited 5 days ago Interestingly, from the analysis one proposal from ABC (cw-16-sha) for fixing the issue of resonances. It does so by modifying the current DAA (cw-144) to use a randomized window based on the current block hash.

[index] [14653] [12769] [3320] [7242] [7914] [347] [3554] [141] [10552] [3276]

[Free Bitcoin Step by Step Guide] BigPoolSearcher Bitcoin Miner - Mine for bitcoin with personal PC

BBT Episode 10: 6x R9 280x TOXIC Mining Rig! Over 4.6 M/hash Litecoin, Dogecoin unleashed! - Duration: 12:21. Bits Be Trippin' 444,398 views Toomim Bros. Bitcoin Mining Concern uploaded a video 3 years ago 6:36. ZCash GPU cloud mining at Toomim Bros - Duration: 6 minutes, 36 seconds. Toomim Bros. Bitcoin Mining Concern. Toomim Bros. Bitcoin Mining Concern 16,702 views. ... How to set UP BITCOIN Mining BY BITMAIN Antminer L3+ For Best Air Circulation - Duration: 3:22. Crypto BROS. 146,895 views. Jonathan Toomim Karol Trzeszczkowski Bitcoin Cash Coffeehouse is a new series that brings together developers and other members in the community for thoughtful discussion in order to figure out ... Toomim Bros. Bitcoin Mining Concern 16,568 views. 7:43. Total IDIOTS at Ships - Ship Fail Compilation #2 Commentary - Duration: 10:02. MrWinning Fun Recommended for you. 10:02.