<p>It is possible to create MW transactions interactively, and if you're creating multisignature outputs I think this is actually necessary. But ordinary transactions can be created non-interactively (well, with half a round of interaction, as in Bitcoin where one party sends an address to another party who builds a transaction) in two ways:</p>

<p>Suppose the sender is trying to send 5BTC to the receiver.</p>

<ol>
<li>The sender can create a transaction that doesn't balance unless a 5BTC output is added. Aside from this discrepancy the transaction is valid; she sends this to the recipient.
The recipient then adds a 5BTC output, adds another kernel to the transaction so that the blinding factors still add up, and the transaction is complete.</li>
<li>The sender acts as above, but sends the <em>opening</em> of the kernel. This is a bit dangerous because it gives the sender the ability to reverse the transaction long after the fact, but I'm unsure what sort of attack this would enable.</li>
</ol>

<p>Note that both cases require a secure channel from the sender to the receiver because anyone who gets the incomplete transaction could add their own 5BTC output to it.</p>

<p>It's also possible to do this in reverse: the recipient sends the sender an incomplete transaction that needs a 5 BTC <em>input</em> to balance, and the same considerations apply.</p>

CC BY-SA 3.0
2017-02-03T06:32:47.217Z
Does the kernel means excess value? and What is opening?
chikyukotei
CC BY-SA 3.0
2017-02-04T05:04:32.200Z
Kernel is the more generic term for excess value. Opening means being able to spend.
Pieter Wuille
CC BY-SA 3.0
2017-10-14T17:38:42.900Z
Could some form of DH be used for the secure channel and passive receiving? Like, I publish some pubkey (A=a\*G) of mine, you generate some random one-time private key (R=r\*G), and publish the (R, H(r\*A), unbalanced transaction encrypted with H(r\*A)) to the blockchain. I can claim this TX at any time (unless you double-spend?), after which it could be purged from the blockchain.
JollyMort
CC BY-SA 4.0
2018-08-30T23:19:20.857Z
There is a fundamental flaw in (1), the transaction which consists of 2 parts, whose the blinding factors are balanced, whereas the sum is not. So there are donor and acceptor parts. The attacker (malicious Node) may brute-force the sum that you're trying to send, and eventually puzzle out its structure. And then it just removes the intended acceptor part, and substitutes its own.
valdo
CC BY-SA 3.0
2017-02-03T03:52:24.270Z
2017-02-03T03:52:24.270Z
Andrew Poelstra
<p>I have read Mimblewimble paper.</p>

<p>Certainly, Transaction merging process is non-interactive.<br>
However, Transaction creation process seems to be <strong>not</strong> non-interactive.<br>
To create transaction, a sender must interact a receiver because a sender shouldn't know all output's blinding factor(except change).
If a sender knows output's blinding factor, he can spend output. </p>

<p>Is my understanding of this correct?</p>

<mimblewimble>
Transaction creation process is not non-interactive(Mimblewimble)?
chikyukotei
# Transaction creation process is not non-interactive(Mimblewimble)?

(Asked by: username_0 on 2017-02-03)

I have read Mimblewimble paper.

Certainly, Transaction merging process is non-interactive.  
However, Transaction creation process seems to be **not** non-interactive.  
To create transaction, a sender must interact a receiver because a sender shouldn't know all output's blinding factor(except change).
If a sender knows output's blinding factor, he can spend output.

Is my understanding of this correct?

**Tags:** mimblewimble


---

## 1 answers

### Answer by username_1 on 2017-02-03. Score: 4 | Accepted answer

It is possible to create MW transactions interactively, and if you're creating multisignature outputs I think this is actually necessary. But ordinary transactions can be created non-interactively (well, with half a round of interaction, as in Bitcoin where one party sends an address to another party who builds a transaction) in two ways:

Suppose the sender is trying to send 5BTC to the receiver.

1. The sender can create a transaction that doesn't balance unless a 5BTC output is added. Aside from this discrepancy the transaction is valid; she sends this to the recipient.
   The recipient then adds a 5BTC output, adds another kernel to the transaction so that the blinding factors still add up, and the transaction is complete.
2. The sender acts as above, but sends the *opening* of the kernel. This is a bit dangerous because it gives the sender the ability to reverse the transaction long after the fact, but I'm unsure what sort of attack this would enable.

Note that both cases require a secure channel from the sender to the receiver because anyone who gets the incomplete transaction could add their own 5BTC output to it.

It's also possible to do this in reverse: the recipient sends the sender an incomplete transaction that needs a 5 BTC *input* to balance, and the same considerations apply.

> **Comments:**
> **username_0**: Does the kernel means excess value? and What is opening?  
> **username_2**: Kernel is the more generic term for excess value. Opening means being able to spend.  
> **username_3**: Could some form of DH be used for the secure channel and passive receiving? Like, I publish some pubkey (A=a\*G) of mine, you generate some random one-time private key (R=r\*G), and publish the (R, H(r\*A), unbalanced transaction encrypted with H(r\*A)) to the blockchain. I can claim this TX at any time (unless you double-spend?), after which it could be purged from the blockchain.  
> **username_4**: There is a fundamental flaw in (1), the transaction which consists of 2 parts, whose the blinding factors are balanced, whereas the sum is not. So there are donor and acceptor parts. The attacker (malicious Node) may brute-force the sum that you're trying to send, and eventually puzzle out its structure. And then it just removes the intended acceptor part, and substitutes its own.  

---

