As much as i think inscriptions are retarded, this fact is just an economic reality.
Login to reply
Replies (69)
I think the only thing we can do is price them out
nevent1qqsgxz9e2mr95mtcjmxpuguctl7l9rj5tm370nwe2l0ldmdmr74du3s24ymaa
But do we need to make the path wider?
I think that would be cool too and likely a good way to deal with storing arbitrary data on chain. And I would say if we want to go down that path, it would be good to establish an environment that is adversarial to arbitrary data in every stance.
What’s in that relay policy that blocking economy motivated transactions? Can I read it somewhere ? The policy
I don’t know what he’s talking about but I know he means it 😂✌🏼🧡
View quoted note →
One question I have is increasing the limit how much does the Bitcoin chain size grows and does it become much more difficult to store in a home node
It needs and 80bytes or Die sticker
there is a blocksize limit, but it is subtle. Storing data in op_returns would actually decrease average blocksize since it is not discounted in segwit. This is the whole block weight concept introduced by pieter wuille.
This is why inscription jpgs are included on the witness input script stack, to get the witness discount (an unintended spam side effect of segwit)
The whole op_return narrative is weird, since if you want to store large images you would’t even use op_return, and the core v30 changes have nothing to do with that because data carrier settings don’t look at the witness stack.
I think luke tried to PR a mechanism for detecting inscriptions and including that in the data carrier size, but it would have confiscated peoples money for transactions that looked like spam but were actually legitimate.
this would have also created a cat and mouse game of various ways to match input script templates to try to get around every inscription variant, leading to an OFAC banning mechanism to bitcoin.
nevent1qqsza8m029sye43ksllqtsxwey9a7cvt6cthxuxwy3yu4l2j8ytegacjc5t0p
I wonder if removing mempool filters would actually help remove an incentive for large centralized pools. 🤔
After all, it's only the big guys who can afford to host out of band services and have built themselves an additional revenue stream.
Nah. You can use bitcoin-cli to add a tx to a mempool. It's way easier than it seems.
Not everyone can develop slipstream though right? As in an easy interface for anyone to use to get out of band txs submitted to a pool.
You don't need slipstream. You can just email or send hex over telegram.
And plenty of people could develop slipstream. It accepts some hex. Does some checks and then is inserted into a mempool.
Someone could also create an entirely new relay/gossip network that bypasses node relay entirely. Would be a decentralized way to get around filters that miners would be incentivized to connect to
You mean like this:
I published my first rust library yesterday: https://crates.io/crates/bitcoin-nostr-relay
You can test it out in this playground environment:
https://github.com/vnprc/tx-relay-playground
I think this approach solves the filter debate by dismantling the bitcoin core architecture into separate components. Bitcoin core should be used only for blocks and blockchain consensus.
It is bad architecture to combine TX relay and block relay into a single binary with a single peer-to-peer network. It opens the node to many DOS attack vectors. It open the developers to social attack vectors. And it forces unnecessary constraints on bitcoin transactions (mempool policy) that severely limit what developers can accomplish with off-chain protocols like lightning.
Why continue down this path when alternatives are available?
I intend to continue developing permissionless software solutions to enable sovereign pool operators to meet and exceed the capabilities of large, closed source pool operators.
View quoted note →
Lol
Thats actually a neat idea… would save core from these filter debates all the time. Although i think core is still better at maintaining relay since they got big brains thinking about adversarial networking
You only need to develop it once if it's open source
Is it open source?
Slipstream is not. It's replacement will be
How is this not the nail in the coffin for knots filteroors
As long as there are a few of these running knots is effectively pointless. I mean it always was but it would even be moreso.
Any wallet could just connect to the libre tx relay network.
What we appretiate is that you show your incompetence publicly.
BSV shitcoin made the same change that core 30 intend to do (allowing 100KB in OP_RETURN) and got flooded with CSAM on their chain. This change is an ATTACK on Bitcoin.
View quoted note →
this can happen today, especially with relay tools being built outside of core or knots
I knew you will say this because this is the nonsence you repeat. At this point its completely retarded.
Truth is in the video. But I will give you some technicals because you seem to not understand them.
Old methods of storing evil stuff required obfuscation: they would need to break it up into multiple chunks and reassembly would require specific software and knowledge of what the data is and how to reconstruct and interpret it exactly.
The old formats looked like this:
"Hi, I'm a Bitcoin transaction, here's my first output of 45 outputs - <filepart1>, here's my second output <filepart2>, here's my third output<filepart3>" along with a tonne of other stuff that has to get parsed out when processing the highly obfuscated material. This is thankfully also true of inscriptions.
OP_RETURN however is just a dump for raw, serialized data. It's not the same.
It says the equivalent of "Hi I'm a Bitcoin transaction, here's an unspendable output: <file> end".
This wasn't a problem for tiny OP_RETURNs i.e their current limit of 80 bytes.
If they're permitted to be 100kb, that's where the abuse begins.
And that's the end of plausible deniability.
When the stuff gets processed - which it has to be for your node to verify that they are valid transactions - then you just have a raw, unadulterated file that will trigger primitive antivirus/forensics software to alert the user: "Hi, you have CP on your computer."
You now need a licence to run a Bitcoin node, everyone thinks you're disgusting if you do, and they're not even wrong.
View quoted note →
Because even with a secondary layer of Tx relay, current Knots users would not relay txs they don't agree with. You still don't seem to understand property rights after all of these repsonses.
They would still relay it, just 10 minutes later
Lol, I swear you wrote a bot to reply without reading and understanding what is being said. Read again, and think for longer.
I read it perfectly. It’s a fact that once it is inevitably in a block that your node will start relaying that exact transaction you already downloaded and rejected from your mempool 10 minutes earlier.
Oh weird, I didn't know that unconfirmed transactions are saved in the exact same spot that confirmed transactions are. Can you show me that data table because I was under a different impression.
Of course, you wouldn't be conflating the two, right? Because that would be absolutely silly.
Especially in a paradigm where we don't use the gossip relay network and we use something else. Those would be two entirely different programs. So there's no possible way that an unconfirmed transaction would be co-mingled with a confirmed one.
your node relays blocks, once its in a block you will start relaying it to peers. This is basic stuff
Again, you can't read or something. That's not what I'm talking about. This is under a thread talking about a separate relay network. Maybe you're reading this on Damus where it's very difficult to understand where the threat is going or where it's been.
The two relay networks just serve the purpose to get txs to miners. The block is still gets relayed to all knots and core nodes. I don’t see whats complicated to understand here.
nevent1qqsgdcm23slfg6seqlhwkv26es9w394gkl0y4mdcz6nuk4pu75wajggw3j8rr
I'll type this in ancient Odell script so you might understand.
BLOCKS AND UNCONFIRMED TRANSACTIONS ARE NOT THE SAME THING.
Do you think that statement is true or false?
Of course they are not the same, but for the purpose of “will i relay this tx” at the end of the day they are the same, just different timing.
True. Not complicated. The real crux of the debate is people don’t want that shit in the chain at all.
Right, i agree with this, but relay is not the place to solve it
Ok so if we agree there, let’s move forward and try to find a real solution
Do blocks= txs?
You see, I don't have a choice on whether to relay a BLOCK but I do have a choice whether to relay a single TRANSACTION.
So, an analogy:
If I deliver packages and letters but a letter comes through witha giant dick drawn on the face of it. I can mark that letter as "Undeliverable" and send it back to sender.
BUT if that SAME LETTER is in a box with a bunch of other letters I MUST deliver the box even if there are bad letters inside. I am fine with this as it doesn't break my delivery rules.
The problem is that you would have to censor coin *spends* to censor witness jpgs, which I can’t imagine we will ever do
sounds like a lot of cope when you will end up relaying the tx regardless, but i guess if it makes you feel better somehow then sure
Definitely not. But what about within the scope of OP return? While not perfect, we should at least be directionally moving towards this usage being harder not easier. That’s another sentiment most Knots users have which Core doesn’t appreciate.
I haven’t gone through the entire history of Bitcoin but to be honest, I speculate there already is a lot of stuff on-chain which is potentially illicit. Filters are never going to be perfect but giving up is also not acceptable.
We could hardfork a hard cap to its size, but it would just push people to solutions that would bloat the utxoset which could be really bad
So to review you conflate two separate things, you say something is inevitable despite the goal is never stated, then because you can't comprehend people not applying information theory to the hacking of a monetary network, they are "coping". I am crazy to keep talking with you, I need to really stop doing this.
Or you could return to the original usecase and remove OP_RETURN from standardness.
I’ve never understood the bloat argument. If you have a block full of 4,000 monetary transactions, doesn’t that ‘bloat’ it just as much as 4,000 spam transactions? Is it an issue due to the amount of dust addresses spam creates?
Also, uncapped OP return allows for decently big JPEGs to easily get on chain. Do other methods of embedding arbitrary data also allow for that size?
The "set" of UTXOs would be larger if packed into pubkeys (multisigs where the pubkey outputs are the actual data not "real" keys)
This puts more demand on your node from a validation and storage perspective. This means it's more expensive to run a full archival node.
OP_RETUN data can be pruned as it has no effect on the chainstate.
no, op_return are provably unspendable, meaning you can prune them from the utxoset. If you store data in bare pubkey outputs (like the butcoin whitepaper): These are *permanent* and you have to store them forever, even on pruned nodes, since you can’t prove they are unspendable. This would be a growing fixed size burden for pruned nodes which is really bad.
Thats why encouraging op_return for data is a good thing, even if it’s not the most economical compared to witness data.
Let’s get a setting where you can prune all of it
And yes most jpegs are stored on witness stacks for the witness discount, not op_return
Got it. Thank you. So if OP Return data is harmless and can all be pruned, how can users remove it all from their nodes?
It is removed automatically from the utxoset, but its still in blocks
Being in the blocks is the issue though. Do you believe there is nothing which can be done about it?
of course you could try to do something about it, but it would have to be pretty heavy handed, require hard forks, and have lots of complicated rules to try to censor any form of data looking transaction.
But again it would just push people into using steganography and hiding data in keys (utxo bloat) which would be impossible to detect automatically.
Its a censorship resistant network, i don’t see how you’re going to stop people from spending money to get these types of transactions in
I think our best leverage is to price it out via legitimate usage and perhaps a small block hardfork
I like small blocks. I can’t see it ever happening. I’ll continue to run core version 25.1.0 for now. I appreciate your time and effort.
We should’ve scaled slower, lightning allows for billions of transactions a year which has pushed the cost down so low.
> legimita usage
Lol.
Whats funny? I don’t think spam and jpegs are legitimate usage of bitcoin, but i also accept i can’t stop them.
It's funny that there should be some legitimate usage for Bitcoin.
Teleportable gold man its pretty cool
It bought you a pin at Bitcoin Asia the other day the whole rest of the trip was paid in fiat.
Yes i also agree we should be trying to make it a medium of exchange and not just a store of value, since that should help adoption and get freedom units in the hands of more people
You've been trying for 15 years.
Lessee how @vinney...axkl goes with his bookshop.
I mean gold has been trying to be money for centuries and it kept getting corrupted, maybe an incorruptible alternative could work.
Maybe pigs can fly.
I think the Knot's folks believe the marginally more expensive economic hurdle (to go out of band) makes an impact to reduce non-monetary tx's, and that with larger adoption of a loose consensus of such deterrents, the effect would grow towards an effectively full deterrence (or much greater than now). It's a valid argument and hypothesis, and I'd like to see it tested, not talked down as not a valid hypothesis.
I think you’ve identified the problem
You can get 2TB now for not more than 100 bucks and that would be sufficient for several years. So it's a non-issue.
I have 2TB now and it is an issue if the speed at which the chain grows increases.