Re: [bitcoin-dev] SAS: Succinct Atomic Swap

[Dmitry Petukhov via bitcoin-dev]

I made a version of the TLA+ spec according to the suggested variant,
as I understood it from your description. This version is in
the separate branch in the SASwap repo, 'variant_ZmnSCPxj' [1]

If I understood and specified your variant correctly, there is a
deadlock possible after step 9, if Bob fails to publish success tx in
time. After refund tx becomes spendable, Alice cannot publish it via
mempool, because Bob can learn her secret and has a chance invalidate
her refund tx by giving his success tx to friendly miner, while taking
back the locked LTC because both secrets are known. At the same time,
Bob cannot publish success tx via mempool, because then Alice can do
the same thing, invalidating his success tx with refund tx via friednly
miner.

There is a possibility that this deadlock can be resolved if one
participant indeed has possibility to confirm their tx directly,
bypassing the mempool, so the counterparty won't learn the secret until
transaction is in the block. But then this just raises the cost of the
attack because the counterparty will need to invalidate (orphan) the
whole block instead of just a transaction in the mempool, after
learning the other secret from the recent block.

[1] https://github.com/dgpv/SASwap_TLAplus_spec/tree/variant_ZmnSCPxj

В Tue, 12 May 2020 04:41:43 +
ZmnSCPxj via bitcoin-dev  wrote:

> Good morning Ruben,
> 
> > Hi ZmnSCPxj,
> >
> > Thanks for your feedback :)
> >  
> > > CoinSwap for privacy is practically a "cross" chain atomic swap
> > > with the same chain and token for both sides of the swap  
> >
> > I agree, I didn't mean to imply that was new, only that this
> > protocol makes it more efficient.
> >  
> 
> Indeed; basically, any innovations in cross-chain swaps can be
> adapted to a CoinSwap (though not necessarily vice-versa, if a
> CoinSwap innovation requires certain specific blockchain features).
> 
> > > "Instead, Bob simply hands secretBob to Alice" is basically the
> > > same as private key turnover  
> >
> > Thanks for the link. I will add it to the links at the bottom of the
> > write-up, as I agree it's related. Do note there are a few key
> > differences:
> >
> > -   The swap is set up in an "asymmetric" way with only timelocks
> > on one side, so on the other side the swap never expires
> >  
> 
> An interesting setup.
> 
> So I was wondering why something like this would not work instead:
> 
> 0.  Alice has BTC, Bob has LTC, they agree on exchange rates and two
> future timelock L1 and L2 such that L1 < L2. 1.  Alice creates
> keypairs Alice[0] Alice[1] Alice[2], Bob creates Bob[0] Bob[1]
> Bob[2], and share the pubkeys. 2.  Alice creates, but does not sign,
> a funding tx on BTC whose output requires Alice[0] && Bob[0]. 3.  Bob
> creates a backout transaction spending the BTC funding txo, with an
> absolute timelock L1, whose output goes to Alice[2], then provides to
> Alice a signature for Bob[0] and requires an adaptor such that
> completing the signature with Alice[0] reveals Alice[1].
> 
>  nLockTime L1
> BTC funding txo ---> Alice[0] && Bob[0]--->  Alice[2]
>  reveals Alice[1]
> 
> 4.  Alice creates a timeout transaction spending the BTC funding txo,
> with an absolute timelock L2, whose output goes to Bob[2], then
> provides to Bob a signature for Alice[0] and requires an adaptor such
> that completing the signature with Bob[0] reveals Bob[1].
> 
>  nLockTime L2
> BTC funding txo ---> Alice[0] && Bob[0]--->  Bob[2]
>  reveals Bob[1]
> 
> 5.  Alice signs the BTC funding tx and broadcasts it.
> 6.  Alice and Bob wait for the BTC funding tx to be confirmed.
> 7.  Bob creates an LTC funding tx whose output requires Alice[1] &&
> Bob[1]. 8.  Alice and Bob wait for the LTC funding tx to be confirmed.
> 9.  Alice creates a success transaction spending the BTC funding txo,
> with no practical absolute timelock (current blockheight + 1), whose
> output goes to Bob[2], then provides to Bob a signature for Alice[0]
> and requires an adaptor such that completing the signature with
> Bob[0] reveals Bob[1].
> 
>  nLockTime now
> BTC funding txo ---> Alice[0] && Bob[0]--->  Bob[2]
>  reveals Bob[1]
> 
> 10.  Bob gives the secret key of Bob[1] to Alice.
> 11.  Alice gives the secret key of Alice[0] to Bob.
> 12.  Bob claims the BTC funding txo before L1.
> 
> Aborts and stalls:
> 
> * Aborts before step 5 are safe: no money is ever committed yet.
>   Stalls before step 5 can be promoted to aborts.
> * If aborted between step 5 and step 8, Alice reclaims her BTC via
> the backout transaction. Since Bob did not confirm any locked funds
> in LTC, revealing Alice[1] does not give Bob any extra funds it did
> not already have. If Bob stalls before step 8 Alice can abort at L1
> using the backout transaction.
> * If Alice stalls at step 9, Bob can force the completion using 

[bitcoin-dev] Bitcoin Core 0.20.0 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

0.20.0 Release Notes


Bitcoin Core version 0.20.0 is now available from:

  

Or through BitTorrent:


magnet:?xt=urn:btih:1845a0c66b6a728e183b9bd8c5d8c1611dddaaa3=bitcoin-core-0.20.0=https%3A%2F%2Fopenbittorrent.com%2F=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

How to Upgrade
==

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be 
migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.12+, and Windows 7 and newer.  Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them.  It is not recommended to use Bitcoin Core on
unsupported systems.

- From Bitcoin Core 0.20.0 onwards, macOS versions earlier than 10.12 are no
longer supported. Additionally, Bitcoin Core does not yet change appearance
when macOS "dark mode" is activated.

Known Bugs
==

The process for generating the source code release ("tarball") has changed in an
effort to make it more complete, however, there are a few regressions in
this release:

- - The generated `configure` script is currently missing, and you will need to
  install autotools and run `./autogen.sh` before you can run
  `./configure`. This is the same as when checking out from git.

- - Instead of running `make` simply, you should instead run
  `BITCOIN_GENBUILD_NO_GIT=1 make`.

Notable changes
===

P2P and network changes
- ---

 Removal of BIP61 reject network messages from Bitcoin Core

The `-enablebip61` command line option to enable BIP61 has been removed.
(#17004)

This feature has been disabled by default since Bitcoin Core version 0.18.0.
Nodes on the network can not generally be trusted to send valid messages
(including reject messages), so this should only ever be used when
connected to a trusted node.  Please use the alternatives recommended
below if you rely on this removed feature:

- - Testing or debugging of implementations of the Bitcoin P2P network protocol
  should be done by inspecting the log messages that are produced by a recent
  version of Bitcoin Core. Bitcoin Core logs debug messages
  (`-debug=`) to a stream (`-printtoconsole`) or to a file
  (`-debuglogfile=`).

- - Testing the validity of a block can be achieved by specific RPCs:

  - `submitblock`

  - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
potentially invalid POW

- - Testing the validity of a transaction can be achieved by specific RPCs:

  - `sendrawtransaction`

  - `testmempoolaccept`

- - Wallets should not assume a transaction has propagated to the network
  just because there are no reject messages.  Instead, listen for the
  transaction to be announced by other peers on the network.  Wallets
  should not assume a lack of reject messages means a transaction pays
  an appropriate fee.  Instead, set fees using fee estimation and use
  replace-by-fee to increase a transaction's fee if it hasn't confirmed
  within the desired amount of time.

The removal of BIP61 reject message support also has the following minor RPC
and logging implications:

- - `testmempoolaccept` and `sendrawtransaction` no longer return the P2P reject
  code when a transaction is not accepted to the mempool. They still return the
  verbal reject reason.

- - Log messages that previously reported the reject code when a transaction was
  not accepted to the mempool now no longer report the reject code. The reason
  for rejection is still reported.

Updated RPCs
- 

- - The RPCs which accept descriptors now accept the new `sortedmulti(...)` 
descriptor
  type which supports multisig scripts where the public keys are sorted
  lexicographically in the resulting script.  (#17056)

- - The `walletprocesspsbt` 

[bitcoin-core-dev] Bitcoin Core 0.20.0 released

[Wladimir J. van der Laan via bitcoin-core-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

0.20.0 Release Notes


Bitcoin Core version 0.20.0 is now available from:

  

Or through BitTorrent:


magnet:?xt=urn:btih:1845a0c66b6a728e183b9bd8c5d8c1611dddaaa3=bitcoin-core-0.20.0=https%3A%2F%2Fopenbittorrent.com%2F=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969%2Fannounce=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

How to Upgrade
==

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes in some cases), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be 
migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.12+, and Windows 7 and newer.  Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them.  It is not recommended to use Bitcoin Core on
unsupported systems.

- From Bitcoin Core 0.20.0 onwards, macOS versions earlier than 10.12 are no
longer supported. Additionally, Bitcoin Core does not yet change appearance
when macOS "dark mode" is activated.

Known Bugs
==

The process for generating the source code release ("tarball") has changed in an
effort to make it more complete, however, there are a few regressions in
this release:

- - The generated `configure` script is currently missing, and you will need to
  install autotools and run `./autogen.sh` before you can run
  `./configure`. This is the same as when checking out from git.

- - Instead of running `make` simply, you should instead run
  `BITCOIN_GENBUILD_NO_GIT=1 make`.

Notable changes
===

P2P and network changes
- ---

 Removal of BIP61 reject network messages from Bitcoin Core

The `-enablebip61` command line option to enable BIP61 has been removed.
(#17004)

This feature has been disabled by default since Bitcoin Core version 0.18.0.
Nodes on the network can not generally be trusted to send valid messages
(including reject messages), so this should only ever be used when
connected to a trusted node.  Please use the alternatives recommended
below if you rely on this removed feature:

- - Testing or debugging of implementations of the Bitcoin P2P network protocol
  should be done by inspecting the log messages that are produced by a recent
  version of Bitcoin Core. Bitcoin Core logs debug messages
  (`-debug=`) to a stream (`-printtoconsole`) or to a file
  (`-debuglogfile=`).

- - Testing the validity of a block can be achieved by specific RPCs:

  - `submitblock`

  - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
potentially invalid POW

- - Testing the validity of a transaction can be achieved by specific RPCs:

  - `sendrawtransaction`

  - `testmempoolaccept`

- - Wallets should not assume a transaction has propagated to the network
  just because there are no reject messages.  Instead, listen for the
  transaction to be announced by other peers on the network.  Wallets
  should not assume a lack of reject messages means a transaction pays
  an appropriate fee.  Instead, set fees using fee estimation and use
  replace-by-fee to increase a transaction's fee if it hasn't confirmed
  within the desired amount of time.

The removal of BIP61 reject message support also has the following minor RPC
and logging implications:

- - `testmempoolaccept` and `sendrawtransaction` no longer return the P2P reject
  code when a transaction is not accepted to the mempool. They still return the
  verbal reject reason.

- - Log messages that previously reported the reject code when a transaction was
  not accepted to the mempool now no longer report the reject code. The reason
  for rejection is still reported.

Updated RPCs
- 

- - The RPCs which accept descriptors now accept the new `sortedmulti(...)` 
descriptor
  type which supports multisig scripts where the public keys are sorted
  lexicographically in the resulting script.  (#17056)

- - The `walletprocesspsbt` 

[bitcoin-dev] Time-dilation Attacks on the Lightning Network

[Gleb Naumenko via bitcoin-dev]

Hi! I and Antoine Riard explored time-dilation attacks on Lightning.

We have a blogpost, which is probably too long to include in the email in full.
You can read it here: https://discrete-blog.github.io/time-dilation/
There’s also a paper we wrote: https://arxiv.org/abs/2006.01418


We believe this work should be interesting for anyone curious/excited about LN 
or other second-layer protocols in Bitcoin. We are very interested in your 
opinions!

Now, let me share the intro from the post with you (which is really a summary 
of the work), since it’s about the right size for a mailing list post. 
Hopefully, it would motivate you to read further.

Protocols on top of the Bitcoin base layer are really cool. They offer 
tremendous opportunities in terms of scalability, confidentiality, and 
functionality, at a cost of new security assumptions.

We all know payment channels have to be monitored, otherwise, the funds can be 
stolen. That sounds too abstract though. We decided to study what an attacker 
actually has to do to steal funds from LN users.

More specifically, we explored how peer-to-peer layer attacks can help with 
breaking the assumption above. Per time-dilation attacks, an attacker controls 
the victim’s access to the Bitcoin network (hard, but not impossible) and 
delays block delivery to the victim. After that, the attacker exploits that the 
victim can’t access recent blocks in a timely manner. In some cases, it is 
enough to isolate the victim only for two hours.

Then the attacker makes a couple (totally legit) actions on the Lightning 
Network towards the victim’s channels, and at the same time commits a different 
state instead. Since the victim is behind in terms of the latest blockchain 
tip, they cannot detect this and react as required by the protocol.

We demonstrate three different ways the attacker can steal funds from the 
victim, and discuss the feasibility/cost of these attacks. We also explore the 
broad scope of countermeasures, which may significantly increase the attack 
cost.

In short, the takeaways from our work are:

1. Many Lightning users (those with Bitcoin light clients) are currently 
vulnerable to Eclipse attacks.
2. Those Lightning users which run Bitcoin Core full nodes are more robust to 
Eclipse attacks, but the attacks are still possible as recent research suggests.
3. Eclipse attacks enable stealing funds via time-dilation.
4. Time-dilation attacks can’t be mitigated with just observing slow block 
arrival, so there is no simple solution to (3).
5. Thus, time-dilation is a practical way to steal funds from eclipsed users. 
Neither it requires hashrate nor targets merchants only. Light client users are 
a good target because they are easy to attack. Full node users are a good 
target because they are often used by major hubs (or service providers), and 
stealing their aggregate liquidiy might justify the high attack cost.
6. Strong anti-Eclipse measures is the key solution. WatchTowers are cool too.


Best,

Gleb Naumenko and Antoine Riard
___
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

[ZmnSCPxj via bitcoin-dev]

Good morning Chris again,


> For the avoidance of theft, it is probably better for Bob to wait for 
> Alice-side funding tx to confirm, probably deeply because reorgs suck.


Over in Lightning-land, we have a concept called "irrevocably committed".
This is a state where a newly-created contract can no longer be cancelled, by 
publishing an older state.
In Lightning, there is a short timeframe where a new state, and its directly 
previous state, are both still valid, until the previous state is revoked.
Only once the previous state (that does not contain the contract) has been 
revoked, and only the latest state is valid, can a forwarding node actually 
forward the payment.


This is roughly equivalent to the funding tx for the CoinSwap being confirmed.
Until a transaction is confirmed, the UTXOs it spends (i.e. the previous state) 
can still be validly spent by other alternate transactions.


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

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

[ZmnSCPxj via bitcoin-dev]

Good morning Dmitry,

> I made a version of the TLA+ spec according to the suggested variant,
> as I understood it from your description. This version is in
> the separate branch in the SASwap repo, 'variant_ZmnSCPxj' [1]
>
> If I understood and specified your variant correctly, there is a
> deadlock possible after step 9, if Bob fails to publish success tx in
> time. After refund tx becomes spendable, Alice cannot publish it via
> mempool, because Bob can learn her secret and has a chance invalidate
> her refund tx by giving his success tx to friendly miner, while taking
> back the locked LTC because both secrets are known. At the same time,
> Bob cannot publish success tx via mempool, because then Alice can do
> the same thing, invalidating his success tx with refund tx via friednly
> miner.

Indeed, this is precisely the issue Ruben pointed out.

Rationally, neither side will want this condition due to the deadlock and Bob 
will strive to avoid this, having a short real-world timeout after which Bob 
will force publication of the success tx if Alice does not respond in time.
There *is* a reason why it says "Bob claims the BTC funding txo before L1."

Of course, computers do crash occasionally, I am informed, so complete 
accidents may occur that way.
This can be mitigated by running multiple servers who are given copies of the 
success tx, and which will publish it regardless after a short sidereal time 
duration, unless countermanded by the main server (i,e, a dead man switch 
system).
With sufficient distribution the probability of this occurring can drop to 
negligible levels compared to other theoretical attacks.

Regards,
ZmnSCPxj

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

Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

[ZmnSCPxj via bitcoin-dev]

Good morning Gleb and Antoine,

This is good research, thank you for your work.

> **Targeting Per-Hop Packet Delay** is based on routing via the victim, and 
> the victim should have at least two channels with the attacker.

The existence of offchain-to-onchain swap services means that the attacker 
needs only build one channel to the victim for this attack to work.
Rather than route to themselves, the attacker routes to a convenient service 
providing such a swap service, and receives the stolen funds onchain, with no 
need even for an incoming channel from a different node.
(Of note as well, is that the onchain contract provided by such services is the 
same in spirit as those instantiated in channels of the Lightning Network, thus 
the same attack schema works on the onchain side.)

Indeed, the attack can be mounted on such a service directly.

Even without such a service, the incoming channel need not be directly 
connected to the victim.


> [Tor is tricky](https://arxiv.org/abs/1410.6079) too

Since the issue here is that eclipsing of Bitcoin nodes is risky, it strikes me 
that a mitigation would be to run your Bitcoin fullnode on clearnet while 
running your Lightning node over Tor.
Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on) 
"only" loses you the ability to pay, receive, or route (and thereby earn 
forwarding fees), but as long as your blockchain view is clear, it should be 
fine.

Of course, the Lightning node could still be correlated with the Bitcoin node 
when transactions are broadcast with the attached Bitcoin node (as noted in the 
paper).
Instead the Lightning node should probably connect, over Tor, to some random 
Bitcoin fullnodes / Electrum servers and broadcast txes to them.

And this seems to tie with what you propose: that the LN node should use a 
different view-fullnode from the broadcast-fullnode.


> if a node doesn’t observe a block within the last 30 minutes, it attempts to 
> make a new random connection to someone in the network.

A mitigation to this would be to run a background process which sleeps for 20 
minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.
It might want to `disconnectnode` any previous node it attempted to connect to.

However I note that the help for `addnode` contains the text "though such peers 
will not be synced from", which confuses me, since it also refers to the 
`-connect` command line option, and `-connect` means you only connect out to 
the specific nodes, so if those are not synced from huh?

And of course the interesting part is "how do we get a `${BITCOINNODE}` that we 
think is not part of the eclipsing attacker?"


> If a Lightning node is behind in its Bitcoin blockchain view, but Lightning 
> payments between honest nodes are still flowing through it, this node will 
> have a high routing failure rate. This would happen because honest nodes on 
> the routing path would reject the forwarded HTLC for being too close to 
> expired.

I am uncertain this would happen very often.
In the first place, the incoming HTLC would have "reasonable" timeouts, or else 
the incoming honest node would not have routed it at all, and the outgoing HTLC 
would be relative to this incoming one, so the outgoing honest node will still 
accept this.

The victim *could* instead check that the absolute timelocks seem very far in 
the future relative to its own view of the current blockheight.
(a forwarding node miht want to do that anyway to have an upper bound against 
griefing attacks)

What would definitely increase in failure rate would be payments arising from 
the victim node; the victim node believes the blockheight to be much lower than 
it actually is, and either the payee node, or some intermediate node along the 
route, will claim to have too little time to safely forward the funds.
This does not help for nodes which are primarily forwarding nodes.



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