Questions for Greg Maxwell

[DaveF]

And I thought I was paranoid.

You're not paranoid, they are really out to get you.
Protect your brain. https://x.com/DC_Tin_Foil_Hat

-Dave

[ABCbits]

You talk as if Ordinal exist more than 5 years ago.

Nope, I'm fully aware that ordinals started 4-5 years ago.

The idea? Yeah, the author claim he came up with it in early 2022.

So, funny story, in the beginning of 2022, I came up with the exact same scheme discussed in this thread.
--snip--

But first ordinal on mainnet created in late 2022.

Creation date
Dec 14, 2022, 8:32 PM(3 years ago)

So definitely not in last 5 years.

- Core doesn't even acknowledge that there is a spam problem, referring to spam as "user cases we have today" and referring to spammers not as attackers or grifters, but at "users who need to upload data".

You talk as if Bitcoin Core is single person/minded group. But in reality, the opinion among Bitcoin Core developer and contributor are very varied. If you look at PR created by Luke Jr (such as https://github.com/bitcoin/bitcoin/pull/28408 and https://github.com/bitcoin/bitcoin/pull/29769), some actually acknowledge the concept/idea to make some non-monetary TX as non-standard.

[PepeLapiu]

(endless drivel and personal attacks)

I have some tips for you.

If you find me annoying, figure out how to click the "ignore" button under every profile.
If you are annoyed with my posts, maybe consider not reading them and not replying to them?

Nope, I'm fully aware that ordinals started 4-5 years ago.

The idea? Yeah, the author claim he came up with it in early 2022.

Yeah, rodamor came up with it in 2022. It caught on in 2023. This is 2026, or 3-4 years later. I said ordinals started 4-5 years ago. I was not exactly precise with the dates. Is that important?

You talk as if Bitcoin Core is single person/minded group.

You need to do some reading.

https://www.citadel21.com/the-network

https://www.citadel21.com/vol21

[PrivacyG]

(endless drivel and personal attacks)

I have some tips for you.

Grow a thicker skin.  Any criticism you receive makes you put your hands up and play the 'personal attack' card.  No one is attacking you.  We are only challenging your ideas and claims.

[PepeLapiu]

Grow a thicker skin.

Believe me, I don't put my head in my pillow and cry when your dumb fucks resort to personal attacks.
You don't offend me, you annoy me. Because you use personal attacks to deflect and not engage in the actual subject.

I state that ordinals pay half of what monetary users pay in miner fees, and I ask what are the fees really filtering. And the answers are that nobody goes on my forum?

I point out that core though it's too controversial to implement an ordinal filter, but they still don't think removing the op_return spam filter is too controversial. And I get replies that tell me I'm delusional to think BIP110 will go through.

I point out that core devs work for those who finance them. They serve who pay their paycheque, not the nodes or the network. And I get told some other stupid personal attack.

You don't engage with anything I say. You just attack something completely unrelated to avoid the real subject.

[PrivacyG]

You don't offend me, you annoy me.

Why do you give advice but never follow it yourself?

But here is a few tips for you if you find me annoying.

Tip #2: Click the complaint button at the top right of this window. It looks like an X in a box. As soon as you click it, your complaint will be forwarded to the proper authorities.

-----

I state that ordinals pay half of what monetary users pay in miner fees, and I ask what are the fees really filtering. And the answers are that nobody goes on my forum?

I am pretty sure over half of us who responded on this particular Topic also responded to the other Topics you wrote on the SAME subject with the SAME questions and the SAME arguments.  You already got your answers.  Multiple times even from the same people.  But considering you are asking yet again the same things, my only option left to believe is that you are looking for the answers you WANT rather than our own.

We engaged in the actual subject.  I even answered your question,

Most of us collectively believe you are wrong.  Deal with it.  To me, Fees are still working as they were designed.  Some times it does not feel fair, but at the end of the day this is Bitcoin.  You want to be first, you pay.

ertil answered you the same question twice and you were STILL asking,

So if the fees are the filter, and spammerspaty half as much as monetary users, who are the fees really filtering out?

Of course users, that want to use 10 coins, instead of having 10-of-10 multisig, and using a single coin (and in case of Taproot, even a single signature).

Stop quoting irrelevent stuff with irrelevent replies. Quote the following and reply to the following:
If ordinal spammers pay half the price monetary users pay in fees, who are the fees really filtering here?

Those, who cannot consolidate coins properly.

Still avoiding the question:

Who seems like the actual dumbfuck when you are answered twice and still continue to ask?  You asked this question 13 times in this Topic and no matter what the answer is, it is either 'unanswered' or a lie.  Do you even want an answer or do you really like hearing yourself talking?

-----

I brought up your forum because you kept claiming the BIP-110 support was overwhelmingly high and we are only censoring it, you are acting as if you are so important Bitcoin Talk moderators have no other thing to do but to handle your butt from Board to Board to 'silence you'.  To me at least, the overwhelming support would have meant your Forum was filled up with a community outraged about what is going on.  What I found instead was silence and spam.

[ABCbits]

Nope, I'm fully aware that ordinals started 4-5 years ago.

The idea? Yeah, the author claim he came up with it in early 2022.

Yeah, rodamor came up with it in 2022. It caught on in 2023. This is 2026, or 3-4 years later. I said ordinals started 4-5 years ago. I was not exactly precise with the dates. Is that important?

Yes, when number you mention usually overstated or exaggerated. Last time you falsely claim 99% taproot are spammed dust, but some data/research shows the number quite lower.

You talk as if Bitcoin Core is single person/minded group.

You need to do some reading.

https://www.citadel21.com/the-network

https://www.citadel21.com/vol21

Sorry, but i don't plan to to read article with almost 10 thousand words. But no matter what point you trying to share, it doesn't change the fact i actually see some Bitcoin Core contributor/developer have different opinion that shared on either mailing or GitHub.

[PepeLapiu]

Here's some more gaslighting from liar/shitcoiner Greg Maxwell.

I explained how BIP110 will not confiscate any coin from anyone unless you are a spammer who is completely unaware of BIP110, and how at the very worst, you might see your coin frozen for a year or less, and even that scenario is so extremely convoluted that we all know it's not going to happen, here is what liar/shitcoiner Greg Maxwell replied in order to grasp at any straw to keep the BIP110 confiscation FUD alive:

For security some people have made transactions which are timelocked for the future, so that e.g. kidnappers can't force them to make payments or so that the transactions for inheritance will only be valid in the future.  After making the transaction they can delete their private keys so that they can't be forced to make any more alternatives, or they can simply lose them -- an eventuality that the presigned transaction was created to pay for.    

What liar/shitcoiner Maxwell is telling you here, is that if you delete your private keys, BIP110 might confiscate your coin

I guess Greg never heard of the mantra "Not your keys, not your coin".

I guess Greg is completely unaware that if you delete your keys, you lose your coin, and that has always been true for a very very long time. Every since bitcoin was created, every single sat on the chain stop being owned by you when you lose or delete your private keys.

No Greg, you shitcoiner.  If you delete your keys, BIP110 will not confiscate your coin. You already confiscated your own coin by deleting your keys.
:eyeroll:

[PrivacyG]

I explained how BIP110 will not confiscate any coin from anyone unless

I will not kill you unless..
I will not rob you unless..
I will not force you unless..

The arugment ends there.

[PepeLapiu]

I explained how BIP110 will not confiscate any coin from anyone unless

I will not kill you unless..
I will not rob you unless..
I will not force you unless..

The arugment ends there.

There is no circumstance under which BIP110 will confiscate anyone's coin.
Worst case scenario, your coin will get frozen for less than a year until BIP110 expires. At which point, you can get your coin back.

Unless you are dumb enough to delete or lose your private keys. But that is true for every single sat on the chain.

And here is what you would have to do to get your coin frozen or unspendable for the duration of BIP110, and all of the following conditions have to be met:

- You would have to be an advanced user who is making convoluted multisig timelocked inheritance scheme with the use of op_if in Taproot.
- Simultaneously have been living under a rock and completely unaware of the controversy and new rules.
- Be using an out of date wallet, or one that refuses to update to the new rules, therefore risking their users funds.
- Be making both the commit and the redeem parts of your tx within the BIP110 active one year period.

And once you have done all of the above, your coin will only become unspendable temporarily, and only until BIP110 expires.

Everyone knows no such user exists. Which is why liar/shitcoiner Greg Maxwell has to pretend you have to delete or lose your keys in order for BIP110 will confiscate your coin. But that has always been true for every single sat on chain.

[ertil]

There is no circumstance under which BIP110 will confiscate anyone's coin.

Of course there are such cases. For example:

Code:

first branch: OP_IF <timelockOne> OP_ELSE <timelockTwo> OP_ENDIF OP_CHECKLOCKTIMEVERIFY OP_DROP <AliceKey> OP_CHECKSIG
second branch: <timelock> OP_CHECKLOCKTIMEVERIFY OP_DROP <BobKey> OP_CHECKSIG

And then, when BIP-110 is active, Alice cannot move her coins, just because she used OP_IF (which is cheaper, than using a separate branch, and expanding the TapScript tree). Later, Bob can move these coins, just because Alice didn't spend them earlier. Which means, that if Alice swapped her coins with Bob, then Bob can end up with both coins, just because of BIP-110, which means, that Alice lost her coins, just because of that.

Worst case scenario, your coin will get frozen for less than a year until BIP110 expires. At which point, you can get your coin back.

This works only if there is one user for a given address. Which is not always the case, for example when you swap coins with someone else in a decentralized way. It doesn't matter, that later, the coin will be spendable by all paths. What matters, is that temporary freezing blocks one party, which means, that the second party can just get all coins, just because of waiting, without any consequences. Normally, the first party could react, and sweep coins earlier, because of smaller timelock, but because of BIP-110, it is blocked.

Unless you are dumb enough to delete or lose your private keys.

You don't need to lose your keys. All that is needed, is to have any coin with OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY. Then, they are blocked for a given time, and knowing the private key won't allow anyone to move them faster.

You would have to be an advanced user who is making convoluted multisig timelocked inheritance scheme with the use of op_if in Taproot

Well, BIP-65 was created in 2014. Why you assume, that something, which is known for at least 12 years, is "advanced"? It is even older than Segwit!

Simultaneously have been living under a rock and completely unaware of the controversy and new rules.

It is more likely to know about transaction locktime, which is decades old technology, than about BIP-110, which is supported only by a small minority.

Be using an out of date wallet, or one that refuses to update to the new rules, therefore risking their users funds.

Which means just "not using the latest Knots version", which applies to most users.

Be making both the commit and the redeem parts of your tx within the BIP110 active one year period.

If some coins are timelocked, then they cannot be moved earlier. And if there is a multisig, then another party may disagree, to sign a second version of the transaction, or can be simply unavailable. And then, Alice will have locked coins, just because she doesn't know the Bob's private key (which is normal in multisig scenarios).

And once you have done all of the above, your coin will only become unspendable temporarily, and only until BIP110 expires.

Which doesn't matter, if the second party will sweep the coins faster. You will have coins locked to October, someone else will have coins locked to December, and your "October transaction" will be rejected, because of BIP-110, so "December transaction" will sweep all of your coins. Great.

Or: if all parties used OP_IF, or something similar, then all coins will be locked, and then it will be just "Speedy Gonzales chain", where each party will try to bump fees, and get coins, before another party will do that. Which means, that the chance of getting coins by the honest player, will be just like a flip of a coin: you will get it, only if you will be lucky, and if your transaction will be confirmed earlier by miners.

Everyone knows no such user exists.

Multisig doesn't exist? Locktime doesn't exist? Or maybe BIP-65, known since 2014, doesn't exist?

Also, it reminds me of a "login forum problem", where some admin was surprised, that no user wrote any post about a problem with logging in. When scripts are hashed, or hidden behind Taproot public keys, then you don't know, how many of them are there. Maybe there are such users, but your node just actively filtered them, and rejected their transactions? If you close your eyes, then of course you won't see anything.

[PepeLapiu]

Unless you are dumb enough to delete or lose your private keys.

You don't need to lose your keys. All that is needed, is to have any coin with OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY. Then, they are blocked for a given time, and knowing the private key won't allow anyone to move them faster.

Correct. You won't be able to move the coin any faster. But your coin would be unspendablebfor the duration of BIP110 (one year) after which your coin becomes spendable again.

Epstein/Blockstream/shitcoin Maxwell makes the case that you would have to delete your keys for your coin to not be spendable after BIP110 expires. And he is correct. But that also applies already for every single sat in chain since the day bitcoin was created.

You would have to be an advanced user who is making convoluted multisig timelocked inheritance scheme with the use of op_if in Taproot

Well, BIP-65 was created in 2014. Why you assume, that something, which is known for at least 12 years, is "advanced"? It is even older than Segwit!

The rule only applies to op_if in Taproot. Use of op_if outside of Taproot will not be affected. And Taproot was implemented 5 years ago, if I recall?

Be using an out of date wallet, or one that refuses to update to the new rules, therefore risking their users funds.

Which means just "not using the latest Knots version", which applies to most users.

You are wasting my time. Users don't need to run a node (Knots or otherwise) to make a tx with op_if in Taproot. The oy wallet I know that does make use of op_if in Taproot is Nunchuck. And only users who use an old Nunchuk wallet, or a Nunchuk wallet that refuses to upgrade to the new rules would be affected. And if so, only for the duration of BIP110.

Be making both the commit and the redeem parts of your tx within the BIP110 active one year period.

If some coins are timelocked, then they cannot be moved earlier. And if there is a multisig, then another party may disagree, to sign a second version of the transaction, or can be simply unavailable. And then, Alice will have locked coins, just because she doesn't know the Bob's private key (which is normal in multisig scenarios).

Now you are just being dishonest and throwing any bullshit at the wall, and hope some of it will stick.

And once you have done all of the above, your coin will only become unspendable temporarily, and only until BIP110 expires.

Which doesn't matter, if the second party will sweep the coins faster. You will have coins locked to October, someone else will have coins locked to December, and your "October transaction" will be rejected, because of BIP-110, so "December transaction" will sweep all of your coins. Great.

More unrelated bullshit thrown at the wall. Nobody is doing multisig with an other person and using op_if in Taproot.

Everyone knows no such user exists.

Multisig doesn't exist? Locktime doesn't exist? Or maybe BIP-65, known since 2014, doesn't exist?

Strawman. That's not what I said.
There are no users who are advanced enough to use Numchuk (or other fancy complex wallet) to make some convoluted inheritance scheme with op_if in Taproot, while simultaneously living in a cave for the last year, not being aware of the controversy and new rules, and simultaneously be using a wallet that doesn't update with the new rules, and simultaneously be throwing away his public keys.

Also, it reminds me of a "login forum problem", where some admin was surprised, that no user wrote any post about a problem with logging in. When scripts are hashed, or hidden behind Taproot public keys, then you don't know, how many of them are there. Maybe there are such users, but your node just actively filtered them, and rejected their transactions? If you close your eyes, then of course you won't see anything.

Stop gaslighting. Any older op_if in Taproot will be grandfathered in. Newer ones confirmed after BIP110 activation might become unsoendable for a temporary period until BIP110 expires.

[gmaxwell]

Private timelocks in bitcoin are accomplished by authoring a locked transaction that won't be valid until later, then tossing the key that paid to it.  This goes all the way back to Satoshi.  The toss-away might be intentional and immediate, or it could just happen as a result of the loss/failure of a device for which the timelocks are a backup.

Until we introduced CLTV it was literally the ONLY way to timelock coins.

They're used to address a fundamental tension that if you make your coins very secure against theft, kidnapping, hacking, seizure, etc... you have a very real risk of making them so secure that even you can't get them.  The fix is to also make your coins available via less secure means but only after a long time delay, so that you can move them away using more secure means unless you've lost access to the more secure means.

Today traditional timelocks are still usually the best way to timelock your coins for maximum efficiency, privacy, and avoidance of blockchain bloat.  It lets you construct an unlimited number of alternative release conditions, and someone who holds one can't tell the other exists and the creator has no way to prove alternatives don't exist even under duress.  So e.g. if someone kidnaps you and demands access to coins they know you have, you can say "look the only way to get them is with this transaction that pays them to a 47 person multisig and is only valid 10 years from now-- you're SOL" and there is no way for them to tell that buried in your back yard is an already mature (timelock passed) backup release that sweeps them to a 2-of-2 cosigned with pet chihuahua.

CLTV is most useful for when you need the timelock to NOT be private, e.g. because you have a counterparty that needs to know there is no alternative-- as is the case with lightning.  For that special usage the traditional timelocks have issues because the counterparty can't be sure that you threw away the coins.  Or at least can't without using 2P-ECDSA or schnorr-- which weren't available at the time CLTV was created-- now that they do thats a wider class of cases that can use the traditional timelocks (and potentially should since they're more private and blockspace efficient).

CLTV is also not exclusive with traditional timelocks-- especially with taproot it can be useful to use both-- and use the more private and efficient timelock paths if you can, and use CLTV leaves if you must as CLTV's have the advantage that you can use one time backups that never need to get updated.  Though even if both are used taking away *some* of a person's redeem paths may functionally take their coins because you've taken away the ones they turn out to need-- the whole reason people have multiple ways to get at their coins is because once they've made them very secure it might turn out that some ways don't work later, like they made a multisig with too many signers that lost their keys. or, in the case of an 'eventual timelock' where the key was kept but not backed up, breaking the timelock takes away their coins in the event they were needed.

But in any case, most usage of CLTV involves conditionals in script which get blocked in 110-- and unconditional usage w/ bip110 is very limited because to eliminate conditions you have to expand out every possible branch into a different leaf (blockspace inefficient!) and bip110 limits to 127 leaves and so that conditional elimination approach cannot be used when there are more than approximately 7 conditions (as 2^7=128)-- it's easy to get that many conditions with multisig, since 10 choose 4 or 6 is 210.

And more critically: Even if using traditional timelocks was dumb (it isn't!), and even if CLTV did everything they do (it doesn't!), and even if 110 didn't hobble CLTV (it does through restricting conditions and tree sizes!) -- we'd still be left with the fact that people today do use traditional timelocks, and BIP110 effectively destroys their coins.  Even if you had a way to notify all of them and even if they understood the risk (in spite of BIP110 authors and advocates making deceptive claims about them), and even if they wanted to stop, they can't necessarily because of the nature of timelocks. And even if you are unable to understand their needs and think they are dumb-- YOU DO NOT GET TO TAKE THEIR COINS.

I'd slam you for your lack of ethics, but the fact that you think that segwit was the first softfork betrays such profound ignorance and indifference to technical details that I doubt you have the capacity for ethical reasoning to begin with.

At best you can say is that the limitations of 110 are "temporary"-- except the creators of BIP110 have been completely clear that they expect its limitations to be perpetual "on the installment plan", using their authority over their fork to regularly reimpose equivalent limitations.  Taking someone's coins even temporarily is still theft and leaves them exposed to permanent loss as other timelocks become valid[1], but it wouldn't actually be temporary here.

110 can also be viewed as a referendum on this meta issue:  is it acceptable for a mob of angry Bitcoin users to invalidate existing script patterns and take away functionality? Is it acceptable to force people to dig up and move coins before the functionality they rely on is revoked?  Is it acceptable that if people have used sophisticated security such that they're not able to move their coins in time, or if they're not paying attention, or if they've been deceived into thinking they won't be impacted (by the proposals authors and proponents, in this case!) that they lose their coins?  Is it acceptable for those coins that escaped 110's blocking to be potentially exposed to loss in a future update intended to block some other 'spam' as part of the inevitable next step in a fruitless and never-ending forever war against the free flow of information? That anyone's ownership of Bitcoin becomes ultimately conditional on some unpopular user's transactions looking a little too much like theirs? That your coins are safe only if you manage them in the same way as the least sophisticated majority of users and so long as you never do something somewhat unusual and if your usage itself doesn't become the target of popular ire?

The answer to these questions must be NO. It's not acceptable to do these things intentionally. Bitcoin was created in response to weaknesses like these in the systems of traditional finance and Bitcoin's security against third party control over your money has been advanced as a primary value proposition since day one.  Every owner of Bitcoin has a right to these properties and to undermine them is to take something of great value from all Bitcoin's users, including those who won't actually lose their coins from this specific proposal.


[1] an example 'backup inheritance' techniques I've seen advocated is timelocking your coins to some key included with the timelock transaction but with the date set way far in the future-- basically creating a bearer release such that if all other security measures are unavailable someone someday will be able to get the coins.  But that means that if someone delays your access through other means long enough a hacker or safe-deposit-box-raiding-state-official who has obtained this last resort release can just steal your coins.  If not for 110 after your last resort backup got stolen you'd just use a transaction with an earlier release time (but stricter security rules) to sweep your coins away before the last resort matured.

[PepeLapiu]

Finally you reply. About time. However, I find it amusing that the tittle of this thread is "Questions for Greg Maxwell" and you finally get around to reply, but you completely ignore the 3 questions I asked in OP in bold for you not to miss them.

Private timelocks in bitcoin are accomplished by authoring a locked transaction that won't be valid until later, then tossing the key that paid to it.  This goes all the way back to Satoshi.  The toss-away might be intentional and immediate, or it could just happen as a result of the loss/failure of a device for which the timelocks are a backup.

So you are saying locking your coin into a multisig and the coin gets locked for a specific amount of time, while you delete your keys, that is nothing new. That it could be done since the very beginning.

Gotcha!

We were sold on Taproot with the ideas of increased scaling and increased privacy.

If op_if is widely and most exclusively used by spammers to shove their garbage dickpic.jpeg in Segwit for free, that is the opposite of scaling. And that is the opposite of scaling. We are effectively displacing monetary transactions with dickbutt.jpegs. And we are making blocks bigger than they should be during low activity periods.

When you use op_if inTaproot, you end up pushing a whole bunch of data on chain. Spammers like that, that is exactly what they want - push their data on chain.
But monetary users are doing the reverse. They are pushing data on chain that don't need to be on chain. And they are making their privacy set worst, not better.

I strongly believe there are no monetary users who are making use of op_if in Taproot.

Such user would have to be advanced enough to make those convoluted time locked scripts, while deleting their keys, and simultaneously living in a cave and being unaware of the controversy over op_if in taproot, and being unaware that BIP110 removes that feature.

And even if such monetary user did exist, he would have to be using a wallet that does not enforce the new rules, either because the wallet devs are wreckless, or the wallet is out of date. Than he would have to make both the commit and the reveal occur during the one year of BIP110 activation.

And even if any monetary user finds himself in such an unlikely situation, he would only lose his coin if he deleted his keys. Which is a really stupid thing to do in the first place.

In the past, elsewhere, you have claimed that you are such a user. But you are not. Unless you tell me you are stupid enough to ignore the fork, and commit your coin with op_if in Taproot after BIP110 activates, and do the redeem before BIP110 expires, and also throw away your keys.

I know what you look like. With those looks, I would hope you are more intelligent than that.

But the reality is that BitcoinMechanic posted a video on YouTube, explaining all that, and inviting people to debunk him. You did not attempt to debunk him. You would not engage with him or with Luke anywhere on any platform. Because just like you ignoring my OP questions, you are avoiding Luke and Mechanic because confronting them would expose your agenda just like answering my questions in OP would expose your agenda.

Op_if in Taproot needs to be removed because it causes more harm than good. It would have been so much easier if the core/block stream/Epstein class did their jobs and fixed the problem when it first started. They didn't. Instead you all got busy lying to to community and proclaim that the fees are the filter, and the only filter required.

And so, because of the incompetence (or corruption?) of the core/blockstream/Epstein class, correcting the problem is now more difficult after 4-5 years of ignoring the problem.

YOU DO NOT GET TO TAKE THEIR COINS.

Your coin will only vanish if you are dumb enough to delete your private keys. Not your keys, not your coin.

Otherwise, if you are dumb enough to do an op_if in Taproot with both commit and redeem during the 1 year of BIP110, your coin will be available for you at the other end.

BTW can you find anywhere on the internet a tutorial that teaches people to do an op_if in Taproot and advises people to delete their keys? And would this tutorial have been published before or after BIP110 was announced?

[CoreRulezKnotsAreFulez]

How do we know that is your transaction and not one you just found on a block explorer?
Can you sign a message from bc1qrs8s7jvmyp5s4677udme6nt0cl4xuuqe2aj8m2

Sure thing. But I don't have access to my laptop for at least a few weeks as I'm away from home. How about I spend 1000 sats from the change address which is bc1q3n02lvaa3v38wxvsh4usk4fpxd3w6af2cn75gh

Would that satisfy you?

I don't think it's that important anyways. ertil is just wasting time with that stupid idea.

"You could just do a coinjoin and save as much as the spammers do."

Okay, so what would stop the spammers to do a coinjoin and save ever more than they already do, fool?

If you can send from the the change address you should be able to sign a message from the sending address.
Laptop or not as the change address is part of the same wallet.

I just got back from 2026 BTC Conference in LV. There was no support for 110. No miners, no exchanges, no pools. There were some people pushing it and they all got laughed at or ignored. Nobody cares for it. Best way I heard it was more or less let them put the money into mine a couple of hundred blocks showing 110 support over the next few months then I'll look at it again. But now I just see social media and nodes both of which are just about zero cost. Even back in 2017 fork the people on both sides were spending a fortune to prove their point, here 110 is just talking.
Not the exact wording but close enough.

Still waiting for you to prove you actually own the bc1qrs8s7jvmyp5s4677udme6nt0cl4xuuqe2aj8m2 address.

https://www.walletexplorer.com/address/bc1qrs8s7jvmyp5s4677udme6nt0cl4xuuqe2aj8m2
https://www.walletexplorer.com/wallet/02037bdf6c7a0e62

Not that anyone really cares. Your fork is never going to be the main chain.

[PepeLapiu]

Still waiting for you to prove you actually own the bc1qrs8s7jvmyp5s4677udme6nt0cl4xuuqe2aj8m2 address.

Why would I do that?

Not that anyone really cares. Your fork is never going to be the main chain.

None cares to see it, and I don't care to show it. Looks like we are in agreement.

[CoreRulezKnotsAreFulez]

Still waiting for you to prove you actually own the bc1qrs8s7jvmyp5s4677udme6nt0cl4xuuqe2aj8m2 address.

Why would I do that?

Not that anyone really cares. Your fork is never going to be the main chain.

None cares to see it, and I don't care to show it. Looks like we are in agreement.

Because you are a liar and scammer.
Quote from you:

You are making shit up and/or trying to the derail the conversation.
Here is my last transaction with Segwit:

https://mempool.space/tx/74d6d05d7d013be3bb547a56fe36951543df024a89f5f8f90445826a08ad6cf5

One input, and two outputs, with a 34% Segwit discount. This is a typical pleb monetary transaction. I would guess that over 95% of monetary transactions with Segwit look like this: 1-2 inputs and 1-2 outputs.

Some random internet person:
Prove that is your transaction. Sign a message from the sending address.

You: Wahhhh I can't.

As a few people have said, you have no bitcoin, so you are just out to destroy it for spite.
You fled Canada since you have no money and ran away from all your debts.
Looking around it seems you tried to scam money from people here too claiming to need seed money.

https://bitcointalk.org/index.php?topic=5516206.msg64688036#msg64688036

You are a useless piece of scamming shit.

So fuck you.

[PepeLapiu]

You are making shit up and/or trying to the derail the conversation.
Here is my last transaction with Segwit:

https://mempool.space/tx/74d6d05d7d013be3bb547a56fe36951543df024a89f5f8f90445826a08ad6cf5

One input, and two outputs, with a 34% Segwit discount. This is a typical pleb monetary transaction. I would guess that over 95% of monetary transactions with Segwit look like this: 1-2 inputs and 1-2 outputs.

Some random internet person:
Prove that is your transaction. Sign a message from the sending address.

You: Wahhhh I can't.

The whole point was to show a typical monetary tx done with Segwit. You don't need to know who owns the address for that. Who owns the address is completely irrelevant to the point I was making.

[CoreRulezKnotsAreFulez]

The whole point was to show a typical monetary tx done with Segwit. You don't need to know who owns the address for that. Who owns the address is completely irrelevant to the point I was making.

So you admit you don't have the coins you said you had. Just another lie to come out of your mouth.

Scammer.

[gmaxwell]

Why would I have commented-- everything else was already answered by me before, by other people before, and by other people in this thread before I commented.   What wasn't addressed in this thread was your continual misrepresentation of classical timelocks.  And honest party would acknowledge the explication and the limitations of their proposal in that situation-- but strangely you continue to just lie and gaslight about it.

All you're doing is making 110 look worse by making it clear that its proponents are not prepared to deal honestly with its downsides, so perhaps I should just follow the old advice of never interrupting an enemy while he's making a mistake.