Transactions full ephemeral

[josediegorobles]

I think that every transaction can have a flag about the succinct proof go in the block or no (ephemeral_data flag for example).

If a transaction proof goes directly on the block, has to pay more fees.

It’s important to have the option to go no interactive, but if one does very fast and short lived transaction of with very few denomination, can go interactive and save a small fee. Every once in a while, for consolidation or for long term save one goes non interactive, so the data that has to be saved don’t grows a lot.

So we can have almos same number of transactions non interactive and a lot more interactive with same block size or less block size and less non interactive transactions but total number of transactions a lot more.

It makes sense?

[adambor]

Yep, we were thinking about this with @cryptoquick already, that this non-interactivity could be just opt-in, and would make sense for long-term storage, then the 1750 tps limitation only applies to long-term storage which I think is very reasonable. It's a good idea worth exploring - merging the original Prime with 9th Proof, however then the whole system might become more complex.

[josediegorobles]

That's the issue, the increased complexity. But maybe not too much.. I think is very much worth it to conserve the two things: the original prime gives a boundless limit to transfers, is very good to have the option and initially is perfect to attract people at the start: the capacity to do limitless transactions (and very very cheap).
And can limit the block size a bit more: maybe blocks of 300 kb, with a lot more of non interactive transactions that current bitcoin AND much more ephemeral transactions.
Can we have an idea of the additional complexity for know if it's worth it?