pull down to refresh
No, i mean BIP 347. I wasn't aware that this was some weird ploy to accuse me of being a shit coiner....
I'm legitimately bummed out man. Just forget it.
I didn't say you were a shitcoiner?
PS: In the case of OP_CAT, you must mean Starkware and I thought I saw the hand of them / their affiliations in some of the things you write. Did you check how their network is going? Their lil token?
Maybe i'm completely off base, but I can't see any other translation to that paragraph
In that case, i'm one hundred percent willing to admit that I may have been wrong, and I will give you the complete benefit of the doubt. My apologies for misunderstanding. Sorry.
The theory is that you need the demand for the block space first. There's no shortage of shit coins that try to "solve" bitcoin by putting the cart before the horse. I'm not familiar with starkware, but I know if simular coins who's claim to fame is infinite block space. Infinite block space + not Infinite demand = dead coin.
I don't know if anyone has claimed that this can fix all 3 concurrently. If you were to roll this out today, for instance, you would solve the quantum threat, and the scaling issue. You'd then have to hope that adoption catches up fast enough to pay miners. That's not a position anyone wants to be in.
I also know originally this would have allowed for a DDOS attack against the network. That has been fixed, but I don't actually know if this opens up any new attack vectors, or concerns about them.
If you were to roll this out today, for instance, you would solve the quantum threat, and the scaling issue.
No, you wouldn't, and that's the problem. What you would do, and I think that this is also how both Ethan and Andrew frame it - or at least how I read it - is that you'd allow solutions to be developed more freely, with real mainnet use cases. And then, you'd be able to optimize the things that work and the latter in turn would solve things like quantum resistance and scaling and some dedicated opcodes to do for example successful BitVM applications properly.
I am not against OP_CAT, at all, even though I'd favor it as a part of GSR. I do because there is much to say for having greater script primitive flexibility, so that these "suboptimal" products can be developed and proven, giving everyone an idea about what is truly needed (and creating some friction, which isn't bad, imho.) For the Quantum case it is too late though, that's already worked on in optimized form. The magic isn't in use cases that we know of: it's in the use cases that we haven't thought of yet.
This is actually a really good take.
My field of knowledge is actually pretty narrow regarding quantum solutions, are there any BIPs you're in favor of?
Honestly, I don't like any of the things circulating at the moment, most of the small stuff is stateful, making wallet backups (not seed backups) a must-have and the stateless ones have 20x signature size - OpTech keeps tabs on everything that's being discussed, so I come back to that page a couple times per month, see what's new.
I do like the rewritten BIP-360 as a stopgap measure for long range attacks on p2tr. But it's not a real solution for PQ resistance long term.
First if all, I'm not pounding a war drum for OP_CAT. I came here with multiple solutions to discuss. I specifically stated that I want to talk to someone who is more technically minded than me about it.
- Scalability solved.
- The reason this is suggested solution by the BITCOIN community, (people like Andrew Poelstra of blockstream, and authored by Ethan Heilman who is heavily involved in BIP 360, as well as being responsible for mathematically destroying shitcoins), is because it allows payments to miners to scale.
The sequences aren't a middle man between L2 and L1, they are the ones that collect and aggregate all of the small fees in order to pay the massive transaction costs to the miners.
Yes, scaling would initially hurt miners, look up Jevons Paradox. But the whole basis is that you could on board the entire planet, and L1 would be sustained by the massive economic weight of all of those transactions.
- Because OP_CAT allows you to combine pieces of data directly in Bitcoin Script, it allows developers to build complex new signature schemes that rely only on hashes, rather than elliptic curves. Specifically Lamport signatures or Witernitz signatures so NO you're not required to switch to another network.
A true ZK-rollup on Bitcoin wouldn't be a federated, custodial sidechain. A covenant mathematically guarantees your unilateral right to force-exit your UTXO back to L1 at any time, without the sequencer's permission. It inherits Bitcoin's base-layer security.
If you don't like this solution, fine. If there's problems with this solution, fine. But this IS a solution and it IS supported by prominent people within the BITCOIN community.
Thanks for the conversation.
Oh, and i forgot to mention. The very first version of OP_CAT was authored by well known shit coiner Satoshi Nakamoto, who disabled it due to an attack vector that it created that has longe since been fixed.
Right, we get to the crux of the answer to your 3 problems:
<magic>. Compression reduces fee pressure, no matter how you put it.PS: In the case of
OP_CAT, you must mean Starkware and I thought I saw the hand of them / their affiliations in some of the things you write. Did you check how their network is going? Their lil token?So what this means is:
What isn't solved? Bitcoin's problems.