Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-06-19 Thread David A. Harding via bitcoin-dev
On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev 
wrote:
> I think you're assuming here that the attacker broadcast a particular
> state.  

Whoops, I managed to confuse myself despite looking at Bastien's
excellent explainer.  The attacker would be broadcasting the latest
state, so the honest counterparty would only need to send one blind
child.  However, the blind child will only be relayed by a Bitcoin peer
if the peer also has the parent transaction (the latest state) and, if
it has the parent transaction, you should be able to just getdata('tx',
$txid) that transaction from the peer without CPFPing anything.  That
will give you the preimage and so you can immediately resolve the HTLC
with the upstream channel.

Revising my conclusion from the previous post:

I think the strongman argument for the attack would be that the attacker
will be able to perform a targeted relay of the low-feerate
preimage-containing transaction to just miners---everyone else on the
network will receive the honest user's higher-feerate expired-timelock
transaction.  Unless the honest user happens to have a connection to a
miner's node, the user will neither be able to CPFP fee bump nor use
getdata to retrieve the preimage.

Sorry for the confusion.

-Dave


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-06-19 Thread David A. Harding via bitcoin-dev
On Fri, Jun 19, 2020 at 09:44:11AM +0200, Bastien TEINTURIER via Lightning-dev 
wrote:
> The gist is here, and I'd appreciate your feedback if I have wrongly
> interpreted some of the ideas:
> https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12

Quoted text below is from the gist:

> The trick to protect against a malicious participant that broadcasts a
> low-fee HTLC-success or Remote-HTLC-success transaction is that we can
> always blindly do a CPFP carve-out on them; we know their txid

I think you're assuming here that the attacker broadcast a particular
state.  However, in a channel which potentially had thousands of state
changes, you'd have to broadcast a blind child for each previous state
(or at least each previous state that pays the attacker more than the
latest state).  That's potentially thousands of transactions times
potentially dozens of peers---not impossible, but it seems messy.

I think there's a way to accomplish the same goal for less bandwidth and
zero fees.  The only way your Bitcoin peer will relay your blind child
is if it already has the parent transaction.  If it has the parent, you
can just request it using P2P getdata(type='tx', id=$txid).[1]  You can
batch multiple txid requests together (up to 50,000 IIRC) to minimize
overhead, making the average cost per txid a tiny bit over 36 bytes.
If you receive one of the transactions you request, you can extract the
preimage at no cost to yourself (except bandwidth).  If you don't
receive a transaction, then sending a blind child is hopeless
anyway---your peers won't relay it.

Overall, it's hard for me to guess how effective your proposal would be
at defeating the attack.  I think the strongman argument for the attack
would be that the attacker will be able to perform a targeted relay of
their outdated state to just miners---everyone else on the network
will receive the counterparty's honest final-state close.  Unless the
counterparty happens to have a connection to a miner's node, the
counterparty will neither be able to CPFP fee bump nor use getdata to
retrieve the preimage.

It seems to me it's practical for a motivated attacker to research which
IP addresses belong to miners so that they can target them, whereas
honest users won't practically be able to do that research (and, even if
they could, it would create a centralizing barrier to new miners
entering the market if users focused on maintaining connections to
previously-known miners).

-Dave

[1] You'd have to be careful to not attempt the getdata too soon after
you think the attacker broadcast their old state, but I think that
only means waiting a single block, which you have to do anyway to
see if the honest final-commitment transaction confirmed.  See
https://github.com/bitcoin/bitcoin/pull/18861



signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-19 Thread Jonas Nick via bitcoin-dev
> [...] we can use 2-party ECDSA to create 2-of-2 multisignature addresses that
> look the same as regular single-signature addresses[2]. Even the old-style
> p2pkh addresses starting with 1 can be CoinSwap addresses.

Probably worth considering that p2pkh, p2wpkh and p2sh are vulnerable to the
(well-known) birthday attack with 2^80 operations on average if they encode a
multisig policy [0]. This is a large number but not the security margin we are
used to.

It is possible to reduce the feasibility of the attack by requiring 2^80
interactions instead of purely offline operations. This works by adding a
commitment round for all public keys involved in the policy. Now in order to
test whether a public key results in a collision, the attacker must first engage
in a commitment protocol with that public key. The "Fast Secure Two-Party ECDSA
Signing" protocol by Lindell [1] already has such a commitment round (for
reasons unrelated to Bitcoin). For example, the Gotham City two-party ECDSA
wallet [2] has this security model because it builds on the Lindell scheme and
uses p2sh-p2wpkh.

[0] https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh
[1] https://eprint.iacr.org/2017/552.pdf
[2] https://github.com/KZen-networks/gotham-city


On 5/25/20 1:21 PM, Chris Belcher via bitcoin-dev wrote:
> === Abstract ===
> 
> Imagine a future where a user Alice has bitcoins and wants to send them
> with maximal privacy, so she creates a special kind of transaction. For
> anyone looking at the blockchain her transaction appears completely
> normal with her coins seemingly going from address A to address B. But
> in reality her coins end up in address Z which is entirely unconnected
> to either A or B.
> 
> Now imagine another user, Carol, who isn't too bothered by privacy and
> sends her bitcoin using a regular wallet which exists today. But because
> Carol's transaction looks exactly the same as Alice's, anybody analyzing
> the blockchain must now deal with the possibility that Carol's
> transaction actually sent her coins to a totally unconnected address. So
> Carol's privacy is improved even though she didn't change her behaviour,
> and perhaps had never even heard of this software.
> 
> In a world where advertisers, social media and other companies want to
> collect all of Alice's and Carol's data, such privacy improvement would
> be incredibly valuable. And also the doubt added to every transaction
> would greatly boost the fungibility of bitcoin and so make it a better
> form of money.
> 
> This undetectable privacy can be developed today by implementing
> CoinSwap, although by itself that isn't enough. There must be many
> building blocks which together make a good system. The software could be
> standalone as a kind of bitcoin mixing app, but it could also be a
> library that existing wallets can implement allowing their users to send
> Bitcoin transactions with much greater privacy.
> 
> == CoinSwap ==
> 
> Like CoinJoin, CoinSwap was invented in 2013 by Greg Maxwell[1]. Unlike
> CoinJoin it is relatively complicated to implement and so far has not
> been deployed. But the idea holds great promise, and fixes many of the
> problems of some kinds of CoinJoins. CoinSwap is the next step for
> on-chain bitcoin privacy.
> 
> CoinSwap is a way of trading one coin for another coin in a
> non-custodial way. It is closely related to the idea of an atomic swap.
> Alice and Bob can trade coins with each other by first sending to a
> CoinSwap address and having those coins then sent to Bob:
> 
> Alice's Address 1 > CoinSwap Address 1 > Bob's Address 1
> 
> An entirely separate set of transactions gives Bob's coins to Alice in
> return:
> 
> Bob's Address 2 > CoinSwap Address 2 > Alice's Address 2
> 
> Where the symbol > is a bitcoin transaction.
> 
> Privacy is improved because an observer of the blockchain cannot link
> Alice's Address 1 to Alice's Address 2, as there is no transaction
> between them. Alice's Address 2 could either be an address in Alice's
> wallet, or the address of someone else she wants to transfer money to.
> CoinSwap therefore breaks the transaction graph heuristic, which is the
> assumption that if a transaction A -> B is seen then the ownership of
> funds actually went from A to B.
> 
> CoinSwap doesnt break any of bitcoin's assumptions or features like an
> auditable supply or pruning. It can be built on today's bitcoin without
> any new soft forks.
> 
> CoinSwap can't improve privacy much on its own, so it requires other
> building block to create a truly private system.
> 
> === ECDSA-2P ===
> 
> The original CoinSwap idea uses 2-of-2 multisig. We can get a slightly
> bigger anonymity set by using 2-of-3 multisigs with a fake third public
> key. For a much greater anonymity set we can use 2-party ECDSA to create
> 2-of-2 multisignature addresses that look the same as regular
> single-signature addresses[2]. Even the old-style p2pkh addresses
> starting 

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-06-19 Thread Bastien TEINTURIER via bitcoin-dev
Good morning list,

Sorry for being (very) late to the party on that subject, but better late
than never.

A lot of ideas have been thrown at the problem and are scattered across
emails, IRC discussions,
and github issues. I've spent some time putting it all together in one
gist, hoping that it will
help stir the discussion forward as well as give newcomers all the
background they need to ramp up
on this issue and join the discussion, bringing new ideas to the table.

The gist is here, and I'd appreciate your feedback if I have wrongly
interpreted some of the ideas:
https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12

Readers of this list can probably directly skip to the "Future work"
section. I believe my
"alternative proposal" should loosely reflect Matt's proposal from the very
first mail of this
thread; note that I included anchors and new txs only in some places, as I
think they aren't
necessary everywhere.

My current state-of-mind (subject to change as I discover more potential
attacks) is that:

* The proposal to add more anchors and pre-signed txs adds non-negligible
complexity and hurts
small HTLCs, so it would be better if we didn't need it
* The blind CPFP carve-out trick is a one shot, so you'll likely need to
pay a lot of fees for it
to work which still makes you lose money in case an attacker targets you
(but the money goes to
miners, not to the attacker - unless he is the miner). It's potentially
hard to estimate what fee
you should put into that blind CPFP carve-out because you have no idea what
the current fee of the
pinned success transaction package is, so it's unsure if that solution will
really work in practice
* If we take a step back, the only attack we need to protect against is an
attacker pinning a
preimage transaction while preventing us from learning that preimage for at
least `N` blocks
(see the gist for the complete explanation). Please correct me if that
claim is incorrect as it
will invalidate my conclusion! Thus if we have:
* a high enough `cltv_expiry_delta`
* [off-chain preimage broadcast](
https://github.com/lightningnetwork/lightning-rfc/issues/783)
(or David's proposal to do it by sending txs that can be redeemed via only
the preimage)
* LN hubs (or any party commercially investing in running a lightning node)
participating in
various mining pools to help discover preimages
* decent mitigations for eclipse attacks
* then the official anchor outputs proposal should be safe enough and is
much simpler?

Thank you for reading, I hope the work I put into this gist will be useful
for some of you.

Bastien

Le ven. 24 avr. 2020 à 00:47, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

>
>
> On 4/23/20 8:46 AM, ZmnSCPxj wrote:
> >>> -   Miners, being economically rational, accept this proposal and
> include this in a block.
> >>>
> >>> The proposal by Matt is then:
> >>>
> >>> -   The hashlock branch should instead be:
> >>> -   B and C must agree, and show the preimage of some hash H (hashlock
> branch).
> >>> -   Then B and C agree that B provides a signature spending the
> hashlock branch, to a transaction with the outputs:
> >>> -   Normal payment to C.
> >>> -   Hook output to B, which B can use to CPFP this transaction.
> >>> -   Hook output to C, which C can use to CPFP this transaction.
> >>> -   B can still (somehow) not maintain a mempool, by:
> >>> -   B broadcasts its timelock transaction.
> >>> -   B tries to CPFP the above hashlock transaction.
> >>> -   If CPFP succeeds, it means the above hashlock transaction exists
> and B queries the peer for this transaction, extracting the preimage and
> claiming the A->B HTLC.
> >>
> >> Note that no query is required. The problem has been solved and the
> preimage-containing transaction should now confirm just fine.
> >
> > Ah, right, so it gets confirmed and the `blocksonly` B sees it in a
> block.
> >
> > Even if C hooks a tree of low-fee transactions on its hook output or
> normal payment, miners will still be willing to confirm this and the B hook
> CPFP transaction without, right?
>
> Correct, once it makes it into the mempool we can CPFP it and all the
> regular sub-package CPFP calculation will pick it
> and its descendants up. Of course this relies on it not spending any other
> unconfirmed inputs.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev