I'm pretty shocked to see some of the comments in this thread.  BurtW has nothing to prove here, and those of you attacking him should be ashamed of yourselves for attacking a victim.

BIP-68 and friends, the new sequence lock feature that allows for relative locktimes, are getting close to activation on the network with 99.31% of the last 144 blocks signaling they are ready to activate.

As we've discussed a few times, Bitcoin Classic has still taken no move to support this-- Zander is suggesting they won't (with a rather confusing argument that this feature is not useful without segwit).  Meanwhile, /r/btc noticed the adoption and there was this gem of a post, after someone suggested that the rapid increase from 50% hashpower to 99% meant classic's 75% threshold were fine:


I responded, pointing out that yes indeed, in professional operations upgrades can and should take a long time... and also pointed out that this softfork has been released in Bitcoin Core for months (BIP-68 itself is a year old proposal, there is nothing surprising or hasty here), and even though Classic need only forward port their "trivial" single point of departure hardfork to the 0.12.1 codebase-- Classic has taken no action to do so at all. Meaning that if CSV were a 75% hardfork, every classic user (however many there actually are) would _now_ be forked off the network.

We saw this same kind of absentee maintenance with Bitcoin XT. -- and, withholding judgement, the freedom to be absentee in this manner is one of the major reasons many people in the community prefer the conservative soft-fork process. Without it, running any implementation but the most popular would be a lot less wise. (Ignoring for the moment the lack of wisdom in running something with an intentionally programmed consensus inconsistency-- it's perfectly possible to make alternative implementations that are consensus consistent.)

It was only after I finished my reply did I realize that the author of the post was Gavin from Bitcoin Classic.  So, what, do the classiccoin supporters here need to pool their funds to spring for a copy of Mavis Beacon teaches typing?

The standard /r/btc response is to bot-vote my replies to invisibility, so, sadly, the people who would most benefit from seeing my response won't see it... but perhaps it will bring some amusement to people here.

Latest "Classic" move,   https://www.reddit.com/r/btc/comments/4nkmzp/the_ultimate_defence_against_the_alleged/   "The ultimate defence against the alleged xthinblock attack is header-first mining"

So "unlimited" (and proposed for "classic" but classic, seems mostly dead) has an efficient block relay scheme (their homegrown analog of BIP152) with a design flaw.

The way it works is this: When I relay a block to you, I give you a list of the transaction IDs in the block so you can match them out of your mempool instead of getting them from me.  To save bandwidth instead of sending the whole ID I send only the first couple digits of it.  They reasoned that they sent enough digits that it would be really unlikely for two txn in your mempool to have the same truncated IDs by chance.

What they didn't account for is the well known result, often called the "birthday paradox", that it is _much_ easier to compute two messages sharing the same short hash than you'd expect.  Because of this, with the scheme in unlimited it's very easy for people to make pairs of transactions with matching short IDs and send them to the network. Any block that includes one of these TXN will propagate more slowly (because the reconstruction will fail, and it will have to take a round trip and retry with more data.).

This flaw is something I spotted back in 2014 while working on some of the design work which later became part of BIP152, and I came up with a simple solution: Instead of truncating the txid, you hash it with a keyed value that isn't known to the attacker (we just have the sender pick one).

It's not the biggest deal in the world, but that fix shuts down some easily perpetrated vandalism (which could also potentially performed for profit reasons) at basically no cost.

The "classic" response?  If miners don't verify anything at all, well then it doesn't matter to the miners how long it takes for block data to reach them. And since big miners and companies are all that are classically important, and SPV wallets (which make a strong security assumption that miners validate) are not... why bother fixing the flawed protocol?

Never-mind the fact that classic's attempt at this was already aborted.

The 'average' tx mostly doesn't exist. The sizes of transactions are highly multi-modal. There are a whole lot of small ones (most ones people make) and a decreasing number of larger and larger ones that drag up the average. If you're joe-schmoe and make a transaction, it's most likely you'll make a median sized one.

It's like saying the the average number of testicles an American has is 1... and yet relatively few people have exactly one testicle, even though it's the average.

[In no case should fees be under-paid... in competent wallets fees are configured per unit size and set accordingly. ]

Another way to think about it is that "a transaction" isn't really a great unit of capacity. Consider, what if everyone started using 4-party non-amount-matched coinjoins for all their transactions. We'd end up with 1/4 the number of "transactions" each of 4x the size. Would it be right to say that suddenly the Bitcoin network had 1/4th the capacity because now the tx were 4x larger?  No-- they're also doing 4x as much.

It's a great statistic if you're talking about typical transaction fees, which I believe was the original topic.

No. 226 is actually the _median_ transaction size.


In [46]: pp = AuthServiceProxy("http://bitcoinrpc:password@127.0.0.1:8332")                                   
In [47]: txa=[pp.getrawtransaction(x,1) for x in pp.getblock(pp.getblockhash(415093),True)['tx'][1:]]
In [48]: sum([x['size'] for x in txa])
Out[48]: 999724
In [49]: numpy.median([x['size'] for x in txa])
Out[49]: 226.0


Same story for pretty much every block.

(Minimum is 189 in that block FWIW).

Franky1, in this case you were just confused-- but you've got a number of other claims like saying CT is part of core's published roadmap, that are outright lies. I think you need to stop wasting everyone's time.

CT isn't part of Bitcoin Core's roadmap at this time; but somehow its not shocking that you're vigorously opposed to it for unexplained reasons.  There are like a bazillion people on /r/btc who would love to hear your theories that Bitcoin Core is bad because the blocks will be _bigger_ under it's plans though, I suggest you go share your theories there.

Bitcoin has specific affordances for softforks which were added to enable them, things like NOPs in script-- which were added to replace an earlier mechanism that caused random uncoordinated hardforks, and transaction version numbers. Softforks were used by bitcoin's creator several times early in its existence, e.g. to do things like fix script or add height based nlocktime.

Things ignored by this post:

Conservationism about coersively overriding the rules of the network is a widely held view, including almost the entire technical community (which blockstream engineers are only a small part of).

Concerns about hardforks and removal of blocksize limits stem back many years, long before the creation of blockstream. I was posting in 2011, for example.

Soft-forks were a mechanism put into place by Bitcoin's creator-- and used by him several times, never hardforks--, and he also also described the initial rules as largely set in stone when the system was launched.

At the end of the day, _no one_ has the authority to push a hardfork onto other people-- to do so would require overriding their wishes and changing the software on computers they personally own and control.  Bitcoin is specifically designed to not have that kind of authority.  People who think hardforks are easy, simple, or desirable have lost the plot.

It is much easier to drive up with tanks to commandeer geographically clustered hashpower.


But destroyed? "We are told to remember the idea, not the man, because a man can fail. He can be caught. He can be killed and forgotten. But four hundred years later an idea can still change the world. I've witnessed firsthand the power of ideas. I've seen people kill in the name of them; and die defending them."

I can't agree at all.

Payment channels are _nothing_ like old centralized financial models.  Who is the trusted third party? No one.  

When you go on and on about "on chain" you're confusing a technical mechanism for a social or business business goal.  Everyone being able to transact with everyone else at low cost and without the risk of censorship or exposure to extraneous counterparty risk is a laudable goal.  "On chain"-- meaning transacting in a lock-step synchronous world wide flooding network-- is a technical mechanism. On that, to the best of our current understanding _cannot_ deliver that business/social goal.  Fortunately, we do know ways to deliver it.

It's like walking up to some aircraft engineers and demanding that the next design be exactly the same but have a wingspan twice as long, when really your goal was to double the number of pounds of cargo it could carry.  Maybe the change lets it carry more cargo, or maybe it just makes the plane unstable.  Regardless, a particular _mechanism_ was confused with the business goal, and as a result an end-run around the science and engineering that could, potentially, have actually met the goal if given a chance and allowed to make the required tradeoffs.

Of course, there is always someone out there that will tell you that you can solve any complex problem with this one weird trick.  But there is a word for them: Scammers and their patsies.  And right now, there is a whole clique of the Bitcoin old timers who were bamboozled by Craig Wright and his 419 scam which predominantly featured a ton of magical scalablity claims... it's going to take a while for their wide and greedy eyes to blink and realize they've been tricked, and that maybe these magical scaling claims were just as fraudulent as everything else.

No.

Is that enabled in ethereum now? last I looked it wasn't.

Blacklist the txout, no? That is a basic level of protection.

I'd just assumed a narrow definition of "in circulation".

I don't expect that to happen, I think they're honestly concerned though for reasons that might have been misguided. E.g. I found out that Classic developers have been telling people that SW will only bring at most 1.2MB worth of capacity.  And other people have been saying that it would take years for wallets to begin making SW transactions. If I were in their shoes and believed those things, I might be trying for other options too.

Check out this discussion about HK: https://www.reddit.com/r/btc/comments/4ma3gh/whats_the_current_status_of_cores_2mb_hf/d3u772x?context=8

I think it's likely miners have just been under a lot of strange pressure-- keep in mind the XT support letter that included all those big corp exchanges (and classic's support campaign that had a few not actual supporters on it), and are just trying to do the best for Bitcoin from their position.  Time and better communication can improve a lot of things.

As an aside, the totally offtopic posts that have nothing at all to do with classic, even in passing are getting pretty irritating. I've started reporting them to mods.

I gave up and put him on ignore too, eventually. It was doing nothing but looping and nonsense. For at least a little while I thought the peanut gallery or at least I would learn something... but eventually even I started to get bored.

Back on topic,

I posted a bit of a Classic take down on /r/btc: https://www.reddit.com/r/btc/comments/4mb6f8/classics_developers_are_almost_completely/d3u3on3  but it seems now that the thread has been hidden.  Nothing new to people here, but I thought it was an okay post.

Oft, claimed, never proved-- I bet him and Wright are great buddies.  Maybe it was true at one point, but one doesn't retaining 100,000 BTC by buying loads of ripple, ethereum, and every other highly hyped altcoin that comes around.

If it is true, it's remarkable and sad-- to own so much bitcoin and yet spend none of it to help further the development of Bitcoin... and instead just investing in putting a sleazy looking gambling site on Bitcoin.com (and filling the site with pro ethereum news).

In particular,  the wallet will generate new addresses after the password was changed that the old wallet won't know about. So your old backup will become increasingly invalid over time.

I'm more or less completely beside myself at Zander's claims that Classic implements BIP9: https://www.reddit.com/r/btc/comments/4lvdsj/repost_from_rbitcoinclassic_warning_flag_while/d3qztv7?context=1

He might as well also say that Core implements 109 for all the relationship to reality that his remarks have.

"Classic" 0.12.1 is out-- it's still based on Core 0.12.0, and in particular doesn't include BIP 9 or the BIP 68, 112, 113 softforking changes.  I bet that number is going to cause a lot of confusion.  What it does include, however, is a hand full of other changes committed directly to the tree without pull requests that appear to have had little to no public review.

Among them, it completely rips out all notification that miners are signaling consensus rules that the node doesn't understand. This silences the _correct_ notice that classic nodes aren't consistent with the rules the majority hashpower are signaling an intent to enforce (68/112/113 in this case).

If this were actually widely used software I'd be raising a stink about it, thankfully it doesn't appear to be.