[bitcoin-dev] Distributed Delegated Pre-Signed Transactions (DDPST)

2020-06-22 Thread Swambo, Jacob via bitcoin-dev
I am building a solution for distributed, delegated pre-signed transactions 
(DDPST). This post introduces what DDPST are and why I think they are relevant 
for multiple applications. If you are working on application that can benefit 
from such a construction and want me to use your application in the proof of 
concept code, please reach out. All feedback is welcome on the concept in 
general.

Pre-signed transactions (PSTs) are utilized in numerous off-chain protocols 
including Lightning Network, non-custodial trading, Statechains, and custody 
protocols. PSTs are useful because they enable restricted access to funds and 
their custody can be *delegated* with limited risk. Compare this with the 
arbitrary control over funds that comes with access to the private keys. It is 
conceivable then that a broad class of applications would benefit from a 
mechanism to securely delegate PSTs. A mechanism to *distribute* custody of 
PSTs across multiple entities can act as a practical countermeasure for 
numerous attacks (e.g. denial-of-service, bribery, blackmail, etc.). Moreover, 
systems of accountability among the custodians, with proofs of correct and 
incorrect behaviour, form a foundation for engineering incentive structures 
that align with the objectives of the application at hand. Finally, distributed 
custody of PSTs could enable new trust models for the privacy of delegated PSTs 
using multi-party computation.

# Examples

Consider first the example of vault-custody protocols [1], where there is a 
requirement for a distributed network monitoring and response system to detect 
breeches and trigger a recovery process. It is critical to protect against 
denial-of-service (DoS) attacks that seek to compromise a monitoring node in 
order to force the custody operation into a recovery process. In this attack 
the adversary broadcasts the recovery transaction and reduces the accessibility 
of the wallet owner's funds. A method for distributing custody of the recovery 
transaction offers defence-in-depth, and a method for delegating custody 
enables outsourcing the monitor and response service (see Watchtower 
implementations currently under development [2,3]). A further improvement for 
the protection of PSTs, that comes from distributing custody, is that 
*proactive* security models can be instanciated such that successful attacks 
must occur in a limited time-frame [4].

Consider next the example of justice transactions in the current Lightning 
Network model. Here, it is critical that justice transactions are broadcast in 
a timely manner in response to detecting that either party is attempting to 
close the channel with a prior state. Attacks rely on disrupting the broadcast 
of the justice transaction through, for example, bribing the watchtower to 
wait. The watchtower can broadcast late and claim that it was an honest failure 
due to network issues. The victim has no recourse to punish the watchtower nor 
the malicious channel participant. If instead the justice transaction was 
distributed among a set of independent watchtowers, and an accountability 
system was in-place for their actions, a more robust incentive structure could 
be engineered. Moreover, distributing custody of the justice transaction can 
provide a new privacy mechanism for both operational security of a business but 
also to mitigate targeted attacks such as bribery.

Best regards,
Jacob

# References

[1] Jacob Swambo, Spencer Hommel, Bob McElrath, and Bryan Bishop. Custody 
Protocols Using Bitcoin Vaults. 2020. https://arxiv.org/abs/2005.11776

[2] The eye of satoshi - lightning watchtower. 
https://github.com/talaia-labs/python-teos

[3] Private altruist watchtowers. 
https://github.com/lightningnetwork/lnd/blob/master/docs/watchtower.md

[4] Ran Canetti, Rosario Gennaro, and Amir Herzberg. Proactive security: 
Long-term protection against break-ins. CryptoBytes, 3:1–8, 1997.
___
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-22 Thread Bastien TEINTURIER via bitcoin-dev
Hey ZmnSCPxj,

I agree that in theory this looks possible, but doing it in practice with
accurate control
of what parts of the network get what tx feels impractical to me (but maybe
I'm wrong!).

It feels to me that an attacker who would be able to do this would break
*any* off-chain
construction that relies on absolute timeouts, so I'm hoping this is
insanely hard to
achieve without cooperation from a miners subset. Let me know if I'm too
optimistic on
this!

Cheers,
Bastien

Le lun. 22 juin 2020 à 10:15, ZmnSCPxj  a écrit :

> Good morning Bastien,
>
> > Thanks for the detailed write-up on how it affects incentives and
> centralization,
> > these are good points. I need to spend more time thinking about them.
> >
> > > This is one reason I suggested using independent pay-to-preimage
> > > transactions[1]
> >
> > While this works as a technical solution, I think it has some incentives
> issues too.
> > In this attack, I believe the miners that hide the preimage tx in their
> mempool have
> > to be accomplice with the attacker, otherwise they would share that tx
> with some of
> > their peers, and some non-miner nodes would get that preimage tx and be
> able to
> > gossip them off-chain (and even relay them to other mempools).
>
> I believe this is technically possible with current mempool rules, without
> miners cooperating with the attacker.
>
> Basically, the attacker releases two transactions with near-equal fees, so
> that neither can RBF the other.
> It releases the preimage tx near miners, and the timelock tx near
> non-miners.
>
> Nodes at the boundaries between those that receive the preimage tx and the
> timelock tx will receive both.
> However, they will receive one or the other first.
> Which one they receive first will be what they keep, and they will reject
> the other (and *not* propagate the other), because the difference in fees
> is not enough to get past the RBF rules (which requires not just a feerate
> increase, but also an increase in absolute fee, of at least the minimum
> relay feerate times transaction size).
>
> Because they reject the other tx, they do not propagate the other tx, so
> the boundary between the two txes is inviolate, neither can get past that
> boundary, this occurs even if everyone is running 100% unmodified Bitcoin
> Core code.
>
> I am not a mempool expert and my understanding may be incorrect.
>
> 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-22 Thread Bastien TEINTURIER via bitcoin-dev
Thanks for the detailed write-up on how it affects incentives and
centralization,
these are good points. I need to spend more time thinking about them.

This is one reason I suggested using independent pay-to-preimage
> transactions[1]
>

While this works as a technical solution, I think it has some incentives
issues too.
In this attack, I believe the miners that hide the preimage tx in their
mempool have
to be accomplice with the attacker, otherwise they would share that tx with
some of
their peers, and some non-miner nodes would get that preimage tx and be
able to
gossip them off-chain (and even relay them to other mempools).

If they are actively helping the attacker, they wouldn't spend the
pay-to-preimage tx,
unless they gain more from it than the share the attacker gives them. This
becomes
a simple bidding war, and the honest user will always be the losing party
here (the
attacker has nothing to lose). For this reason I'm afraid it wouldn't work
out in practice
as well as we'd hope...what do you think? And even if the honest user wins
the bidding
war, the attack still steals money from that user; it just goes into the
miner's pocket.

But from the perspective of a single LN node, it
> might make more sense to get the information and *not* share it
>

I think it depends. If this attack becomes doable in practice and we see it
happening,
LN routing nodes and service providers have a very high incentive to thwart
these attacks,
because otherwise they'd lose their business as people would leave the
lightning network.

As long as enough nodes think that way (with "enough" being a very hard to
define quantity),
this should mitigate the attack. The only risk would be a big "exit scam"
scenario, but the
coordination cost between all these nodes makes that scenario unlikely
(IMHO).

Thanks,
Bastien

Le sam. 20 juin 2020 à 12:37, David A. Harding  a écrit :

> 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 

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

2020-06-22 Thread ZmnSCPxj via bitcoin-dev
Good morning Bastien,

> Thanks for the detailed write-up on how it affects incentives and 
> centralization,
> these are good points. I need to spend more time thinking about them.
>
> > This is one reason I suggested using independent pay-to-preimage
> > transactions[1]
>
> While this works as a technical solution, I think it has some incentives 
> issues too.
> In this attack, I believe the miners that hide the preimage tx in their 
> mempool have
> to be accomplice with the attacker, otherwise they would share that tx with 
> some of
> their peers, and some non-miner nodes would get that preimage tx and be able 
> to
> gossip them off-chain (and even relay them to other mempools).

I believe this is technically possible with current mempool rules, without 
miners cooperating with the attacker.

Basically, the attacker releases two transactions with near-equal fees, so that 
neither can RBF the other.
It releases the preimage tx near miners, and the timelock tx near non-miners.

Nodes at the boundaries between those that receive the preimage tx and the 
timelock tx will receive both.
However, they will receive one or the other first.
Which one they receive first will be what they keep, and they will reject the 
other (and *not* propagate the other), because the difference in fees is not 
enough to get past the RBF rules (which requires not just a feerate increase, 
but also an increase in absolute fee, of at least the minimum relay feerate 
times transaction size).

Because they reject the other tx, they do not propagate the other tx, so the 
boundary between the two txes is inviolate, neither can get past that boundary, 
this occurs even if everyone is running 100% unmodified Bitcoin Core code.

I am not a mempool expert and my understanding may be incorrect.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev