Thanks for pointing this out-- only takes a second to register on github... but if you don't it'll get picked up eventually.

Please feel free to report any other issues you find (though best on github!)

Nope, changes to the tags require another hardfork. So much for avoiding impact.

Sewit doesn't repurpose any fields, it adds fields. The transaction format isn't static.

Tagged binary formats are a repeated source of vulnerabilities, as I mentioned the one that was being used in Bitcoin-- ASN1 has caused problems even for our very narrow use of it.

I won't elaborate more because I said much of it above and all you did was simply repeat the same claims without responding to any of it.

This is just an outright lie-- go ask any actual Bitcoin developer: Segwit makes Bitcoin much easier to use. While FT adds a pile of complexity that results in vulnerabilities (including cryptographic compromises), and has _already_ done so in Zander's own codebase.


Yea, it's the same crud over and over again over a ever shifting sea of nyms-- some of them probably socks, other people just weaponized innocents.  The end result is that the people that get to deal with the disinformation and are working to defend Bitcoin from it learn to recognize the repeated arguments at their first sentence and cut it off curtly -- and then you get a pile of out-of-context links  "Oh look how mean they are! that was unjustified." -- yea, unjustified unless you also saw the same lies being repeated over and over again for months.

This post is a dirty fucking lie.


Every Bitcoin user should be outraged at this libel.

BU shipped vulnerable software. BU disclosed their vulnerablity in public. Random people on the internet broke their shit.

Now the BU org claims "Bitcoin Core" did it?

FUCKING BULLSHIT.

The only thing contributors to Bitcoin Core have done here is gone "WTF".

This is disinformation that you're peddling here.  Segwit uses an _explicit_ _intentional_ forward compatibility mechanism.  Old nodes _know_ that the segwit transaction is making use of rules they don't understand, which is why they will not relay, mine, or display unconfirmed txn using it in their wallets.

Go look at the history of ASN1 and XML-- 'tag' based formats, they're freeking disasters in the context of cryptosystems. They result in malleability bugs and all sorts of other disaster cases-- Bitcoin itself has had several vulnerabilities related to ASN1 just being used inside signatures. The extreme complexity of FT is also revealed by the fact that it's authors reference implementation had at least three buffer overflow vulnerabilities...

The design also doesn't actually create the flexibility it claims, since changing the fields requires a hardfork. ... and a hardfork could already have done anything. So there is no reason to have an overly generic structure in advance, it simply leads to vulnerabilities and inefficiency.


Actually, the FT format actually increases the entropy of transactions because the ordering of fields is signature normative by not canonically mandated.  This means that it actually takes more data to make an efficient representation of FT transactions than ordinary and segwit transactions.

Segwit doesn't move any data into the coinbase. Perhaps you mean that it includes a *commitment* (not data) in the coinbase transaction (though not in the coinbase itself)? This is specifically an intended use of the coinbase transaction, which it has been used for since ~2011... and it's a use that Satoshi recommended-- in fact.


Kinda funny how you asked a question but then followed up with a mountain of pretty extreme misinformation.  It's especially amusing to hear you in one breath attack an idea (fields that nodes explicitly ignore) while in the next extol the same concept.  It makes it hard for me to believe that you're really asking this stuff earnestly.

No it didn't it had support from maybe about ~55%  from what I recall and was opposed by the largest pool of the day (deepbit).


That is just simply untrue. Damn man your dogmatic ignorance is making me want to go read up on the proposal just so I can support it.

The users of Bitcoin define what mining is, if you cross them you are not a miner.  In that sense, it is impossible for 100% of miners to not support anything that the user base has decided on...

Rusty is not a moderator. I don't know who are moderators now.

Personally I don't go anywhere near that list. It's full of abusive people like Thomas Zander who just crappost relentlessly.  It's a waste of time.


Meh. I don't know why you say that: BIP16 was flag day activated.  I haven't really been following, but some people seem to think a controversial HF should work and a flag dayed softfork-- if it's a miner compatible softfork like segwit at least-- should be strictly simpler and less risky than that even in the worst case.

Segwit doesn't give any spammers more power than they have had before, in fact it makes them much weaker.


It improves the system by changing the limited quantity from "size" to weight because weight better reflects the true costs to the system than size.   Size is totally irrelevant for pruning nodes, with fast-block-relay-protocol, BIP152, and Fibre size is almost totally irrelevant.  It matters for non-pruned nodes, but at the current size and growth rates those are already effectively pushed out of using cheap fast storage-- e.g. you're not likely to run a node on a 256GB SSD anymore.

e.g. see the stats from Matt's public fibre network:

-- with the exception of small or effectively empty blocks that fit into a single packet, the size of a block has no real effect on its propagation time.  (Time figures are in millisecond delay over the speed-of-light time)

Though size is decreasingly important, UTXO impact remains important as we previously ignored in the past limits. Because size is blind to UTOX impact:  A spammer could create transactions that bloated the UTXO set and paid _less_ per byte than ordinary transactions.

One possible solution is multiple distinct limits but a problem there is that with multiple limits in play it is impossible for wallets to figure out appropriate fees, because the right fees would depend on the exact mixture of transactions at play when the block is created. Multiple effective limits also make creating an income optimizing block very computationally difficult-- but with one limit you simply take transaction in order of fee per limit-used.  So to avoid that the weight limit combines both witness and non-witness (utxo impacting) limits into a single limit.   Whenever this is done, improving one factor (e.g. amount of worst case UTXO bloat per byte to typical) will make another worse (e.g. worst case amount of size.).  Segwit's parameters were set to massively decrease the amount of UTXO bloat possible while only increasing the worst cast size modestly:


Green line is how many times beyond typical a UTXO Bloat block can be, red line is how many times larger than typical a "size" bloat block can be.   X is the segwit factor, which is 0.25 in the actual segwit proposal.  The pre-segwit behavior is effectively an X of 1.

Since UTXO costs are much more concerning than size on the modern network it might be arguably to set the segwit factor even lower, but the size bloat goes up hyperbolically with a lower factor.  So even though size is less important the trade-off becomes less attractive with values much lower.  The value chosen for the proposal also happens to be just about what is required to get virtually all the capacity gain from this particular restructuring, owing to the typical ration of witness to non-witness data in transactions.

All that said,

Segwit is indeed a compromise: Increasing the networks' load and capacity is a non-trivial risk that may ultimately cause harm.  Segwit does a lot to mitigate that risk, but it remains.  It offers effective the same capacity that that the hardforksers were pushing for w/ Classic & BIP109 before they moved the goalposts again after a way was found to achieve that without splitting the network.

It just isn't a compromise because malicious miners could make blocks with 4MB size-- they could, but who cares... blocks with 4x more UTXO bloat would be a _much_ greater concern. And under the constraint that there be a single limit-- needed to make block creation and fee selection tractable-- improving the one bloat attack means that that the worst case for the other, less important, one will be worse.

If your node is crashing suddenly then you have worse things to worry about.

The mempool saving was originally written so that it wrote it periodically but writing 300 MB every N minutes is not good for performance or write durability of your media.  I suggest fixing your crashes, losing your mempool state is the least of your worries.

Ignoring the block size would be one thing-- just an ill-advised hardfork which would erode the decentralization of the system-- but BU replaces the validation based consensus model in Bitcoin with "emergent consensus", which is radically different and not an improvement.

Then they should admit that what they want is a system which is different from the one Bitcoin's creator released. There is also no mention of 21 million coins -- why not 42 million-- there is no mention of Bitcoin Script, nor of 1001 other parts of the system.

I don't do anything with monero.

Elements and liquid use Bitcoin (well testnet Bitcoin and Bitcoin respectively.)

I own a considerable amount of Bitcoin and am paid partially in Bitcoin.


I feel like you are a paid shill trying to destroy Bitcoin. I probably have more evidence of that than you have to argue about me.


I am not paid by bankers. I am paid by a company I founded whos investors are not bankers.  And many people are excited about work I've done that was funded by this company like Confidential Transactions and sidechains.


The irony is that you're posting here nearly 24 hours a day arguing to change Bitcoin. I think Bitcoin is okay the way it is.

Are you not even reading the pieces of the whitepaper we're quoting here? An overpowering attacker making invalid blocks is simply ignored by network nodes. There is no reason to change the POW.

No, just more work. It doesn't matter how big or slow it is, BU will follow more work even with those changes, because it has abandoned the consensus model of Bitcoin and replaced it with strong trust in miners. Instead of having a process that guarantees consensus it is a free for all that hopes cartel activity will cause an undocumented consensus to "emerge".

The text is also talking about full nodes. I've re-bolded to help you out.   As it nodes, an attacker might overpower the network with invalid blocks (this is not possible in the BU security model, because having more hashpower is the definition of "valid" there, and it states that this is prevented by network nodes because they validate, but in BU the network nodes trust miners instead of enforcing on their own.

If the attacker is overpowering the network, as noted, they can produce any number of blocks ahead on their chain. Not just 12.


No: more work wins, all that change does is potentially influence the behavior on ties of equal work (and potentially enable new selfish mining strategies, while slowing down validation and making it more memory hungry). Meaning an overpowering attacker can do whatever they want. This is the BU model and it is unlike the model described in the Bitcoin whitepaper or implemented in any version of the software ever released.

Repeating a lie won't make it true.

Even though you and BU insist on ignoring how _every version ever released_ works-- you don't even need to look to the operation of the system to disprove your belief that Bitcoin does whatever the majority of the hashpower wants-- The whitepaper itself specifically speaks to the potential for a dishonest hashrate majority:


The text you quote, "He ought to find it more profitable to play by the rules"-- is speaking to a world where network nodes validate and so miners ability to profitably break the rules is very limited. This incentive assumption is far weaker in the BU world where all users strongly trust miners.

Besides, you've dodged my point there:  You can that you want that miners should be strongly assumed to be honest and the system shouldn't be secure against them-- but don't turn around and complain about 'attacks' that only exist in a security model you've already rejected one where miners attacking is a problem.

I did and it's sitting with "Your comment is awaiting moderation.". I cannot "archive it" because it won't even be displayed in the first place without his permission.

Wow. Another remarkably dishonest article from the authors of Bitcoin Unlimited. (Archive link)


Making your transactions non-malleable is a thing you always opt-into because some forms of mallability are an intentional and useful feature.  With a segwit using wallet you get non-malleability by default, you can choose to not have it by using things like sighash flags. Obviously if you don't use a segwit wallet you don't get the segwit benefit. There is no fungiblity interaction here-- any coin can be sent to a segwit wallet and any coins in a segwit wallet can be sent to any other wallet, so that claim is simply untrue.

Again, a complete untruth. Segwit makes transaction hashing strictly linear in the size of the transaction. There is no quadratic component at all, and the hashing CPU time for all transactions with multiple inputs is significantly reduced. Because segwit is backward compatible it doesn't change older transactions (and couldn't, without risking confiscating funds) but that is okay because segwit doesn't increase the capacity for older transactions.

Dishonest miners being able to make malicious blocks that bloat the system isn't a new attack, but segwit makes the attack better by reducing the much more serious UTXO bloat attack vector.

I think this point is especially dishonest coming from a BU developer, given that their whole security model is based on a strong assumption that the aggregate behavior of miners is honest.  It's like a guy who sells houses without doorlocks on the basis that people are honest complaining that someone was lowering their security replacing their deadbolt with a combination fingerprint scanner + key lock where the key was somewhat easier to copy.


The description given there actually argues the opposite. The funds in channels are required based on the number of channels.  Lightning designs today are setup to only build channels as a product of payments you're already making. Using lightning in a "hub like" way requires extra transactions that you never would have made normally.   The big advance of lightning over the prior payment channels proposals is specifically that it doesn't need hubs.

Recently BU's "chief scientist" was making exactly the opposite argument based on the same facts: He argued that lightning did not improve scalablity because there would need to be as many channels as users and so when users went up the channel count would go up.


This isn't true-- blocks are _always_ effectively full and any system where they aren't is either irrelevant or subject to censorship. Bitcoin's incentives depend on full blocks, as well.. Lightning works fine in the presence of full blocks, and moreover lightning is largely orthogonal to segwit.


This is simply untrue.  Our construction for schnorr aggregation on top of segwit yields over 24% additional capacity in the limit with two outputs and infinitely many inputs, this number is nearly achieved with realistic numbers of inputs like 10 (which achieves a 24.6% capacity increase).  

So we have each and every point raised in this blog post are untrue, many absurdly so.

Finally, the untrue claims in this blog post are being plastered all over rBTC but due to actions by that subreddit's moderators I am unable to post a counterargument-- not just on rbtc-- but anywhere on Reddit.  Yet they happily scream about far less limiting actions a censorship.

Would you like me to post screenshots of the admin's comments?  (I'd prefer to to edit out their account name so no one harasses them; or only share it with you privately)

Had nothing to do with frapp, the post was harassing me by one of the zillion and one rbtc harassers. I think that one might have been go bitcoin but I'm not sure. In any case, frapp's name nor pseudonym were not mentioned there.

Please don't smear me-- I was suspended before because BitcoinXio reported me to the admins for "doxing" for posting a github commit message, which worked for a bit because Reddit staff didn't know that a commit message was not private personal information, and didn't know that Gavin's email address had already been long ago posted by himself. I was unsuspended when they figured it out, and the post in question is visible today: https://www.reddit.com/r/btc/comments/5g3weu/blockstreams_creator_changes_bitcoin_network/dap9jyr/


Due to s230 they have basically no (legal) liability for material posted by their users-- even if their action were to rise to the level of recklessness, they would still have no liability.

But indeed, I know about Reddit's rules; but the rules do not prohibit posting material that the person it was about requested be posted, and the person in question had already posted a link to a page they put up with their email address previously.  (Besides, if I'd thought to remove it and done so, it would have invalidated the DKIM signature on the message).  And as I said in my post above-- it's their right to have foolish policies if they choose to. (Ultimately, I think that letting me address libelous comments by one on one refuting them is ultimately a time and trouble saver for reddit, but nothing requires that they agree).

Reddit doesn't really have an appeals process as far as I can tell: All you do within the process is provide information to the specific administrator that they made an error.

And now our friendly (ex)rbtc mod account that I was accused of 'doxing' has argued that it was intended the whole time https://twitter.com/SouperNerd/status/835015250432819200

Cleaning up the subreddit of defamatory postings was the apparent idea.

yea moon typos from merging together multiple messages.  LOL. or perhaps I'm just subconsciously trying to feed the conspiracy theories.