How can a 3rd party tell whether the sender or the receiver spent it, when both claim the other did?
1 Like
On the example of bitcoin. In order to resolve the dispute, the recipient presents the public key to which the payment was to be made. Anyone can check on the blockchain if the payment was made to that address.
In our case, to perform a similar check, the sender must disclose the shared secret. At least the part that is responsible for generating the public key for withdrawing funds.
Bi=x(S) * A1i
x(S) â x coordinate of point S (shared secret)
A1i - is the public key, the address to which the funds should be transferred.
Đi - is the public key for withdrawing funds, explicitly recorded in the blockchain.
1 Like
If there is no 1-of-2 involved then I didnât understand your proposal. Maybe you can explain what consensus rule changes are required in your proposal.
2 Likes
- The sender forms a non-interactive transaction, which consists of several points of the elliptic curve, but the sum of these points of the elliptic curve is formally verified as a normal output. There is a range check. The sum of points is fully taken into account when verifying the blockchain.
- Simultaneously with the formation of a non-interactive transaction, a future offset (core) - Bi is created, which the recipient must sign in order to spend the input. The core must remain on the blockchain forever. Together with the kernel, a hash is written that captures the constituent parts of the transaction from change to the moment of spending.
- After spending the input of a non-interactive transaction, the signed core participates in the verification of the blockchain as an offset.
I havenât been able to find 1 of 2 yet, can you provide a link?
Maybe Quantum research will stop reaching for use cases in breaking ciphers and instead put more emphasis on inventing stronger cryptography? I think the overall incentive points towards stronger cryptography instead of breaking weaker forms just so they can be proclaimed broken.
You havenât explained what consensus rule changes are required to support your schemeâŚ
Here for instance https://forum.grin.mw/t/simple-idea-for-2-step-grin-transfer/
1 Like
Consensus rules change:
- Unsigned cores that are associated with non-interactive transaction outputs will be stored on the blockchain. Therefore, it is necessary to check that each unsigned kernel has a corresponding non-interactive output, and that the content of that output matches both the kernel and the hash stored with the kernel.
- All unsigned cores will not need to be taken into account in checking the equality of blockchain inputs and outputs.
- It will be possible to spend a non-interactive output only by signing the core that is associated with this output. In this case, when validating a transaction, you will need to take into account the kernel offset and take into account the value of the input of a non-interactive transaction minus the kernel.
- You will also need to check that the signed core was previously written to the blockchain.
- After spending the output of a non-interactive transaction, the signed core will remain on the blockchain forever. The hash that was written along with the core must also remain on the blockchain. This does not affect the consensus, but may be required in a dispute, although not exactly.
Thatâs not quite what consensus rules look like. Youâll need to be far more precise, like section 3 of the article [1], specifying what new fields of data are added where, and what new equations they need to satisfy.
1 Like
Can someone explain why youâd want non-interactive transactions when we already have slatepacks?
1 Like
There are some benefits to not having to involve the receiver in the transaction. Obviously, this can make transaction building much faster and makes some cases like donations very simple because these are âweâll take anything from anyoneâ transactions. However, noninteractivity means that the sender can instantly construct a valid transaction for anyone and, at least for me, itâs not clear if you want to give such power to the sender. I want to be the only person to put coins in my wallet, just like with my physical wallet. On top of that, the schemes we know today add so much complexity just to cover this case. I donât think itâs a good tradeoff.
2 Likes
we have slatepacks because we have interactive transactions â in non-interactive transactions the sender can create a valid transaction on his own, so he doesnât need to send any data to someone else (therefore doesnât need slatepack). What you probably mean is âwhy would you want nitx when we have autoreceiveâ and the answer for that is that nitx donât require the receiver to be online and sign the transaction (so itâs easier to send to cold storage or in general less things to do to send a regular transaction)
1 Like
Usually the sender is already in communication with the receiver to discuss payment details and confirm the receiver address. Thatâs been the case for all (a few dozen) crypto transactions I have ever performed.
In many cases itâs desirable to generate a payment proof, which cannot be done without interaction. For added privacy, itâs also desirable to use payjoins, again requiring interaction.
A little but not that much, once you have built good clients to communicate slates back and forth. E.g. lightning payments are not that much slower than regular Bitcoin payments.
2 Likes
There are two options here. This is because the sender of a non-interactive transaction can do without a kernel_excess to protect ownership.
In the first variant, the sender protects the transaction from being changed using the value of the hidden commitment factor, which is affected by all elements of the transaction. This option has been described above. Non-interactive transactions.pdf - Google Drive.
The second option is based on the fact that the sender creates a kernel_excess and signs the transaction data with this key. Thus, there are two sender and receiver kernel_excess per one non-interactive transaction. This option is useful when implementing the chargeback function. Non-interactive transactions_double kernel.pdf - Google Drive
Iâve looked at the 2 PDFs in the most recent reply, and it looks like they are actually quite similar to the existing schemes ([1] Minglejingle, [2] LIP-0004, and [3] Non-interactive Mimblewimble transactions, revisited).
@Andi, how does your idea differ from those 3? Are there any notable improvements over these schemes? AFAICT, your writeups each seem to be just minor variations of [2] and [3], but if there is something more novel about your approach that I may have overlooked on my first read, please let me know, and Iâd be happy to take another look.
7 Likes
One of the important differences is the ability to identify a transaction without a hint, which reduces confidentiality. It only takes a few steps to identify any transaction. If the transaction is identified, then you can start searching for the address to which the funds were sent.
I looked badly, in lips/lip-0004.mediawiki at master ¡ litecoin-project/lips ¡ GitHub the quick identification function is implemented. In this case, there are no special significant functions. It is only possible to return unclaimed funds after a certain number of blocks.
I reviewed the protocol and it seems to be sound except for one major problem: the recipient can actively invalidate any payment proof that the sender might have. Practically speaking, this makes it not much better than the simplest 1-of-2 output proposals.
Assume that Alice is sending an output (B, Cl, BP(C), n, P1, P2) to Mallory. Mallory can intercept the transaction in the mempool and replace the output by a different output (B', Cl', BP(C)', n', P1', P2') that has the same value v, but for which Alice does not know any secrets. This allows Mallory to deny having received anything from Alice.
In cryptographic terms, this is called a malleability vulnerability.
4 Likes
Hello, @tevador . Thank you for your time and finding the vulnerability. I would like to note that this vulnerability does not exist in version 2, since the composition of the transaction is fixed at K 1 (kernel_excess).
In the first option, I see the following possible solution to the problem:
- P 1, P 2, n excluded from commitment ĐĄ.
- P 1, P 2, n transfer to the recipient later through other channels or include in the blockchain after a given number of blocks.
Although all of the above is inconvenient for the sender.
That does not actually solve the issue.
Any payment proof must be bound to the output key B by showing that it was indeed constructed from the recipientâs public key. Even if you remove P1, P2, n from the blockchain data, Mallory can still replace B with B' since itâs not actually anchored in the verification equation (it is added and then subtracted again as a part of Cl).
The only solution is to have the sender sign B using another key that canât be swapped out without invalidating the transaction.
This does fix the vulnerability, but introduces several new issues.
- You canât have different rules for the change output and the recipientâs output, otherwise the transaction is leaking privacy-sensitive information (blockchain analysis companies would love it).
- Since the change output must be indistinguishable from the recipientâs output, you have to sign both in the kernel. This links the two outputs together, removing one of the privacy benefits of Mimblewimble.
- Since the kernel signs transaction outputs, the outputs can never be pruned, otherwise the signatures could not be verified in the future. This can be mitigated by signing hashes, but you still have to keep the hashes forever.