pull down to refresh
42 sats \ 0 replies \ @kevin_lightning 7 May \ parent \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
If you were insane and mandated that txns came with signatures you could prove they were spendable but yeah.
Within the realm of reasonable solutions there's not much you can do. That's the nature of a digital ledger that ultimately is a distributed database.
People are going to store arbitrary content. Trying to stop it is futile. What we can do though is provide aligned incentives.
Unlikely. Inscriptions / witness stuffing is more economical past about the 100 byte mark due to cost. Witness is 4x discounted while OP_RETURNs are not.
-
The main reason for the PR (in my opinion) is that it achieves harm reduction. Similar to how local governments might provide a drug addict clean needles, giving data embedders the option to utilize OP_RETURN is better than having them stuff witnesses. This is because (1) OP_RETURN is provably unspendable and does not bloat the UTXO set and (2) does not leave dust outputs behind like witness stuffing (i.e. inscriptions). Secondly, removing the limit reduces the need for nodes to need to pull transactions at block-sync time because the next block will be made up of transactions already in your local mempool. Finally, because mining pools don't care about standardness, relay should not either. I think it was gmax that said what is relayed should closely match what is mined.
-
IBD solutions already exist today. I forgot the name of one of them but it essentially has UTXO set hints that allow you to parallelize the process of sync. This is the main reason why IBD is slow today, and if you setup a node from scratch you'll see that CPU/networking are not utilized to their full potential. Libbitcoin is another example of how parallelizing can make it such that your network speed is the bottleneck for sync.
-
If we do nothing then block updates are slightly worse for everyone as mentioned before. Additionally, if your code relies on mempool estimates for fees it will have a less accurate prediction of what to use for a fee rate. It would be similar to someone running the ordisrespector patch. Even if the transactions they don't like are not in their own mempool, they will need to store it anyway when a block is mined that contains them. Finally, if we do nothing there is a very real likelihood that a third party may resort to VERY BAD data storage methods like Bitcoin Stamps which utilize fake pubkeys and stuff data in them. These are much worse because they permanently bloat the UTXO set with each transaction created.
In the event of forced liquidation, the insurance fund will cover progressive offloading of the position. If that doesn't happen (or if the insurance fund is insufficient to do so) auto deleveraging kicks in with fill-or-kill orders to minimize liquidation ripple effects.
I think I would try and get ANY_PREVOUT merged first, then build channels on top of eltoo. It's a lot easier to wrap your head around conceptually versus asymmetric commitment transactions
We're working to add more metrics. Right now we primarily track the origin of trades (i.e. Pro front-end vs Lite front-end vs Umbrel app).
So the way their stablesats system works is via a dealer that hedges against the total liability of the platform. It's a pluggable system and currently uses Okex. Kollider would be the second exchange to be added, increasing the overall hedging system's durability.
We're working with Galoy to get Kollider integrated with their dealer, which would allow for the mobile BitcoinBeach wallet to hedge on our exchange.
GENESIS