op+

2/18/13
How a floating blocksize limit inevitably leads towards centralization
https://bitcointalk.org/index.php?topic=144895.0

1/14/16
Why Bitcoin's Decentralization Matters
http://bluematt.bitcoin.ninja/2016/01/14/decentralization/

2/22/16
Coinbase CEO Rejects Proposal for Bitcoin Hard Fork in 2017
http://www.coindesk.com/coinbase-ceo-rejects-bitcoin-hard-fork/

2/23/16
Bitcoin Roundtable Consensus: Wladimir Says ‘I’m All For It’
http://coinjournal.net/bitcoin-roundtable-consensus-wladimir-says-im/

We need some entries for Oct/Nov/Dec 2015!

The "weaker side" is the one getting pwnd by DDoS attacks voting.  

It used to be called XT, but they have now rebranded to Classic.  Same shit, different pile.

Stating well-known facts about Honey Badger isn't "endorsing" anything.

But don't let that stand in the way of your quest to make this all about *me* (ie personalize the debate) instead of the real issues at hand.

Core will not "fall."  Classic will be #R3KT like Stannis at Winterfell.  

https://www.reddit.com/r/btc/comments/47f0b0/f2pool_testing_classic/

It might be down though.  Honey Badger can get a little defensive when somebody tries to steal his honey.

Replace the battery in your sarcasm detector.  I am mocking the Gavinista hypocrisy of selective outrage:

"Classic isn't an attack on Core.  Classic miners' blocks are merely voting to attack at a time in the future when they may have power sufficient to endanger Bitcoin's critical consensus.  If Evil Adam Back and Kim Jong-theymos don't like it, they can DIAF."

Where is the part of the roadmap where people stop using FakeClassic and pretending using FakeClassic is the same as using NotFakeClassic?


No pool will sacrifice the competitive advantages of 0.12 (faster sig_ops and block construction, etc.) for the political feel-good BS of Classic.

"Hay look guize, f2pool mined another FakeClassic block using Core!  Let's all advertise and celebrate the impotency of the Gavinista governance coup!"  - Olivier Janssens, probably

It's not an "attack."  Core supporters are merely voting with their packets.

If that happens to disturb f2pool's existing datagram consensus with a more contentious version, well too bad.

Majoritarian Democracy > Nork Sensor Ships

These are 100% legitimate concerns and questions.

Why can't we get some real answers from (whatever is left of) Team SDC, instead of deflection in the form of attacking the messenger?



IKR?  You should see what's happening in the NXT Civil War.  JL777 had a Hearnia and pulled a whiny rage quit.  Which just happens to be the perfect excuse to abandon his dozens of incomplete projects.

Then there's the bawling at /r/btc over the fact that Honey Badger is not a punching bag and will fight back when attacked.

Popcorn supplies are running dangerously low.   At this level of drama, nobody will notice when Game of Thrones comes back!   

Pleasant like LibertAryan copyright troll and sock-puppetmaster Olivier Janssens?

Last year the XT pushers told us


If Classic can't shrug off a few silly script kiddies and their flimsy DDoS attacks, why does it deserve to replace Core?

https://github.com/bitcoinclassic/documentation/blob/master/roadmap/technical2016.md

Technical TODO for scaling up

    Implement parallel validation of blocks. Currently Core does block validation one block at a time (the cs_main lock is held during validation). Allowing blocks to be validated in parallel means a slower-to-validate block is more likely to lose the "block race" to a faster-to-validate block.

    Implement "headers-first" mining. As soon as a valid 80-byte block header that extends the most-work chain is received, relay the header (via a new p2p network message) and allow mining an empty block on top of it, for up to 20 seconds. When it is fully validated, mine a normal block. If a faster-to-validate block that extends the most-work chain is received and validated first (see parallel validation, above), mine on top of the faster-to-validate block. If full block data has not been received within a reasonable number of seconds (e.g. 30 seconds), fall back to mining on the last fully-validated block.

The combination of parallel validation and headers-first mining eliminates the effect of block size on orphan rates.

Permanent scaling solution:

    Variation on Stephen Pair/BitPay's idea for a new consensus rule: validation cost (CPU+bandwidth+UTXO storage) for blocks in current 2016-block-difficulty adjustment period must be less than a small multiple of the average validation cost of the last difficulty adjustment period.
    Transaction selection is modified to optimize bitcoins-per-validation-cost (large or CPU-expensive or bloat-the-UTXO-set transactions cost more).
    Incorporate segregated witness work from Core (assuming it is ready), but no special discount for segwit transactions to keep fee calculation and economics simple.

Optimizations that will be applied on top for bandwidth-constrained nodes:

    Bandwidth optimizations implemented as new p2p protocol messages to avoid re-sending redundant 'inv' messages, re-sending transaction data in 'tx' and 'block' messages.
    Use UDP instead of TCP for messages that don't need reliability (e.g. transaction 'inv' messages, block header)

Development Priorities will always be:

    Security first and foremost. Secure coding principles will be followed, as described at https://www.securecoding.cert.org/. An explicit threat model will be defined and used to evaluate risks.
    Reliability/predictability always second.
    A pleasant development community. Life it too short to work with unpleasant people.
    Changes will be restricted to bug fixes that address security or reliability, or a short list of high-priority new features or changes for the current release cycle. Developers are expected to spend more time reviewing each other's code than writing new code.

https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md#bitcoin-classic-2016-roadmap

Note: This is our initial roadmap proposal. We will run this by miners, companies and users for feedback, before it is finalized.


Bitcoin Classic 2016 Roadmap

The Bitcoin Classic team will help realize Satoshi’s vision of making Bitcoin scale into a global peer to peer cash system, and not just a settlement network. We believe on-chain scaling is crucial for the long term health of Bitcoin. On-chain scaling maximizes transaction volume, whose fees are needed to replace miner rewards on the medium to long term scale.

Our preferred strategy for on-chain scaling, is to eliminate the need for blocks to be synced within seconds. We will implement solutions that make continuous block syncing possible. Instead of transmitting the data for a new block all at once when it is found, we can significantly optimize current bandwidth by sending data during the full ten-minute interval between blocks. This will enable the Bitcoin network to scale to significant new levels, without endangering decentralization. We will scale using a 3-pronged approach:
Phase 1 (Q1-Q2)
Urgently resolve issue of blocks being almost full

    Implement BIP 109: Raise block size limit from 1MB to 2MB.
    Hard fork with 75% activation threshold (750 of 1000 blocks), 28 day activation grace period.
    Software based on Bitcoin Core implementation 0.11.2 and 0.12.0.

Note: 0.11.2 is already finished and available for download here.
Phase 2 (Q2-Q3)
Eliminate the need for blocks to be sent within seconds

    Reduce the effect of block propagation times on orphan rates (lost miner income)
    De-emphasize block size as an obstacle for scaling and open up potential for on-chain transaction throughput gains using several improvements (listed below).
    Optimizations for bandwidth constrained nodes via improvements to the P2P layer

Note: We intend to discuss various solutions such as the ones listed below and pick the best ones.

    Parallel validation of blocks (theoretically reduces the profitability of excessive-sized block attacks).
    Headers-first mining (largely nullifies excessive-sized block attacks).
    Thin blocks: Blocks refer to transactions that have been well propagated rather than including them, allowing for minimization of bandwidth use.
    Weak blocks: allow miners to pre-announce the blocks they are working on, to minimize the data sent once a block is found.
    Validate Once: Transactions that have been validated when entering a node’s memory pool do not need to be revalidated when included in a block (speeds up block validation).

Phase 3 (Q3-Q4)
Make the block size limit dynamic

Note: This phase will only happen when miners & companies confirm Phase 2 successfully addressed their blocksize concerns.

    Use a variation of Steven Pair’s/BitPay proposal. Validation cost of a block must be less than a small multiple of the average cost over the last difficulty adjustment period
    Simplified version of Segregated Witness from Core, when it is available

Technical details

A more technical version of the roadmap can be found here
Conference

We plan to hold an on-chain scaling conference soon, where these and future scaling solutions & concerns can be discussed among the community.

Honey Badger doesn't need to rip your face off if you tickle him.  That's just how he rolls.

Write his obituary if it makes you feel better about delicate snowflake Classic's utter lack of antifragility.  He doesn't really give a damn.

Scumbag tactics?  You mean like attempting to force a contentious hard fork at a 75/25 split with only 28 days warning, while using FUD as a thin wedge to insert a governance coup?

Don't cry to me when you poke the Honey Badger and he rips your face off.  You knew that was bound to happen.  Remember XT?  LAAAWL!

Let's make a soda machine.  Oh wait, that was already done.

How about coffee mugs?  Hmm, tried that too.

Well I'm stumped.

Only ~30 Masternodes worth of Dash between Here and Zero.

Remember when you guys believed the price was going to stay above 0.01?  Aww, sweet memories!

Honey badger's characteristic ferocity creates disincentives to attack him.

As for your happy talk and gross generalizations about the broad category of DDoS attacks, whether or they they are "countered easily" depends on their scale.

By now you should know the Core Defense Network and small block militia have demonstrated capacity sufficient to take down entire ISPs and data centers for hours or days.

The fact macbook is here disclosing the attack indicates it is not trivial.  I forget, did they ever get stratum working through Cloudflare?

Let's see how breezily you gloss over 500Gbps of energized particle beam when La Serenissima's orbiting battle stations have you in their crosshairs.   

Fixed it for you.

Mess with the honey badger and you get the claws.  Plus the teeth.

Only 30 Masternodes to ~zero.  Creates quite a large incentive to be the first to liquidate Masternodes and dump the Dash while you still can.

Anyone lending their coins for less than 0.1% should feel very very stupid right about now.  I hope they enjoy their dust while those of use with a spine collect real money.