I dunno where this april thing came from, but segwit was pull requested on April 19th.  Deployment waits somewhat on continued review (which is very actively ongoing-- though it would likely be faster if a single person from one of the companies saying we urgently needed capacity increases contributed) and to a lesser extent on the activation of the BIP 68/112/113 softfork. (It's possible to have multiple softforks running in parallel now with BIP9, but I think most people would prefer to not have the extra dynamics for the very first BIP9 softfork.)

It's worth pointing out that although btcd has a segwit implementation, Bitcoin "classic" and XT have taken no preparatory action here (and haven't even caught up to BIP-68 or BIP-9). Though these implementations don't have any real widespread use AFAICT, it's preferable to not just leave them behind.

You're looking at a not very useful metric: The only reason blocks are _ever_ not the maximum size now is because miners voluntarily cut the size to improve propagation or to avoid mining DOS attack transactions. It's much more interesting to look at the feerate for moderately fast confirmation (e.g. 4 or less confirms), which has been pretty stable over time.

Pedantically, this is not correct. They validate many things about them-- locktimes, spend consistency, prevention of double spending, fees, non-inflation.  The only thing they don't validate is segwit signatures.  However, they also also drop and ignore segwit txn unless they're in blocks-- they won't relay them, or mine them, or show them as unconfirmed transactions in wallets.  Non-upgraded nodes also know something is going on about that they don't understand and will tell the user, and if you wanted to set yours up to shut down until you upgrade it to be segwit aware you could-- though it would be an unusual thing to do.  (Except "Bitcoin Classic"-- they just started ripping out the notification logic because it was telling users they were out of sync due to CSV's pending activation-- rather than just integrating this long coming, well understood, simple script addition that we already wrote for them...)

The same non-checking of the new thing but still checking the old stuff was is true for CSV which will activate soon, it was true for CLTV, it was true for P2SH, it was true for nlocktime by block-height back when Bitcoin's creator added that.  This particular upgrade mechanism is an intentional part of Bitcoin's design with specific affordances in the transaction structure and script system.  It's one that has been used many times in the past without trouble via a process which has evolved and matured in response to experience (in the above listed changes as well as a number of additional ones).

Before and when segwit activates your nodes will tell you (unless you're running the most recent "Classic" software...), at that point you can figure out what you want to do.

The obvious thing to do is to upgrade-- but you don't have to: things will continue to work and if you are already requiring multiple confirmations to consider transactions confirmed or primarily sending funds it's hard to argue that your security would be in meaningfully degraded. If you'd like to upgrade but you are running customized or un(der)maintained software (like Bitcoin "Classic", or one of the many abandoned full node implementations) you can get the full security effect of upgrading by setting up an upgraded node and then -connect-ing  your non-upgraded node to it.  This means that you can upgrade on your on terms, when it fits your schedule, and in a way that minimizes costs and disruption to your activities.  It means that, if you want and/or your process requires it, you'll have all the time you need to have new software audited to your requirements or to forward port and test your customization.   Of course, you'll likely just upgrade-- as it's easy to do, and after doing so you can get the benefits of using segwit yourself but when and how you upgrade is up to you and on your terms. And that is really how it has to be: We can't build a system who's value proposition begins with personal freedom and autonomy with a system maintained through coercive synchronous forced upgrades.
 
This is an effect that was reasonably expected in 2011/2012 which has been thoroughly debunked by experience. The user count has grown astronomically while the node count has declined pretty much right along with the increase in the initial sync time.  More users means more nodes, but not when running a node makes your systems obviously slower, chews up enough bandwidth to run you into data caps, and takes a week to sync up. In Core we've been working frantically for years slamming out performance improvements to try to use optimization to compensate for load increases to protect decentralization.


Segwit increases capacity, but does so in a way that can eat less into those factors than a simple blocksize increase-- because it is a true scalablity improvement-- and it sets the stage for further efficiency increases down the road. Today even many big name bitcoin businesses outsource their node operations to centralized APIs, and this was something that no one working on Bitcoin really anticipated in 2011.

Franky1-- So, you're saying that you are not going to complain to "classic" about behavior a million fold riskier than what you're complaining about in Core that exists in all other full node software?

And we're supposed to continue to believe your concerns are sincere? Oookkay.

Meanwhile you continue to flood this thread with things you fake-disagree with (as evidenced by not caring about classic doing something far worse) to push off the list of scalability improvements in segwit where you can't find anything to distort into a fault.

Keep in mind that this thread is about "Bitcoin Classic"-- if that isn't what you want to talk about, your posts are offtopic.

This is, after all, the "classic" thread-- so, I guess since your concerns are so sincere and neutral I should be expecting to see you open an issue on the classic github to tell them that disabling validation on blocks claimed to be a day old is bad and they should undo it?


Nice ninja edit there.  No-- Classic turns off validation based on a timestamp set by the miners. Core and every other full node other there skip signature checking on blocks below a hardcoded block 100,000 deep in the chain (a behavior, added by Gavin in 2011, which-- incidentally-- i argued against, but is now one of the things keeping the initial sync time tolerable on low power devices).  In any case, your dispute there is with every existing full node software, not Core. (And at least in core you can disable that behavior by setting checkpoints=0).  

I hope you can see the difference between not checking things in a chain with months of POW on top of it vs not checking when miners simply say so in block headers.

All you can see is random distortions that confirm your world view.  Clue up: You know that your Bitcoin Classic now doesn't check any signatures at all on blocks where the miner-provided timestamp in the header is a day old?   If you're concerned about these details you should be rallying against "classic".

I gave you a long list of ways that segwit improves actual scalablity and all you can do is focus on skipping validation WHICH EVERY SINGLE EXISTING FULL NODE ALREADY SKIPS and on the _option_ of a possible new mode that still protects against inflation and the users own transactions which someone could use when their alternative is to NOT RUN A NODE AT ALL. And you suggest that it's reducing something-- but you ignore classic's gutting of validation.  Tisk tisk.

Nice classic-speak jbreher--  Someone saying that a change increases bandwidth usage doesn't mean they're saying it does nothing to mitigate.

For those who actually care about the facts: Segwit does ease the burden compared to a blocksize  increase: It eliminates the quadratic cost in transaction signature hashing, it opens up new sync mode for full nodes that are using pruning that will allow them to skip downloading the signatures they aren't going to validate or store,  it also allows running a non-upgrade segwit node to get a mostly-validating state (which is useful as a last resort for someone who's alternative would be to not run a node at all), and (compared to Bitcoin Classic's proposal) doesn't make the potential impact on the UTXO set size any worse (so on this point, it's an increase, but less of an increase than just changing the blocksize limit would be).

That is the median size.

You're just being mean.

If they mislead anyone-- though they assure me they didn't-- that's on them, no one else-- doubly so because assurances were made to other contributors that no such thing would be done when concerns were raised in advance about the ethics of trying conspiring to set network rules in closed meetings.  My prior exasperated comments were precisely because I think it's naive to think that whatever understanding there actually was at the time that it wouldn't be spun as something else-- exactly as you're doing.

As far as contributor it's true that they are-- but:  Matt's last merged commit was December 13th (6 months ago), Peter Todd's last merged commit was Jan 31st (5 months ago), Luke's was Feb 27th (4 months ago).  Valued though they are, these are not exactly the most active contributors (and to be complete, they do now all have recent pull requests open).  Their signatures were accurate in any case-- anyone can be a contributor, it doesn't imply any particular authority... but nor did the subject of the agreement require any authority. Considering that the goalposts are shifting, -- now people suggesting that core has to accept whatever they propose (a promise they never could have made), or that this proposal has to come before SW... I don't know why they'd bother with it at all now. It seems clear to me that they're getting played.

If "Classic" were to hardfork in any case, they could simply make it merged mined.  When I heard the name I initially assume that was precisely what they were going to do-- make it into a spinoff with merge mining, and apply the deceptive "classic" moniker to try to privilege it as the original thing.

I guess you think if you just keep screaming your lies louder and louder people will finally believe you?  Pure "Classic".

what the fuck is a "confidential payment code"? ... in any case, things like any additional commitments come out of the block size limit-- they don't add to it.

There is no math to provide, you're just outright lying-- and trying to obscure it by stringing together your jibberish with addition symbols. The faux-formalism might make it look truthier but it doesn't make it true.

2MB blocks are "Bitcoin Classic"'s roadmap, I suppose that the confusion is justified since that is the subject of this thread.

Thanks for confirming that your lying is intentional and not just a product of ignorance.

That is a Bitcoin Core roadmap, not blockstream, and has nothing about 2017 or "5.7mb potential real data transmission per block".

No kidding-- the only value in replying is that most people don't expect such audacious lies, and if there is no correction at all these jerks will keep doubling down on their dishonesty until joe-bystander, who can tell that it's at least 99% rubbish, thinks that at least 1% of it must be true.

What the @#$@ are you talking about?  "blockstreams 2017 roadmap"?!?!?! Where can I get a copy of this?

And "potential"? The fact that a miner could create contrived high cost blocks is nothing new, right now miners can create blocks that take something like 20 minutes of cpu time to validate. But this sort of intentional bloat-block is almost equivalent to just delaying publication of the block.  What matters for the long term system cost is the average size of blocks, not the potential for a single unusually costly one. Without segwit the unusually costly risks are just different (instead, they take the form of utxo bloat blocks or signature hashing bloatblocks). If your metric of risk is the worst case time it can take to transfer and process a block, segwit does not increase this over the current state: It does allow more data to be sent in the worst case, but segwit transactions have massively faster worst case validation. The end result is that the worst case block with segwit is exactly the same as the worst case block without, you can't use segwit transactions if you want to make a block that propagates very slowly.

Segwit has been public for a long time... Block 0 on the current segnet has a date in January, and segwit is live on testnet now.

Where is Bitcoin Classic's segwit implementation? Hell, where is their mediantimepast and CSV implementations?  Even when they can just copy code from core they can't seem to keep up. If you're going to complaint about something not moving fast enough, it's not core you need to look at...

What? you don't read this thread? (the comment he was referring to was a few pages back)-- I guess it's interesting to know that Coinbase's executives are reading this thread.

More deceptive garbage-- in particular, it makes it sound like I wasn't referring to my own freeking employees there, or that my flip comment had something to do with working with miners on compromise when instead I explicitly pointed out it was because they went off to hold a secret meeting and let themselves get coerced (literally locked in a room until 3-4am) into an agreement which-- in the sense it was understood-- was physically impossible for them to comply with (because none of them have the authority to control what core releases or what the network runs)... and they did so after explicitly promising other people-- concerned about the ethics of meeting in secret to collude with miners-- that they go only to learn and share information and not make agreements. I don't feel any hesitation in calling that a foolish move. (and not just in hindsight, I warned about this kind of outcome in advance)

But while we're on the subject of foolish moves, whats the deal with coinbase continually insulting bitcoin technology and antagonizing the people whom are actually working on it?  They contribute _NOTHING_ to the technology, they don't even contribute to maintaining their beloved "classic".  I guess they might be happier with Ethereum, since it's a far more centralized system they'll know exactly who to lobby to get whatever they want without putting in any effort themselves...  But, considering that Coblee was bragging months ago about how much Ethereum people at coinbase were buying, I think the main attraction is something Bitcoin couldn't match: the ability to use their company to pump an asset they could all buy personally on the cheap-- it's much harder to do that for a system which is mature and less based on speculation.

Segwit's implementation is done, and has been for some time now. It's in review and testing (both on testnet and the dedicated segnet) right now.

Any person or organization who is interested can help hurry it along by contributing to review and testing.

Bringing it back on topic:  Looks like "Bitcoin Classic" has still not integrated CSV support.  The CSV BIP is 9 months old now-- and was almost deployed in Core along with 0.12.0, but was given more time to mature first. It's now been out in Core for over a month-- and the BIP9 starting date was sent a bit in the future, in part to give other implementations time to update.

Signaling for it has started now and is already hitting half the hashrate.  This triggered "Classic" nodes to start warning that they didn't appear to be consistent with half the hashrate.  Did this spur a quick catch up? No: The response of classic's developer was to rip out the notice infrastructure.  Ironic: That this is happening after months of "Bitcoin Classic" advocates howling incorrectly about soft-forks silently downgrading the level of validation their nodes do... Doubly ironic: If changes like this were hardforks users of under-maintained projects like "Bitcoin Classic" and Bitcoin XT would be forced by the change to use Bitcoin Core instead of their preferred software.

PWC has no investment in Blockstream or anything to do with investment in Blockstream. (Not that it would matter if they did), AFAIK no bank has any investment in Blockstream-- though they might be wise to, to the extent that the technology we work on might displace some of their businesses they'd be wise to want to figure out how to adapt to it.

But really, most groups that might be displaced by Bitcoin simply can't see it coming-- if they weren't blind to the reasons it would displace them they wouldn't likely be displaced. There is no reason that any ordinary bank today couldn't quite profitably adapt to an all Bitcoin world.

Alice and Bob want to tranfer a secret letter. How can they transfer the information with the use of the chess game?

Over and over, the concrete evidence shows that the hardfork at all cost push comes largely from shills, conmen, and their victims.  When actual Bitcoins are put on the table in a cryptographically provable way the result is 180degress off from what the claims are in trivially sockpuppeted forums.

e.g. http://bitcoinocracy.com/arguments/if-non-core-hard-fork-wins-major-holders-will-sell-btc-driving-price-into-the-ground
http://bitcoinocracy.com/arguments/unlimited-blocksize-is-bad-for-bitcoin-because-it-diminishes-incentive-to-pay-fees-and-in-the-long-term-it-makes-mining-unprofitable
http://bitcoinocracy.com/arguments/bip101-is-better-than-the-status-quo

If you want to resist the kinds of things your signature is talking about you need to steel yourself against claims like that, because they're a primary attack vector.

Besides, if wishes were horses beggers would ride:  Classic is a release behind core now, and not keeping up with network features which have been in the works for a year. It's headliner devs continue to not do anything, just as they were not doing anything with Core. Meanwhile, core continues to set the pace with both invention and development that to deliver improved scalablity, capacity, flexibility, privacy, etc. There is a clear reason why you can't get engineers who care about their reputations and about Bitcoin to back these HF at any cost initiatives-- they're no good for either.

The situation is pretty clear too and not just to me-- the big Classic voices, who are still haven't come to grips that with the fact that Wright defrauded them and denouncing wright are ramping up the complete and total dishonesty... such as mischaracterizing Theymos' repeat of the (good or bad) perennial proposal to make apparently lost coins secured with vulnerable cryptosystems unspendable after a long announcement and delay to prevent economic turmoil when someone steals them all at once, or claiming that a couple core contributors musing about potential countermeasures to the patent encumbrance of a vulnerability in SHA256 mining creating a government granted monopoly on mining is some move to make existing mining hardware unworkable, or claiming that Bitcoin core devs are totally going to line up and work on classic if only miners use it, or other such nonsense.

Pfft. I'm not going to mislead people by failing to call it what it is-- going to have some secret meeting where you are massively outnumbered with no strong negotiator on your side where you let yourself get compelled to commit to random things which are either largely meaningless or violate other people's trust and confidence in you (or, in fact, commitments you made to others before leaving) is a truly foolish move, if not quite "publicly endorsing scammer-wright" grade.

It's not the end of the world, people screw up, shit happens, goes on on-- but someone here asked the question as to why Luke was going around polling segments of the community what kind of hardforks they'd find acceptable, and that is why. It is a disappointment because its likely to exacerbate and prolong some drama which could otherwise be largely over now.

It's just that a couple of well meaning dipshits went to China a few months back to learn and educate about the issues and managed to let themselves get locked in a room until 3-4 am until they would personally agree to propose some hardfork after segwit. They're now struggling to accomplish the seemingly impossible task of upholding their agreement (even though it was made under duress and even though f2pool immediately violated it) while obeying their personal convictions and without losing the respect of the technical community. All this struggle is based on the mistaken idea that anyone external to the project cares what they personally committed to work on...

I think it's a shame, since with Wright's fraud behind us, I think the biggest behind the scenes driver of this drama is likely gone. But one should never under-estimate the bitcoin community's ability to keep cutting itself even after the external assaults tone down.

There aren't 'hubs' in lightning, especially not any form of it I support. Blockstream has no business plans to collect bitcoin fee income from lightning, never has, and the claim otherwise is just whole cloth fabrication.