Re: [Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network

[Christian Decker]

Matt Corallo  writes:
> Right, but there are approaches that are not as susceptible - an
> obvious, albeit somewhat naive, approach would be to define a fixed and
> proportional max fee, and pick a random (with some privacy properties eg
> biasing towards old or good-reputation nodes, routing across nodes
> hosted on different ISPs/Tor/across continents, etc) route that pays no
> more than those fees unless no such route is available. You could
> imagine hard-coding such fees to "fees that are generally available on
> the network as observed in the real world".

This is sort of what we do already in c-lightning, namely we set up a
fee budget of 0.5% and then select a random route within this
constraint. On top we also fuzz the amount and other parameters within
this range and similar ones in order to obfuscate the distance to the
recipient, i.e., slightly overpaying the recipient, but simulating a
shadow route.

So while not fixed in the network, we built our own fuzzing on top of
the real fees. The rationaly behind this is that users will simply not
care to optimize down to the satoshi, and the resulting randomization
helps privcay. We don't have real numbers but recent research results
show that attempting to squeeze the very last bit of fees out has a
detrimental effect on sender-receiver-privcay (surprise...).

Cheers,
Christian
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Remove from list

[pnewmanster]

Sent from my Samsung Galaxy smartphone.___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

[Max Dignan]

Hey Antoine,

Would PSBT (BIP 174 - 
https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki 
) be a good 
solution to this?

-Max___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

[lisa neigut]

hi max — great question. PSBT is a great protocol for wallet interop but a
bit overweight for tx collaboration between two peers

On Wed, Jan 29, 2020 at 17:29 Max Dignan  wrote:

> Hey Antoine,
>
> Would PSBT (BIP 174 -
> https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) be a good
> solution to this?
>
> -Max
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

[Antoine Riard]

Hey thanks for this proposal!

2 high-level questions:

What about multi-party tx construction ? By multi-party, let's define
Alice initiate a tx construction to Bob and then Bob announce a
construction to Caroll and "bridge" all inputs/outputs
additions/substractions
in both directions. I think the current proposal hold, if you are a bit more
tolerant and bridge peer don't send a tx_complete before receiving ones
from all its peers.

What about transactions format ? I think we should coordinate with Coinjoin
people to converge to a common one to avoid leaking protocol usage when
we can hinder under Taproot. Like setting the nLocktime or sorting inputs
in some protocol-specific fashion. Ideally we should have a BIP for format
but every layer 2 protocols its own set of messages concerning the
construction.

> nLocktime is always set to 0x00
Maybe we can implement anti-fee sniping and mask among wallet core
txn set:
https://github.com/bitcoin/bitcoin/blob/aabec94541e23a67a9f30dc2c80dab3383a01737/src/wallet/wallet.cpp#L2519
?

> In the case of a close, a failed collaborative close would result in an
error and a uninlateral close"
Or can we do first a mutual closing tx, hold tx broadcast for a bit if
"opt_dual_fund"
is signaled to see if a tx_construction + add_funding_input for the channel
is received
soon ? At least that would be a dual opt-in to know than one party can
submit a funding-outpoint
as part of a composed tx ?

Antoine

Le lun. 27 janv. 2020 à 20:51, lisa neigut  a écrit :

> Some of the feedback I received from the check-in for the dual-funding
> proposal this past Monday was along the lines that we look at simplifying
> for breaking it into smaller, more manageable chunks.
>
> The biggest piece of the dual-funding protocol update is definitely the
> move from a single peer constructing a transaction to two participants.
> We're also going to likely want to reuse this portion of the protocol for
> batched closings and splicing. To that extent, it seemed useful to
> highlight it in a separate email.
>
> This is a change from the existing proposal in the dual-funding PR #524
>  -- it allows
> for the removal of inputs and outputs.
>
> The set of messages are as follows.
>
>
> Note that the 'initiation' of this protocol will be different depending
> on the case of the transaction (open, close or splice):
>
> 1. type:   440 `tx_add_input`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
> * [`u64`:`sats`]
>
> * [`sha256`:`prevtx_txid`]
>
> * [`u32`:`prevtx_vout`]
>
> * [`u16`:`prevtx_scriptpubkey_len`]
>
> * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
>
> * [`u16`:`max_witness_len`]
>
> * [`u16`:`scriptlen`]
>
> * [`scriptlen*byte`:`script`]
>
> * [`byte`:`signal_rbf`]
>
> 1. type: 442 `tx_add_output`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
> * [`u64`:`sats`]
>
> * [`u16`:`scriptlen`]
>
> * [`scriptlen*byte`:`script`]
>
> 1. type: 444 `tx_remove_input`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
> * [`sha256`:`prevtx_txid`]
>
> * [`u32`:`prevtx_vout`]
>
> 1. type: 446 `tx_remove_output`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
> * [`u64`:`sats`]
>
> * [`u16`:`scriptlen`]
>
> * [`scriptlen*byte`:`script`]
>
> 1. type: 448 `tx_complete`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
> * [`u16`:`num_inputs`]
>
> * [`u16`:`num_outputs`]
>
> 1. type:  448 `tx_sigs`
>
> 2. data:
>
> * [`channel_id`:`channel_identifier`]
>
> * [`u16`:`num_witnesses`]
>
> * [`num_witnesses*witness_stack`:`witness_stack`]
>
> 1. subtype: `witness_stack`
>
> 2. data:
>
> * [`sha256`:`prevtx_txid`]
>
> * [`u32`:`prevtx_vout`]
>
> * [`u16`:`num_input_witness`]
>
> * [`num_input_witness*witness_element`:`witness_element`]
>
> 1. subtype: `witness_element`
>
> 2. data:
>
> * [`u16`:`len`]
>
> * [`len*byte`:`witness`]
>
>
>
> ## General Notes
>
> - Validity of inputs/outputs is not checked until both peers have sent
> consecutive `tx_complete`  messages.
>
> - Duplicate inputs or outputs is a protocol error.
>
> - Feerate is set by the initiator, or in the case of a closing
> transaction, negotiated before the transaction construction is initiated.
>
> - Every peer pays fees for the inputs + outputs they contribute, plus
> enough to cover the maximum estimate of their witnesses. Overpayment of
> fees is permissible.
>
> - Initiator is responsible for contributing the output/input in question,
> i.e. the
>
>   funding output in the case of an opening, or the funding input in the
> case of a close.
>
>   (This means that the opener will pay for the opening output). In the
> case of a splice,
>
>   the initiator of the splice pays for the funding tx's inclusion as an
> input and the
>
>   new 'funding tx' output.
>
> - Any contributor may signal that their input is RBF'able. The 

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

[Max Dignan]

Hey,

Ok gotcha now. Re-read your prior post. Thanks for the feedback both of you!

Thanks,
Max

> On Jan 29, 2020, at 9:00 PM, lisa neigut  wrote:
> 
> 
> hi max — great question. PSBT is a great protocol for wallet interop but a 
> bit overweight for tx collaboration between two peers
> 
>> On Wed, Jan 29, 2020 at 17:29 Max Dignan  wrote:
>> Hey Antoine,
>> 
>> Would PSBT (BIP 174 - 
>> https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) be a good 
>> solution to this?
>> 
>> -Max
>> ___
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

[Antoine Riard]

Hi Max,

Sorry by transaction format I didn't mean a binary transaction format,
but format like we use in BOLT3 :
https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md

My concern is, e.g LN implementations setting nLocktime to 0x,
Coinjoin wallets always disabling nSequence and core wallet transactions
doing anti-fee snipping. Now even if all of them are using Taproot outputs
you're still leaking what protocol/tooling you're using to an external
observer
due to discrepancies in transaction fields. So we should obfuscate or using
standard values as much as protocol semantics let us doing it to break chain
analysis heuristics.

Le mer. 29 janv. 2020 à 21:00, lisa neigut  a écrit :

> hi max — great question. PSBT is a great protocol for wallet interop but a
> bit overweight for tx collaboration between two peers
>
> On Wed, Jan 29, 2020 at 17:29 Max Dignan  wrote:
>
>> Hey Antoine,
>>
>> Would PSBT (BIP 174 -
>> https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) be a
>> good solution to this?
>>
>> -Max
>> ___
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev