Will BIP110 confiscate your coin?

[PepeLapiu]

(useless retarded personal attacks removed)

So far, you have supported the removal of a spam filter, glorified spam as "being easy to validate", rejected the reality that ordinal spam pay half the price of monetary users, all while claiming "the fees are the best filter", and you have rejected any and all attempt at resisting spam.

You have no credibility, Greg.

But I'm curious Greg. What are the ways you find are acceptable to fight against spam? Since your coretard mind rejects every anti-spam ideas so far, what are your suggestions now?

[BitGoba]

Bitcoin is a monetary protocol and money. It is not crypto.It has nothing to do with the crypto industry, which is a scam. Scammers have drained the market with endless scams and shitcoins. Fewer people are falling for them now, so they are trying to attach their scams to Bitcoin

I only support changes that make Bitcoin better as money.

[dkbit98]

There is a clear statement that BIP-110 could result in RISKS that would make coins frozen or lost:
https://bip110.org/#is-there-any-risk-of-funds-being-frozen-or-lost

Bitcoin is a monetary protocol and money. It is not crypto.It has nothing to do with the crypto industry, which is a scam. Scammers have drained the market with endless scams and shitcoins. Fewer people are falling for them now, so they are trying to attach their scams to Bitcoin

Then why are you now promoting Citrea crap and their shitcoins?
It's not a scam when you are doing it right? 

[PepeLapiu]

There is a clear statement that BIP-110 could result in RISKS that would make coins frozen or lost:
https://bip110.org/#is-there-any-risk-of-funds-being-frozen-or-lost

Here is what they say:

In theory, yes, but this proposal goes to great pains to avoid affecting any known use cases. Funds are completely unaffected if they don't use Taproot, use Taproot in standard ways, or can be spent via keypath or other expected Tapleaves. Additionally, UTXOs created before activation are permanently exempt from the new rules — they can be spent at any time without restriction. A separate two-week grace period between lock-in and activation also provides general preparation time.

The operative word here is "in theory".
But in reality, and practically, it's very unlikely.
You would have to be knowledgeable enough to know to do an op_if in Taproot, all while living under a rock and completely unaware of the controversy and new rules.
You would also need to use an outdated wallet, or one that refuses to update to the new temporary rules.
And you would have to do both the commit and the redeem during the BIP110 one year period.

And after you do all that, your coin would still only be unspendable for the duration of BIP110.

You'd have to delete your keys to actually lose your coin.

So yeah, in theory it's possible, but extremely unlikely.

Op_if in Taproot is something we need to get rid of. And as far as I am concerned, we should get rid of all Tapscript in Taproot. Bundling Tapscript with Taproot was not a good thing.

The reality is that there is not a single tutorial out there that teaches you to delete your keys after doing some convoluted inheritance scheme. So you have to find and read and understand a github page in order to think "Hey, it's a great idea to delete my private keys as part of protecting my coin."

Nobody is that stupid, not even Greg Maxwell.

[dkbit98]

The operative word here is "in theory".
But in reality, and practically, it's very unlikely.

It's not impossible, and that means there is a chance for something to happen, especially with quantum computers in near future.

[PepeLapiu]

The operative word here is "in theory".
But in reality, and practically, it's very unlikely.

It's not impossible, and that means there is a chance for something to happen, especially with quantum computers in near future.

Correct, it's not impossible. This is why it's wise to do it only temporarily, in case BIP110 does break something.

The temporary aspect of it, I consider wise. Just imagine if we had done Taproot as a temporary upgrade. We could have fixed a lot of problems before making it permanent. Taproot's "speedy trial" was completely useless.

I think, in the future, all upgrades should be temporary.

[ertil]

This is why it's wise to do it only temporarily, in case BIP110 does break something.

It won't be temporary. Even now, before BIP-110 activated, you want to use stricter rules, by activating next BIPs: https://bitcointalk.org/index.php?topic=5582070

Just imagine if we had done Taproot as a temporary upgrade.

Do you understand, what would happen, if Taproot would expire? Then, all P2TR coins would be spendable by anyone, without any signatures, unconditionally. Which means, that all users, who used P2TR, would lose their coins in that way or another. Because what can be done with a coin, which is spendable by anyone? You can let it to be stolen, or burn it, by throwing it out of circulation. In both cases, real users lose their funds.

Taproot's "speedy trial" was completely useless.

Then, why Luke wanted to mandatory activate Taproot, even if it wouldn't be supported by miners? Why he wanted to do that in the same way, as he is doing it for BIP-110 now? Why he created a separate client, which forced Taproot activation, while in Core, it could simply fail, if not enough miners would signal?

If you are disappointed, because of Taproot, then go ask him, why he forced it in his client. If Taproot would fail, then Luke's client would fork into a minority chain back then. Speedy trial actually pushed both clients to the same chain.

I think, in the future, all upgrades should be temporary.

If they would be, then it would be risky to use any new features. Which means, that all users would just stick with P2PK, because it is the only address type, which is present since 2009, and is used absolutely everywhere.

So, do you think, that everyone should stick with uncompressed P2PKs? Because even compressed ones is a feature, which was discovered later. Satoshi used only P2PK uncompressed keys, which is why he hashed them, to make addresses shorter.

[ABCbits]

And as far as I am concerned, we should get rid of all Tapscript in Taproot. Bundling Tapscript with Taproot was not a good thing.

You don't want smaller TX size (since Tapscript let you reveal only 1 branch rather than whole script) which allow people save fee on Bitcoin TX and allow more TX on a block?

I think, in the future, all upgrades should be temporary.

All upgrades? i can't image new address and quantum resistant cryptography only available/can be used temporarily.

[PepeLapiu]

You don't want smaller TX size (since Tapscript let you reveal only 1 branch rather than whole script) which allow people save fee on Bitcoin TX and allow more TX on a block?

That's the sales pitch. We were promised scaling and privacy with Taproot. But in practice, Taproot is 85% used by spammers. 85% of Taproot UTXOs are spam dust UTXOs.

I think, in the future, all upgrades should be temporary.

All upgrades? i can't image new address and quantum resistant cryptography only available/can be used temporarily.

Yes, all upgrades.

I'm tired of devs who claim an update is safe and effective, and there won't be any unintended consequences. And when the unintended consequences show up, the core devs get busy ignoring the problem completely.

[ABCbits]

You don't want smaller TX size (since Tapscript let you reveal only 1 branch rather than whole script) which allow people save fee on Bitcoin TX and allow more TX on a block?

That's the sales pitch. We were promised scaling and privacy with Taproot. But in practice, Taproot is 85% used by spammers. 85% of Taproot UTXOs are spam dust UTXOs.

Sales pitch? It's technically true, the benefit actually exist and can be used if you bother use wallet that use it properly. Boltz demonstrate Taproot usage that show both benefit on https://blog.boltz.exchange/p/introducing-taproot-swaps-putting.

[PepeLapiu]

You don't want smaller TX size (since Tapscript let you reveal only 1 branch rather than whole script) which allow people save fee on Bitcoin TX and allow more TX on a block?

That's the sales pitch. We were promised scaling and privacy with Taproot. But in practice, Taproot is 85% used by spammers. 85% of Taproot UTXOs are spam dust UTXOs.

Sales pitch? It's technically true

Yes, technically true but practically false.
85% of Taproot outputs are spam dust. Need I say more?

the benefit actually exist and can be used if you bother use wallet that use it properly.

Shoulda, coulda, coulda. But in reality, so far, Taproot has been nothing but a disaster.

I think Taproot could have been a great thing, if core had even remotely attempted to fix the bugs and exploits that turned Taproot into total spamware.

[ABCbits]

Sales pitch? It's technically true

Yes, technically true but practically false.
85% of Taproot outputs are spam dust. Need I say more?

Why should all dust considered as spam? It's normal to make small output due to leftover when you spend/send Bitcoin. And as i said on https://bitcointalk.org/index.php?topic=5562381.msg66604848#msg66604848, 62.9% Taproot UTXO are created by Ordinal inscription.

the benefit actually exist and can be used if you bother use wallet that use it properly.

Shoulda, coulda, coulda. But in reality, so far, Taproot has been nothing but a disaster.

Nothing but a disaster? What nonsense. There are so many wallet that support Taproot, with different level of support. See LIST Wallets supporting Taproot. Lightning Network these days also use Taproot address, including for swap that i mentioned on previously reply.

[PepeLapiu]

Nothing but a disaster? What nonsense.

Yeah. Again, 85% of Taproot outputs are spam dust. Clearly, 85% of Taproot uses are fucking parasites.

There are so many wallet that support Taproot, with different level of support.

I wouldn't care if there were a zillion Taproot wallets. The fact is that 85% of their users are using them for spam.

And to be more precise, the wallets used for most harm are the ones that support op_if in Taproot. That list is considerably shorter..The only one I know is Nunchuk. Not sure if others exist.


The litmus test should be simple:
Is your "interesting feature" needed to make bitcoin sound money?
Do we need convoluted inheritance schemes for bitcoin to succeed as money? If not, let's take it out. Otherwise, it's just a risk for exploits and bugs.

I oppose the agenda of trying to make Bitcoin do all sorts of funky stuff that aren't needed for bitcoin to be money.  And so, I think bundling Tapscript with the Taproot upgrade was a mistake.

[ertil]

And so, I think bundling Tapscript with the Taproot upgrade was a mistake.

If Taproot would allow only spending by key, then we would need a separate address type for scripts, just like P2PKH and P2SH was changed into P2WPKH and P2WSH by Segwit. Now, by looking at P2TR alone, you never know, if it would be spent by key, or by TapScript, or how complex it would be. And that was intended, to have a single address type for both use cases.

We already have more than enough address types. Ideally, there should be less. But unfortunately, it is hard to deprecate old ones, because then, people would lose coins, for example if they use uncompressed P2PKs, and it will be blocked.

Is your "interesting feature" needed to make bitcoin sound money?

There is also another question: is "not having a feature" making the situation better or worse? For example, Counterparty wrapped their data in multisigs, where some of them are now non-standard (but they were standard). If they would simply use OP_RETURN instead, then these users could sweep old coins easier. But because it is not the case, then cleaning some UTXOs is now difficult, and will probably require contacting the miners: https://bitcointalk.org/index.php?topic=5550467.0

So, which situation is better? To have OP_RETURN, and clearly separate data pushes from other use cases, or to not have them, and see them mixed with regular payments? Because even if you don't like something, then it doesn't mean, that people won't do that. And if they do, then it is easier to filter OP_RETURNs, than to check each public key, if it is valid or not.

Do we need convoluted inheritance schemes for bitcoin to succeed as money?

If you want to encourage billions of users to use Bitcoin, then it is not yet ready for that amount of traffic. If all people would stop using fiat today, and start using Bitcoin on-chain, in its current form, then the network would be stuck, and only transactions with the highest fees will be processed, and everyone else will have to wait.

Which means, that you need to change the protocol, if you want it to succeed, and not be used just by a small minority. If you block useful upgrades, then instead of scaling in a decentralized way, it will scale through centralized exchanges, and other similar things.

This triangle still applies:



In 2017, there was a split into BTC and BCH, where BTC decided, that block size increase is not the way to go. Violating 21 million coins limit was also raised from time to time, and it was rejected. Decentralized sidechains were rejected, so we have centralized ones instead. And Lightning Network won't onboard everyone, because if you need to have on-chain coins first, and you have to always interact with the main layer, by closing and opening channels, then it won't handle billions of people.

So, the question remains: how to scale correctly? And BIP-110 solution is simple: just don't scale at all, and block all use cases, which looks more complex, than most users can understand. Which means, that BIP-110 chain is doomed to scale through centralized exchanges, because this is what users can easily get, when they will see "deposit" and "withdraw" buttons on some website. Or worse: it will explicitly reject some groups, by saying "you shouldn't use our payment system", which means it won't be the coin for billions of people, but only for a small minority they can handle.

If not, let's take it out. Otherwise, it's just a risk for exploits and bugs.

Which is why Knots follows Core, and imports a lot of changes, including exploits and bugs. Because if you complain about Core deleting keys, or making other mistakes, then better check, if Knots didn't do exactly the same thing in some versions, just because of copy-pasting the same code, while also changing the commits, to make it harder to figure out.

[PepeLapiu]

We already have more than enough address types. Ideally, there should be less. But unfortunately, it is hard to deprecate old ones

Typical fucking coretard!
New address types are full of spam and you want to deprecate older ones?
This is the kind of stupid retardation that is causing people to migrate away from core spamware.

Is your "interesting feature" needed to make bitcoin sound money?

There is also another question: is "not having a feature" making the situation better or worse?

Avoiding the question with an other question is lazy and dishonest.
So far, the "new features" are not making anything better with 85% of Taproot UTXOs being spam dust.

I answered the question you asker, even though it was a lazy attempt to deflect from my question. So answer it:

Is your "interesting feature" needed to make bitcoin sound money?

For example (blah-blah-blah. more coretard bullshit) : https://bitcointalk.org/index.php?topic=5550467.0

How fitting that the OP posted an example tx that is a bare multisig and fake pubkey. And on top of it all, it's for an 11 years old UTXO of 20,000 sats. In 2014, 20,000 sats was worth 14¢ USD. Clearly, this is a grifter and a spammer.

So, which situation is better? To have OP_RETURN, and clearly separate data pushes from other use cases, or to not have them, and see them mixed with regular payments? Because even if you don't like something, then it doesn't mean, that people won't do that. And if they do, then it is easier to filter OP_RETURNs, than to check each public key, if it is valid or not.

That is the difference between coretards and bitcoiners. Coretards cater to spammers and grifters, under the cover of "harm reduction". Bitcoiners are no longer interested in dealing with terrorists.

Do we need convoluted inheritance schemes for bitcoin to succeed as money?

If you want to encourage billions of users to use Bitcoin, then it is not yet ready for that amount of traffic. If all people would stop using fiat today, and start using Bitcoin on-chain, in its current form, then the network would be stuck, and only transactions with the highest fees will be processed, and everyone else will have to wait.

Why do you bother to quote questions and completely avoid answering them? Is that a mental deficiency of yours?

If we want to encourage billions of people to use bitcoin, we need to scale up some more, AND we need to kick out the spammers and grifters who pay you to spew your bullshit.

Which means, that you need to change the protocol

So far, core has gotten busy changing the protocol to.cater to spammers, scammers, and grifters. Bitcoiners are now starting to turn the ship around. Core has been marked as deprecated.

In 2017, there was a split into BTC and BCH, where BTC decided, that block size increase is not the way to go.

If you want to bring up the block war, you should look into BIP148.

Big players and the industry wanted big blocks and they rejected Segwit. They though they were the ones in charge. BIP148 showed them the nodes run the show. Get ready to re-learn your lessons and take your L in 3 months.

And Lightning Network won't onboard everyone, because if you need to have on-chain coins first, and you have to always interact with the main layer, by closing and opening channels, then it won't handle billions of people..

Scaling is an ongoing process. Segwit, LN, and Taproot were all supposed to help the scaling problem. Instead, core got busy not fixing the bugs and exploits in Segwit and Taproot to cater to spammers.
So yes, we need to scale some more. And kicking out the spammers and grifters is part of that scaling process.

So, the question remains: how to scale correctly? And BIP-110 solution is simple: just don't scale at all, and block all use cases

Of course, coretards keep redefining spam as "use cases". Go to hell, coretard. Go back to.the shotcoins you came from.

If not, let's take it out. Otherwise, it's just a risk for exploits and bugs.

Which is why Knots follows Core, and imports a lot of changes, including exploits and bugs.

You are too funny. Core kept telling people they need to upgrade to spamware 30 because it contained important security updates. Instead, core 30 turned out to be spamware that delete private keys.
And for the record, not a single Knots user lost any coin. No Knots user saw his node delete his private keys. That is a horrible bug that was only present in core, not in Knots.

[qoluote]
Because if you complain about Core deleting keys, or making other mistakes, then better check, if Knots didn't do exactly the same thing in some versions, just because of copy-pasting the same code, while also changing the commits, to make it harder to figure out.
[/quote]

Luke is not stupid enough to copy-paste wallet deletion malware. That is something that occurred only for core 30 spamware users.

[ertil]

New address types are full of spam and you want to deprecate older ones?

What takes less bytes on-chain? 71-byte DER signatures, or 64-byte Schnorr signatures?

Is your "interesting feature" needed to make bitcoin sound money?

If you want to scale, then you need to do it "somehow". If you block all new features, then your chain will always use today's model, which won't scale enough, to onboard everyone.

By blocking things like TapScript, you will force those, who use it today, to use P2WSH instead. And then, some scripts will be pushed, no matter if they are used or not. Because Taproot gives you an option: you can spend by key, or you can spend by TapScript. If you will be able to spend only by key, then you will need two addresses, where a single one can handle it today.

Which means, that by disabling new features, you will undo the scaling efforts, which already happened, and then, users will use what they can, and push more on-chain bytes, than they otherwise would.

How fitting that the OP posted an example tx that is a bare multisig and fake pubkey.

People wouldn't use fake public keys, if they could use OP_RETURN instead. If you block OP_RETURN, then they will go back to previous methods, which will be more harmful.

Why do you bother to quote questions and completely avoid answering them?

Because you wouldn't ask that question, if you would understand that answer.

Do we need convoluted inheritance schemes for bitcoin to succeed as money?

We don't, but they exist. And if you block something that exists, then you will take other people's money. Also, if you block simple ways of doing things, which people want to do, then they will adapt, and switch to more harmful ones. What is harder today, discarding some OP_RETURNs, or recovering coins from multisigs, which were standard, but became non-standard?

If we want to encourage billions of people to use bitcoin, we need to scale up some more, AND we need to kick out the spammers and grifters who pay you to spew your bullshit.

How do you want to scale, if you want to block new upgrades, make them optional, or block things, which exists today? People will have no reason to use your new, scaling solution, which could improve the situation, if you tell them, that new upgrades can be disabled in the future, or their coins could be blocked. Why developers would want to build new things to scale BIP-110 chain, if they would risk being blocked, because of using "too complex scripts, that BIP-110 supporters cannot understand"?

Big players and the industry wanted big blocks and they rejected Segwit.

And they went back to Segwit, when they understood, that hard-fork will push them to a completely new chain, that would be worth the fraction of BTC. Those, who rejected Segwit, simply landed on altcoins like BCH.

Luke is not stupid enough to copy-paste wallet deletion malware.

In January 2023 Luke lost 200+ BTC due to poor security practices.

He proved to everyone, how he cares about security, by hosting binaries for Knots on a compromised server, and by losing a lot of coins, because of not using "convoluted inheritance schemes", or other ways, to protect them.



So, if someone cannot protect his own coins properly, then how other users can trust, that his code will protect their coins properly?