Re: [bitcoin-dev] Safer NOINPUT with output tagging

> On 20 Feb 2019, at 4:24 AM, Luke Dashjr wrote: > > Even besides NOINPUT, such a wallet would simply never show a second payment > to the same address (or at least never show it as confirmed, until > successfully spent). This is totally unrelated to NOINPUT. You can make a wallet like this

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Even besides NOINPUT, such a wallet would simply never show a second payment to the same address (or at least never show it as confirmed, until successfully spent). At least if tx versions are used, it isn't possible to indicate this requirement in current Bitcoin L1 addresses. scriptPubKey mig

Re: [bitcoin-dev] Safer NOINPUT with output tagging

This only depends on the contract between the payer and payee. If the contract says address reuse is unacceptable, it’s unacceptable. It has nothing to do with how the payee spends the coin. We can’t ban address reuse at protocol level (unless we never prune the chain), so address reuse could on

Re: [bitcoin-dev] Safer NOINPUT with output tagging

On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote: > While this seems fully compatible with eltoo, is there any other proposals > require NOINPUT, and is adversely affected by either way of tagging? Yes, this seems to break the situation where a wallet wants to use NOINPUT fo

Re: [bitcoin-dev] Safer NOINPUT with output tagging

On Sun, Feb 10, 2019 at 12:48:40AM +0800, Johnson Lau wrote: > In a 3 parties channel, let’s say the balance for A, B, C is 2, 3, 6BTC > respectively, there are few ways they could make the settlement tx. The way I look at this is: * you can have a "channel factory" of 3 or more members (A,B,C,

Re: [bitcoin-dev] Safer NOINPUT with output tagging

And this scheme could be generalised to the combinatorial settlement model in my earlier post. Let’s say the settlement tx has 3 outputs: (A&B),(B&C),(A&C). There will be 4 versions of this tx: tx-X: all 3 outputs are tagged, signed by all 3 parties tx-Y-AB: output (A&B) is untagged, the other

Re: [bitcoin-dev] Safer NOINPUT with output tagging

<--- not replying to list as this is off-topic > Hey Alejandro, thanks for the pointer. Is there a summary of how the opcode you're proposing would look like? Is pairing crypto strictly necessary or would interactive key aggregation schemes like Bellare-Neven work as well? Best, Jonas On

Re: [bitcoin-dev] Safer NOINPUT with output tagging

In a 3 parties channel, let’s say the balance for A, B, C is 2, 3, 6BTC respectively, there are few ways they could make the settlement tx. The first type we may call it “simple settlement”, which has 3 outputs with A=2, B=3, C=6. The second type we may call it “fully combinatorial settlement”,

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Johnson's modification solves the issue I pointed out. Moreover, as Johnson and I discussed in private, using different locktimes for X and Y is not necessary. They can have the same relative locktime. If A and B would only sign Y as soon as the update tx is confirmed, there is no risk of Y changi

Re: [bitcoin-dev] Safer NOINPUT with output tagging

This is really interesting. If I get it correctly, I think the fungibility hit could be avoided, just by making one more signature, and not affecting the blockchain space usage. Just some terminology first. In a 3-party channel, “main channel” means the one requires all parties to update, and “

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Hi all, Side note: I was not able to come up with an similar, eltoo-like protocol that works if you can't predict in advance who will become absent. An eltoo-like protocol that works (without going on-chain) if you can't predict in advance who will become absent would be a childchain. If the

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Output tagging may result in reduced fungibility in multiparty eltoo channels. If one party is unresponsive, the remaining participants want to remove the party from the channel without downtime. This is possible by creating settlement transactions which pay off the unresponsive party and fund a ne

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Good morning aj, I certainly agree. I hope that PSBT support becomes much, much, much more widespread. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, January 31, 2019 2:04 PM, Anthony Towns wrote: > On Mon, Dec 24, 2018 at 11:47:38AM +

Re: [bitcoin-dev] Safer NOINPUT with output tagging

On Mon, Dec 24, 2018 at 11:47:38AM +, ZmnSCPxj via bitcoin-dev wrote: > A boutique protocol would reduce the number of existing onchain wallets that > could be integrated in such UI. Seems like PSBT would be a sufficient protocol: 0) lightning node generates a PSBT for a new channel, wi

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Good morning Johnson, Indeed, manual operation is risky. However the intent is to reduce the requirements on commodity wallets in order to integrate them into a combined onchain and offchain UI. A boutique protocol would reduce the number of existing onchain wallets that could be integrated in

Re: [bitcoin-dev] Safer NOINPUT with output tagging

> On 22 Dec 2018, at 10:25 PM, ZmnSCPxj wrote: > > Good morning Johnson, > >> Generally speaking, I think walletless protocol is needed only when you want >> to rely a third party to open a offchain smart contract. It could be >> coinswap, eltoo, or anything similar. > > I think a third par

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Good morning Johnson, > Generally speaking, I think walletless protocol is needed only when you want > to rely a third party to open a offchain smart contract. It could be > coinswap, eltoo, or anything similar. I think a third party would be pointless in general, but then I am strongly agains

Re: [bitcoin-dev] Safer NOINPUT with output tagging

> On 21 Dec 2018, at 7:15 PM, Christian Decker > wrote: > > Johnson Lau writes: > >> I think the use of OP_CSV (BIP112) is not needed here (although it >> doesn’t really harm except taking a few more bytes). All you need is >> to sign the settlement tx with a BIP68 relative locktime. Since t

Re: [bitcoin-dev] Safer NOINPUT with output tagging

> On 21 Dec 2018, at 7:40 PM, ZmnSCPxj wrote: > > Good morning Johnson, > >> The proposed solution is that an output must be “tagged” for it to be >> spendable with NOINPUT, and the “tag” must be made explicitly by the payer. >> There are 2 possible ways to do the tagging: > > First off, th

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Good morning Johnson, > The proposed solution is that an output must be “tagged” for it to be > spendable with NOINPUT, and the “tag” must be made explicitly by the payer. > There are 2 possible ways to do the tagging: First off, this is a very good idea I think. > While this seems fully

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Johnson Lau writes: >> If we are using a trigger transaction the output of the setup >> transaction would simply be `2 Au Bu 2 OP_CMS`. If we were to use a CLTV >> in there we would not have an option to later attach a collaborative >> close transaction that is valid immediately. Furthermore the t

Re: [bitcoin-dev] Safer NOINPUT with output tagging

> On 21 Dec 2018, at 1:20 AM, Christian Decker > wrote: > > Johnson Lau writes: >> Correct me if I’m wrong. >> >> For the sake of simplicity, in the following I assume BIP118, 143, and >> 141-P2WSH are used (i.e. no taproot). Also, I skipped all the possible >> optimisations. >> >> 1. A and

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Johnson Lau writes: > Correct me if I’m wrong. > > For the sake of simplicity, in the following I assume BIP118, 143, and > 141-P2WSH are used (i.e. no taproot). Also, I skipped all the possible > optimisations. > > 1. A and B are going to setup a channel. > > 2. They create one setup tx, with a s

Re: [bitcoin-dev] Safer NOINPUT with output tagging

> On 20 Dec 2018, at 6:09 AM, Christian Decker > wrote: > > Ruben Somsen via bitcoin-dev > > writes: > >> Hi Johnson, >> >> The design considerations here seem similar to the ML discussion of >> whether Graftroot should be optional [1]. >> >>>

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Ruben Somsen via bitcoin-dev writes: > Hi Johnson, > > The design considerations here seem similar to the ML discussion of > whether Graftroot should be optional [1]. > >>While this seems fully compatible with eltoo, is there any other proposals >>require NOINPUT, and is adversely affected by ei

Re: [bitcoin-dev] Safer NOINPUT with output tagging

> On 18 Dec 2018, at 4:08 AM, Johnson Lau via bitcoin-dev > wrote: > > > >> On 17 Dec 2018, at 11:48 PM, Ruben Somsen > > wrote: >> >> Hi Johnson, >> >> The design considerations here seem similar to the ML discussion of >> whether Graftroot should be optional [1]

Re: [bitcoin-dev] Safer NOINPUT with output tagging

> On 17 Dec 2018, at 11:48 PM, Ruben Somsen wrote: > > Hi Johnson, > > The design considerations here seem similar to the ML discussion of > whether Graftroot should be optional [1]. Yes, but the “tagging” emphasises more on the payer’s side: if the payer cannot guarantee that the payee woul

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Hi Johnson, The design considerations here seem similar to the ML discussion of whether Graftroot should be optional [1]. >While this seems fully compatible with eltoo, is there any other proposals >require NOINPUT, and is adversely affected by either way of tagging? As far as I can tell it sho

[bitcoin-dev] Safer NOINPUT with output tagging

NOINPUT is very powerful, but the tradeoff is the risks of signature replay. While the key holders are expected not to reuse key pair, little could be done to stop payers to reuse an address. Unfortunately, key-pair reuse has been a social and technical norm since the creation of Bitcoin (the fi