Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
offline transactions via "public" outputs #2650
@GandalfThePink posted a link to a this -https://github.com/mimblewimble/grin/files/2905763/MWpp.pdf
In the issue tracking BLS Signatures -
But I pulled this out here as there are some things in the paper that we may want to discuss outside of the BLS signatures conversation.
Specifically "public outputs" and "offline transactions".
(Hope you don't mind me starting a discussion here @GandalfThePink).
Paraphrasing poorly (given my limited understanding) -
At this point, if a recipient publishes a a public key (a public address)
i.e. If Bob publishes a public key, Alice can use it to send an arbitrary number of Grin non-interactively.
Bob could then "claim" the "hanging output" at a later date, allowing the output to be put on-chain as a regular output.
To claim (or complete or finalize?) the hanging output the recipient would build the necessary rangeproof (given
Did you mean to separate this thinking implementation could be done separately or just for the discussion of hanging transactions? Practically they're not separatable from BLS because it all relies on the ability to aggregate signatures non-interactively.
I do have some questions though regarding the privacy of the hanging output commitments. It seems they could easily leak amounts or even more.
I think this is a slightly simpler but along the same lines approach to "public outputs and offline transactions".
This does not require "hanging outputs", both transactions (the "send" and the "claim") are valid and can be accepted on-chain (with modified consensus rules).
We decouple the "send" from the "claim" allowing the sender to select the value
An output currently consists of a commitment
Introduce the concept of a public key
Introduce the concept of a "public" output, one with a public key associated with it -
i.e. A public key, a commitment using both
Note: we can still verify the rangeproof as we can reconstruct
So recipient publishes
Sender (unilaterally) creates a transaction creating an output with the following properties -
Note: The sender uses their own private key
This is effectively a tx that spends an output and sends it back to the sender,
Modify the consensus rules such that a public output can only be spent by the owner of the private key
So the output is valid in terms of MW, kernels still sum correctly if we account for both
When the recipient comes to "claim" this output and spend it the MW rules can account
Modify the spending rules -
To create a public output -
To spend a public output -
But there is a problem with this though. Same problem with timelocked outputs (and any other attempt we have made at encumbering an output) -
We are attaching additional data (the public key) to an output.
This is probably doubly bad because the malicious miner could add a public key to any output and "claim" it.
There are a few issues to be discussed.
First the problem of deep reorgs. I personally think that this is not a very big problem. The required depth can be chosen such that any such reorg would be disastrous for many other reasons and it is mostly a theoretical problem.
Then there is the question about BLS. Public transactions work without BLS. But the offline solution I describe using hanging outputs requires signature aggregation. Otherwise when the receiver wants to claim, the sender would need to participate and in that case the payment is just an empty promise to pay.
The modification that you describe above avoids that, but I think that it has its own flaws. In particular there is a weakness similar to what I describe in section 4.1. Making a transaction from a third-party commit back to the same person can be done without that persons involvement, potentially adding a public key and I think the way the rangeproofs are set up these can still be created. To avoid this the sender would need to prove possession of the private key in some way.
Let me summarise your idea in my words to see if I did correctly understand it.
In essence we are looking at a MW transaction that pays from Alice C_A = v L + k_A G to Carol C_C = v L + k_C G.
In that case in order to validate the chain however we need to have Alice interact with Carol, or store the intermediary data (Bobs public key, the signature and the related commits) forever. This means that each time an offline transaction is used we no longer scale as UTXO size, but with the transaction history.
Another somewhat related question to the implementation of rangeproofs. Are we sure that given a valid rangeproof for C = v L + k G I cannot forge a rangeproof for C = v L + (k+1) G without knowing k. What are the security assumptions. Is this a well understood problem?