Segmenting/Reserving Block Space

[bipshuffle]

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?

[1715179359]

1715179359

[1715179359]

1715179359

[1715179359]

1715179359

[larry_vw_1955]

For example, 20% of block reserved specifically for lightening transactions, 20% reserved for ordinals, 60% reserved for general use.

Who's going to decide on those percentages? As much as I'd like the spam to stop, I don't think some "central authority in power" is the right way to do that. I also see no reason to reserve 20% for the spammers.

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.

[ABCbits]

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

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.

For example, 20% of block reserved specifically for lightening transactions, 20% reserved for ordinals, 60% reserved for general use.

Who's going to decide on those percentages? As much as I'd like the spam to stop, I don't think some "central authority in power" is the right way to do that. I also see no reason to reserve 20% for the spammers.

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.  

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

[LoyceV]

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.  

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.

[d5000]

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

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.

[larry_vw_1955]

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.

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. 

[bipshuffle]

just to solve a small problem

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.

[larry_vw_1955]

just to solve a small problem

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?

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.

[JiiBs]

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.

[larry_vw_1955]

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.

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.

[vjudeu]

BLOCK 456 would contain a hash of M BLOCK 456 and so on.

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 <someHash>", 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.

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.

[d5000]

"segregating the monkeys" method.

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).

[larry_vw_1955]

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".

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.

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).

i feel like ordinals will be something that dies down for a while and then has a short spike in activity but it will never go away completely. and there will just be new ideas people come up with to take advantage of this thing like maybe someone comes up with a cool "make a 5 second video that lives on the bitcoin blockchain forever". someone with 5 million followers on instagram or something. that type of thing. fads come and go. there will always be another one that's for sure.

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 <someHash>", 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.

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.

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.

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  

[d5000]

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.

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.

[larry_vw_1955]

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.

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.