2

If Monero gets large enough Ring Sizes to include potentially unconfirmed inputs, would chained transactions be possible?

Chained Mempool Transactions in Bitcoin allow unconfirmed inputs to be immediately respent. This gives huge UX advantages, including:

  • Immediate sending of received funds
  • Multiple transactions possible with only 1 input
  • Services can do more nifty things*

*See Bitcoin unlimited's post.

Obviously, a chain of 25+ is unrealistic from a privacy perspective, but are there any technical barriers stopping Monero from doing this in the future?

| improve this question | | | | |
3

in addition to janowitz answer, chained transactions in monero are currently impossible because inputs are referenced with an index ID that is created when the tx makes it into a block. Thus, in order to make chained txs possible, the system would have to be reworked such that transactions are referenced by a unique identifier, so it doesn't matter where in the chain they end up. This reworking is also important for chain reorganizations.

| improve this answer | | | | |
  • This is a good addendum. Also worth noting that indexes are much smaller than the actual keys (which are themselves the unique identifiers); this is an optimization of overall tx size (<8 bytes vs 32 bytes per decoy). So if the decoys used the actual keys directly for the ring members in the tx, the tx size will balloon. – jtgrassie Nov 27 '19 at 7:57
  • 1
    @jtgrassie: It is true that the transaction size would grow while in transit through the network and while waiting in the mempool, but transactions could be stored in the database substituting the one-time keys for their global index once they are mined. This way, you get the same space savings for storing them, but can also check the that the transaction ID is correct by replacing back the global index by its one-time address as needed. – user141 Nov 27 '19 at 10:20
  • By the way, this is not just an addendum: the global index vs. direct one-time address referencing of outputs is the main technical reason standing in the way of chaining transactions, above all else mentioned in the other answer. – user141 Nov 27 '19 at 10:53
  • I referred to this answer as an "addendum" because the author starts with "In addition to janowitz answer". W.r.t. tx size, I never suggested the on-disk size would change. – jtgrassie Nov 27 '19 at 16:03
  • It's also not a particularly big "technical reason" replacing indexes with output keys in the tx, but it is a challenge to preserve the same level of privacy. This is why both answers have merit. – jtgrassie Nov 27 '19 at 16:14
1
+300

Very good but complex question since it's affecting multiple parts of the network integrity, security and privacy.

Let's start with your second point "Multiple transactions possible with only 1 input" since this is already possible and you can add multiple recipients in a single transaction, no matter how many inputs you use. Currently the maximum outputs you can use is 16 and only in CLI wallet, but as of my knowledge there is already work going on to implement it into the GUI wallet.

However, in Monero an output needs 10 confirmations, this was a wallet setting up to 0.14.x but from 0.15 is enforced by consensus, so a transaction which contains a ring member which is not yet confirmed in 10 blocks will not be valid until all ring members have at least 10 confirmations. This is in case a chain reorg would occur, transactions containing at least one ring member from an orphaned block wouldn't be valid any more. This setting of 10 is arbitrary and not settled in stone, but there needs to be research done if maybe a lower number of confirmations would be sufficient.

Now if we'd allow spending of unconfirmed outputs, for privacy reasons we would have to add unconfirmed ring members also in other transactions which may never be confirmed (eg. double spend attempts within txpool). Also sybil attacks could compromise privacy, when a malicious actor pushes 100 tx into an almost empty txpool, but a tx includes one of the few others as ring member, so it'd be statistically pretty obvious this was the real one.

Monero has an average 2 minute block time in comparison to 10 minutes in Bitcoin and most of its forks, so on average you currently need to wait 20 minutes for an output to be spendable.

So it's unlikely that Monero will implement chained transactions within the mempool with its current privacy ring signature scheme, however if a better zero knowledge scheme would be found, it might be implemented in one of the scheduled hard forks and maybe allow better options.

In the current ring signature scheme, it's more likely that something like frequent transactions would be implemented in a side chain / second layer like Mimble Wimble or Lightning Network. Tari Labs is already working on a side chain for Monero which is based on the Mimble Wimble idea.

For more frequent onchain transactions it's more likely short term that some automatic output splitting functionality / management will be implemented like in a physical cash wallet, where you most likely have not just one single bill which you can spend, but splitted into several bills and coins. For example if you split up your single output into 16 new outputs, you will be able to spend them subsequently, either one of them or use several for larger transactions.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.