Topic: Segmenting/Reserving Block Space (Read 433 times)

you seem like people sit around figuring out ways to spend their money inefficiently to store data on the blockchain. they don't. they never did and it never caught on.

but when you come along and introduce a 75% off sale (aka segwit) and then tell them they can store unlimited data into their 75% off transaction fee, well, why WOULDN'T that cause a problem?  

so go right ahead. store the entire king james version of the bible onto the bitcoin blockchain using OP_RETURN. see if anyone cares or complains. the only one complaining will be YOU. because it costed you so much money.

Then you have again the same problems as if you "ban" OP_RETURN and Taproot. People will create, mint, and transfer tokens with fake P2(W)KPH transactions.

You have to think again about such authoritarian measures: they simply don't work in a decentralized network if there is an alternative which is allowed.

Even if vjudeu's method to identify spendable public keys works, these keys could be still faked, you only have some more restrictions in the "number space". Imagine a sort of "VanityGen" for public keys. You could even store the information in a private key, and compute the public key from it; this would make a transaction technically "spendable". Nobody stops you from publishing private keys if they are only used for information storage.

it can't be something people can opt out of or have to opt in to. It should be something that happens automatically based on their transaction type.

these people buying ordinals need the illusion that their data is being stored ON the bitcoin blockchain though. a sidechain would probably not really matter to them. most of them wouldn't even be technical enough to understand what was really going on. that there was a main chain and a side chain and the side chain is where all the bloat transactions got put... and not everyone that ran a node stored the sidechain.

i don't know how that would work where you could tweak public keys and signatures to store monkeys. i'm talking about with legacy type transactions. surely people could try but it's going to be expensive i would imagine! because they would have to do alot of transactions. that's why it never caught on in the first place i would imagine.

but anyhow i think you know more about some of these technical details than i do  

Yep, that's "in theory" the way I'd approve to take NFTs out of the Bitcoin blockchain. There was a quite elaborate proposal called L2O (website: https://l2o.io/) describing even a method to take BRC-20 tokens out to a sidechain (a zk rollup) and it would continue to "live" there.

I wrote "in theory" however because the problem the stubbornness of the Ordinals community to insist on their NFTs being available on "OG Bitcoin". The value proposition of these tokens and NFT collections was very much tied to the fact that they were stored on the Bitcoin blockchain. There are lots of cheaper chains, and I believe Litecoin or Dogecoin are nearly as secure as BTC when it comes to long-term availability, but the LTC and DOGE Ordinals spinoffs never really took off.

Ordinals NFTs are however much less of a problem now than in 2023 and I believe at least Ordinals is about to die (see particularly the post-halving stats, total Ordinals size on the Bitcoin chain since then is less than 10 vMB per day, which is equivalent to a little bit more than two blocks). Runes may be a little longer around, but they seem to have been a very short hype (most runes are already making losses only days after the halving).

It is not needed. You can just point to any 256-bit value, for example into R-value of some signature, and then reveal your commitment on a separate chain. Because if you create "OP_RETURN ", then everyone will know: "hey, that transaction may have a monkey or something". But if you point to the R-value of your signature, then nobody knows that, it is then just a regular payment, and you know, that anything is committed to that, only if you connect to the separate network.

Quote

and the only increase in disk space they would see is one single extra hash from the M BLOCK

This is another reason, why tweaking public keys and signatures is better: in that case, the size of your transaction is left unchanged, so you can keep all amounts, inputs, and outputs the same, which is important, because then you don't have to calculate both cases: "with the monkey" and "without the monkey". You only prepare one transaction, and just tweak your signatures accordingly.

you could something like this:


MAIN CHAIN: BLOCK 456...BLOCK 457....BLOCK 458....

SIDE-BLOCK WITH MONKEYS: M BLOCK 456...M BLOCK 457...M BLOCK 458

BLOCK 456 would contain a hash of M BLOCK 456 and so on. But people running nodes and such could elect to not download the M BLOCKS. and the only increase in disk space they would see is one single extra hash from the M BLOCK. don't care about the monkeys and dont want to download them, then don't don't verify their hash. because you don't care about them and that's ok!

i call this the "segregating the monkeys" method.

The few problem seems to be an enduring one especially with the fact that, it fluctuates just like we’ve got with Bitcoin too, where the volatility on it would determine price.

Space reservation though as presented to solve fee problems might seem like a good idea but,
Bitcoin is just Bitcoin in the end. It’s the network and what it charges that we are really looking at here and what is it really at the miners end when a transaction is initiated, is there really a segmentation, I don’t think. This would make having to separate or decide an issue that shouldn’t even be as Bitcoin is only still Bitcoin.

Perhaps further developments as per having quick transaction broadcast would require another separation of the block spaces too, Bitcoin doesn’t need that, I think.

potential doesn't mean it will definitely do that. so you're working off of a possibly fault premise which could lead to all kinds of questionable judgements and conclusions.

but do you really think that segregating transactions into categories and trying to enforce quotas on each category within every block is a reasonable thing? apparently it's a genius idea and it's all we've been needing this whole time but no one thought of it until now.   now all you have to do is get it done.

imagine being willing to destroy your whole cryptocurrency just because of some monkeys popping up here and there.

Susceptibility of what has the potential to be the backbone of the global monetary system to what are effectively DDOS attacks is a small problem in your opinion?

I'm guessing you're probably pro-ossification lol.

if you disagreed with it then what made it worth reading exactly? to me it seemed like trying to go way overboard and hard fork bitcoin just to solve a small problem. the "cure" is worse than the disease if that makes any sense. you really want to change the entire structure of bitcoin blocks and require a hard fork just because of some monkeys? how is that worth even discussing?

i'm not against throwing a few merits to a new user trying to make contributions through their ideas just in this case, he's way off. try again, i would say. 

I think LN is still the "primary" approach in the Bitcoin community itself. It has a few problems though, for example the replacement cycle attack, which still make it unsuitable for larger payments.

Sidechain projects and concepts I know of, which are not federated - i.e. centralized management by a static multisig "federation" of users - are:

- Drivechain (problem: needs new opcode, is not well liked by some Bitcoin Core devs)
- Stacks (if everything works well it will be rolled out this year, problem: has a premined token for consensus)
- Nomic (already live, but the peg bridge is limited because it's in an audit process, has also a premined token for consensus)
- Forum user @vjudeu seems to be developing some sidechain too but I think it is still not public.

Federated sidechains are primarily Elements and RSK, which are live already for years.

Then there is the rollup concept, where the data is stored on a sidechain and on mainchain in a compressed form. It already works well on Ethereum, but the popular projects (for example, Optimism) also have premined tokens. On Bitcoin it would probably also need new opcodes. There's an info website for rollups on Bitcoin. I read recently that the Avail project is about to launch on Bitcoin.

There is also the extension block concept, which afaik was implemented in Litecoin for the Mimblewimble privacy technology. It's also a kind of sidechain. It was rejected however in 2017 when it was proposed for Bitcoin as an alternative to a block size increase.

Premined tokens is a problem because it makes the project centralized in some way, there will always be a founder group which is able to extract profits. This is a bit against Bitcoin's ethos, and thus sidechain concepts (except Drivechain) are mostly viewed as "altcoins" by many Bitcoiners. What I could imagine however, as most projects are open source, that you could fork these projects once they work and build a version without premined token.

I think the rollups concept and Stacks/Nomic are the closest to be implemented, and I expect some fully working for this year.

Merit doesn't mean "like" or "agree. In this case, it means it's worth reading, and not spam. And I'm loaded in sMerit.

There are few things that comes to mind,

• PLTC as replacement of HLTC, which commonly used by LN. PLTC has less on-chain TX size/weight.
• Taproot Assets and RGB protocol, which enable token, NFT and others on LN.
• Various Bitcoin sidechain and L2.

It's probably merit for OP's effort, i also do that on few occasion.

but you merited OP's original posting which contained the above statement in bold. and now you're saying you don't like the idea? that seems like a contradiction.  

even for people that dislike ordinals, i don't think they would agree with the OP's idea. and neither would people who use ordinals because their fees would go up but that may be giving them too much credit since i don't even know if many of them even follow bitcoin too closely even while spamming the blockchain..with their monkeys.

just as a simple example of things that could go wrong: say a particular block didn't have any ordinals. or not enough to fill up the 20% quota. that's wasted block space which could have been used to lower transaction fees for "ordinary" transactions.

Thanks for the in-depth example.
Seems like this is a more difficult problem than it appears at the surface.

Are there any promising solutions in development/consideration? Or is furthering development of LN the primary approach?

Yes, it can. You can encode the necessary metadata in the nSequence field, like EPOBC did, or create fake public key hashes aka addresses (P2PKH/P2WPKH) or public keys (P2PK). P2(W)PKH offers less bytes.

Basically to explain it in simple terms what you would do is to create a fake address with the data of the tokens. Let's say you represent something like P:DRC20:t:PEPE:v:2000 (p for Protocol, t for Token [symbol] and v for Value) first in hexadecimal numbers (503a44524332303a743a504550453a763a32303030) and then encode it into bech32 and this becomes an address (bc1qqqqqqqqqqqqqqqqqqpgr53zjgverqwn58fgy25z98fmr5v3sxqcqqyvute, you can try it here). Nobody would be able to spend this UTXO however, so it would clutter the UTXO set forever.

You create now an additional output with 1 satoshi to the address you want to mint/transfer the token to, optionally an output for change coins, and that's all what's needed - two or three P2(W)PKH outputs. While the bech32 address in this example looks a bit strange, this is only because I had to add zeroes to the hex value because it was too short (it has to be either 20 or 32 bytes).

Even if you create a completely new transaction type with even less data available, the "fake address" method would also work. You could try to separate transactions with more than 1 output, as it's difficult to encode everything in one P2(W)PKH ScriptPubKey but it would perhaps be still possible. But more important you would then make all transactions which have even one satoshi of change more expensive, so this would be unfeasible.

I believe I understand the point you all are making.
In summary, you feel as though there's no way to design bins in a manner which would prevent people from simply circumventing them by cleverly designing their transactions to fit into low fee bins (which may in turn actually make the issue worse because those transactions might become even less efficient).

 
Still, is there really no broad based way to accomplish something like this?

Consider the most simple case; say we wish to implement binary binning - one bin with a very precise and very common transaction op code signature, let's just say P2PKH: [OP_DUP, OP_HASH160, Hash160(seckey.pub), OP_EQUALVERIFY, OP_CHECKSIG] (I know this is pretty much a legacy op-code, just using it for simplicity).
Couldn't we help such transactions occur without issue by ensuring some fraction of each block is available for  such transactions?
I can't imagine that any inscription could occur via this particular op sequence (could it?).

If we can achieve this, could we not expand scope to parse out other common and precise transaction types?
The majority of the block could remain "all transactions" (including those which are specifically reserved).

Perhaps it's not possible with LN atm (I'm not sure of the op codes used to open/close LN channels), but it appears possible at a basic level.

But that's exactly the point! Mechanisms like Stampchain SRC-20 use only opcodes common in "normal" transactions (in this case OP_CHECKMULTISIG). Yes, OP_RETURN is (afaik) only used by "data transactions" (the other ones you mentioned, from my understanding, have other usecases), but it was made standard in Bitcoin 0.9+ to lower the impact of token systems and data transactions on the validating nodes.

Now imagine you "ban" OP_RETURN from the main bin and fees for OP_RETURN txes rise because their "bin" becomes congested - everybody wanting to use tokens on BTC would then use Stampchain or similar mechanisms, and the "main bin" becomes congested again (with worse consequences due to increased resource usage).

If you also ban multisig transactions from the main bin you affect Lightning, and multisig is not even necessary for such a protocol. There are older protocols that use the sequence number for metadata, e.g. the first version of EPOBC.

By the way, regarding Lightning: there may be situation where it would have advantages that "LN transactions" could get all the necessary block space. If you restrict LN transactions (in whatever way) to a 20% "bin" then you may for example delay the closure of channels if a massive node tries to attack.

I think you should really re-read my, Heretiks, odolvlobos and vjudeus posts to understand what's wrong with your proposal.

The intent of such partitioning *is not* to increase the fees of data transactions (though it may be a byproduct); the intent is to ensure that there's space in blocks available for BTC's intended usecase as a currency (this includes facilitating L2 transactions).



Are there any op codes that are integral to ordinals/other inscription that aren't critical for facilitating true L1/L2 BTC monetary txs? OP_RETURN, OP_PUSHBYTES, OP_PUSHDATA come to mind, but I haven't studied Lightning / other L2s enough to be sure these aren't required.
Perhaps, partitioning blocks based on tx op codes could be broad based enough to have fairly static rules?



I'm continuing to push this both for educational and brainstorming purposes.
I'd really love to see a solution that mitigates the potential for what are effectively DDOS attacks on BTC, while preserving the ability for BTC to be multi-functional and uncensored.

This is basically what Luke-jr was trying to do a couple weeks ago with patching the datacarrier structures to interpret TapScripts (well not exactly increasing fees but to make large data transactions infeasible). It never reached a consensus obviously so it was never merged. It would've enforced a limit on the size of TapScripts. A similar failed pull request for enforcing the witness size limit is here.


I believe a partitioning of block space to increase the fees of data transactions is even less likely to get merged.