Topic: 1000x throughput on transaction batching + privacy boost using Script Bitfields. (Read 352 times)

I'm a big bitcoin fan. Period.. If we want this teck to be used it needs to function within the realms available. Scripting upgrades are all soft-fork. It can _already_ be done on Liquid. That makes it 1,000,000 times more likely to be used. Frankly it _will_ be useable if Bitcoin simply follows the current upgrade path. no changes to the current proposed changes required..


The work Core does cannot be over-estimated. They get a big THANK YOU! from me everyday of the week and twice on Sundays.


Awful name.

----------------------------

IF I was integrating this into a brand new coin.. then there might be ways of making this process cooler.

And for that I'm all ears.

I was thinking that if you had to off-board 1 million users from a side-chain that was under-attack, you could get them all back on-chain in 1 block. If you made the bitfield larger.. even less.

I don't think it is any different in regard to implementation complexities and probable side-effects. No matter you are championing for a
an improve in the script processing or what. Maintaining an extra data infrustructure for UTXO is not that complex and the costs involved in projecting the problem to scripting layer are not justifiable. It is generally a bad idea to solve a problem in scripting layer whenever it could be solved in core layer.

We need to forget about what Core devs say and think, they are not good at improving bitcoin, we are far better. They are under pressure of real worl bitcoin and whales, we are not, we can do anything and implement any idea, it is not our mission to keep bitcoin "un-compromised" it's Greg Maxwell's job and theme song, we need to get rid of succh stupid considerations and innovate and innovate, forever!

I think you are too excited about the covenant stuff. I've no doubts there would be an application for covenant scripting  but this is not the one!

Let's just don't start from covenants and focus on the core idea, I know you've started form covenants but here we are, no need to covenants at all!

I'll fork from your idea, I don't care about covenants and their applications what I care about is the core idea: scaling batch processing in bitcoin and right now we have the solution (thanks to your original idea):
adding a recursive definition of "unspent txn output' such that you can encapsulate more data to a transaction. it is what actually matters.

So, I'm considering a far more efficient version of your idea eliminating the whole covenant thing and txn commitment to bitfields which is absolutely unnecessary and to give you the whole credit I'm calling it "SpartacusRex protocol". Are you in or not?

..

Yes, yes..

The point about including the bitfield is that it doesn't ask the miners to fundamentally change. My technique uses a little clever scripting, that's all. The miners do exactly what they normally do. They don't need to start storing extra data, and changing their core functionality. It's just a scripting upgrade - and miners process scripts very well. I think that has simplicity benefits but we can disagree. 


I fully accept that the spend transaction will include more data.

The point was simply that the exchange or sidechain or who ever it is needing to do a large batch transaction, can now do so at a fraction of the fee and space requirements _initially_. In reality, as you say, by passing the burden of the fee / space to the spender. (Allthough spending may be a long time in the future when space is less of an issue - at least we are on-chain)

Merkle trees are useful when plain cryptography is not enough, like in inter-chain communication. In this proposal you are attempting an uneasy task to compress thirty-something bytes per output even more.

He is arguing that if you need large proofs to spend, it would make things even worse. Actually, it will be a fair objection if you insist on including bitfield on spend txns. My proposed improvements doesn't need such an overhead tho.

The original transaction ( the one where the 'transaction batching' is going on ).. is still 1000x times smaller.. with a fee which is 1000x smaller. And you'll still have paid out to 1024 users.

This bitfield goes into every transaction 1024 times. Adding to this Merkle path and comparing to 250 bytes of an average transaction I would doubt even 1x throughput.

Op. I think we have a common perspective now. It looks very simple and obvious to me, no covenants, complementary UTXO data and extra amountsList data being hash-committed in the txn, and passed to each user who we wish to convince about our fidelity.

Now let's take a look at the bigger picture:

One important problem would be maintaining the wallets by users. They have to keep track not only of their private keys/seeds now to retrieve their balance they need the extra proofs to be backed-up and kept safe, for each output and it is great inconvenience.

well, what I'm saying is that there is absolutely no need to all of this convenants thing and complicating the proposal. It is just like how nodes maintain the UTXO right now, they can just have extra bitfields for this class of outputs. Period.


This ?.. Please elaborate.. '..confirming initially a hurdle..' ( I think we are not seeing exactly the same picture..)