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

2020-06-20 Thread ZmnSCPxj via bitcoin-dev
Good morning again,

> Good morning Dave,
>
> > ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> > hoping one of Bitcoin's several inventive cryptographers would come
> > along and describe how someone with an adaptor signature could use that
> > information to create a pubkey that could be put into a transaction with
> > a second output that OP_RETURN included the serialized adaptor
> > signature. The pubkey would be designed to be spendable by anyone with
> > the final signature in a way that revealed the hidden value to the
> > pubkey's creator, allowing them to resolve the PTLC. But if that's
> > fundamentally not possible, I think we could advocate for making
> > pay-to-revealed-adaptor-signature possible using something like
> > OP_CHECKSIGFROMSTACK.[3]
>
> 
>
> The signed message could be a signature to `SIGHASH_NONE`, finally an actual 
> use for that flag.

If you are going to embed it in an `OP_RETURN` in the same transaction, you 
also need `SIGHASH_ANYPREVOUT`, otherwise you cannot embed the adaptor 
signature for spending from that transaction in the transaction being spent, it 
also implies `A[p4s] = a[p4s] * G` is a one-time-use keypair.

Regards,
ZmnSCPxj
___
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-20 Thread ZmnSCPxj via bitcoin-dev
Good morning Dave,

> ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> hoping one of Bitcoin's several inventive cryptographers would come
> along and describe how someone with an adaptor signature could use that
> information to create a pubkey that could be put into a transaction with
> a second output that OP_RETURN included the serialized adaptor
> signature. The pubkey would be designed to be spendable by anyone with
> the final signature in a way that revealed the hidden value to the
> pubkey's creator, allowing them to resolve the PTLC. But if that's
> fundamentally not possible, I think we could advocate for making
> pay-to-revealed-adaptor-signature possible using something like
> OP_CHECKSIGFROMSTACK.[3]


Not a cryptographer, I just play one on the Internet, but maybe the 
pay-for-signature construction could work...?

Assuming a PTLC has a pointlocked branch, which involves signing with MuSig(A, 
B).
A offers to B the amount if B reveals the secret `t` behind `T = t * G`; A 
knows `T` but not `t`.
This is done by B handing over `R[B]` and `s'[B]`:

R = R[A] + R[B] + T
s'[B] = r[B] + h(MuSig(A, B) | R | m) * b

Then A provides its partial signature to B.

s[A] = r[A] + h(MuSig(A, B) | R | m) * a

B has to complete the signature by:

s = s[A] + s'[B] + t

Since A knows both `s[A]` and `s'[B]`, once it knows `s`, it can compute `t`.


Now, we can massage the equation for `s`:

s = r[A] + h(MuSig(A, B) | R | m) * a + r[B] + h(MuSig(A, B) | R | m) * b + 
t
; multiply both sides by G
s * G = r[A] * G + h(MuSig(A, B) | R | m) * a * G + r[B] * G + h(MuSig(A, 
B) | R | m) * b * G + t * G
; replace with public points
s * G = R[A] + h(MuSig(A, B) | R | m) * A + R[B] + h(MuSig(A, B) | R | m) * 
B + T

Note that A can compute `s * G` above, because it generated `R[A]`, was given 
`R[B]` and `T`, and knows who `A` and `B` are.

So what A needs to do is to offer a fund that can only be claimed by leaking 
knowledge of `s` behind `s * G`.
A can do this by creating a new keypair `A[p4s] = a[p4s] * G` and putting a 
fund into it.

Then A generates an `R[A][p4s] = r[A][p4s] * G`, and computes:

R[p4s] = R[A][p4s] + s * G
s'[A][p4s] = r[A][p4s] + h(A | R[p4s] | m) * a[p4s]

The signed message could be a signature to `SIGHASH_NONE`, finally an actual 
use for that flag.

A reveals publicly (in an `OP_RETURN` as you suggest):

* `R[A][p4s]`
* `s * G`
* `s'[A][p4s]`
* `A[p4s]` - Already the Schnorr output pubkey.

In order to complete the above signature, a third party C has to learn `s` from 
B.

The third party has to scan every onchain 1-of-1 signature for an `s` that 
matches `s * G`, so there is greater processing (point multiplies are more 
expensive than hashes, also there are more 1-of-1s).
But once learned, the third party can complete the signature and claim the 
funds.
And A then learns `s`, from which it can derive `t`.

The third party learns about which channel (i.e. the UTXO that was spent to 
create the PTLC in the first place), but never learns `t` or `T`, which is a 
small but nice privacy bonus.


Regards,
ZmnSCPxj
___
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-20 Thread David A. Harding via bitcoin-dev
On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote:
> We're simply missing information, so it looks like the only good
> solution is to avoid being in that situation by having a foot in
> miners' mempools.

The problem I have with that approach is that the incentive is to
connect to the highest hashrate pools and ignore the long tail of
smaller pools and solo miners.  If miners realize people are doing this,
they may begin to charge for information about their mempool and the
largest miners will likely be able to charge more money per hashrate
than smaller miners, creating a centralization force by increasing
existing economies of scale.

Worse, information about a node's mempool is partly trusted.  A node can
easily prove what transactions it has, but it can't prove that it
doesn't have a certain transaction.  This implies incumbent pools with a
long record of trustworthy behavior may be able to charge more per
hashrate than a newer pools, creating a reputation-based centralizing
force that pushes individual miners towards well-established pools.

This is one reason I suggested using independent pay-to-preimage
transactions[1].  Anyone who knows the preimage can mine the
transaction, so it doesn't provide reputational advantage or direct
economies of scale---pay-to-preimage is incentive equivalent to paying
normal onchain transaction fees.  There is an indirect economy of
scale---attackers are most likely to send the low-feerate
preimage-containing transaction to just the largest pools, so small
miners are unlikely to learn the preimage and thus unlikely to be able
to claim the payment.  However, if the defense is effective, the attack
should rarely happen and so this should not have a significant effect on
mining profitability---unlike monitoring miner mempools which would have
to be done continuously and forever.

ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2]  I was
hoping one of Bitcoin's several inventive cryptographers would come
along and describe how someone with an adaptor signature could use that
information to create a pubkey that could be put into a transaction with
a second output that OP_RETURN included the serialized adaptor
signature.  The pubkey would be designed to be spendable by anyone with
the final signature in a way that revealed the hidden value to the
pubkey's creator, allowing them to resolve the PTLC.  But if that's
fundamentally not possible, I think we could advocate for making
pay-to-revealed-adaptor-signature possible using something like
OP_CHECKSIGFROMSTACK.[3]

[1] 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html
[2] 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002667.html
[3] https://bitcoinops.org/en/topics/op_checksigfromstack/

> Do you think it's unreasonable to expect at least some LN nodes to
> also invest in running nodes in mining pools, ensuring that they learn
> about attackers' txs and can potentially share discovered preimages
> with the network off-chain (by gossiping preimages found in the
> mempool over LN)?

Ignoring my concerns about mining centralization and from the
perspective of just the Lightning Network, that doesn't sound
unreasonable to me.  But from the perspective of a single LN node, it
might make more sense to get the information and *not* share it,
increasing your security and allowing you to charge lower routing fees
compared to your competitors.  This effect would only be enhanced if
miners charged for their mempool contents (indeed, to maximize their
revenue, miners might require that their mempool subscribers don't share
the information---which they could trivially enforce by occasionally
sending subscribers a preimage specific to the subscriber and seeing if
it propagated to the public network).

> I think that these recent attacks show that we need (at least some)
> off-chain nodes to be somewhat heavily invested in on-chain operations
> (layers can't be fully decoupled with the current security assumptions
> - maybe Eltoo will help change that in the future?).

I don't see how eltoo helps.  Eltoo helps ensure you reach the final
channel state, but this problem involves an abuse of that final state.

-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-20 Thread Bastien TEINTURIER via bitcoin-dev
Hello Dave and list,

Thanks for your quick answers!

The attacker would be broadcasting the latest
> state, so the honest counterparty would only need to send one blind
> child.
>

Exactly, if the attacker submits an outdated transaction he would be
shooting himself in the foot,
as we could claim the revocation paths when seeing the transaction in a
block and get all the
channel funds (since the attacker's outputs will be CSV-locked).

The only way your Bitcoin peer will relay your blind child
> is if it already has the parent transaction.
>

That's an excellent point that I missed in the blind CPFP carve-out trick!
I think this makes the
blind CPFP carve-out quite hard in practice (even using getdata - thanks
for detailing that option)...

In the worst case scenario where most miners' mempools contain the
attacker's tx and the rest of
the network's mempools contains the honest participant's tx, I think there
isn't much we can do.
We're simply missing information, so it looks like the only good solution
is to avoid being in that
situation by having a foot in miners' mempools. Do you think it's
unreasonable to expect at least
some LN nodes to also invest in running nodes in mining pools, ensuring
that they learn about
attackers' txs and can potentially share discovered preimages with the
network off-chain (by
gossiping preimages found in the mempool over LN)? I think that these
recent attacks show that
we need (at least some) off-chain nodes to be somewhat heavily invested in
on-chain operations
(layers can't be fully decoupled with the current security assumptions -
maybe Eltoo will help
change that in the future?).

Thank you for your time!
Bastien



Le ven. 19 juin 2020 à 22:53, David A. Harding  a écrit :

> 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev