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

2020-06-05 Thread ZmnSCPxj via bitcoin-dev
Good morning a third time Chris,

Now unrelated to the funding order, but one of the reasons why timeliness is 
desirable for CoinSwap is that if possible, we want to ensure that sends from a 
user wallet are not correlatable with receives into that wallet.
Thus, there is the strong suggestion that before sending to a payee, the user 
wallet should swap, then use the swapped funds to pay the payee, i.e. 
swap-on-pay.
JoinMarket does this in `sendpayment.py`, for example, and this is the 
recommended way to perform payments out of the JoinMarket wallet.

Let me propose an alternative: swap-on-receive+swap-on-change.

ZeroLink already suggests that wallets maintain two internal wallets: a pre-mix 
wallet and a post-mix wallet.
With swap-on-receive, when the user wants a receive address, the wallet gets it 
from the pre-mix wallet address.
Then, when wallet notices any unspent funds on any pre-mix wallet address, the 
wallet automatically swaps it into the post-mix wallet.
This is swap-on-receive.
Long-term HODLing goes into post-mix wallet addresses.

Then, when sending, the wallet selects from the post-mix wallet coins, and 
spends those coins directly into the payee address.
If there is no exact amount, it has to have change.
The change output does *not* go to the pre-mix or post-mix wallet address.
Instead, it goes to a 2-of-2 funding outpoint for a new swap immediately.

This lets the payee receive its funds quickly, as soon as the transaction 
confirms, without waiting for the CoinSwap to complete.
Of course, the user now has to be online to *fully* receive funds (the user 
cannot spend the funds until it is in the post-mix wallet).

Regards,
ZmnSCPxj
___
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-05 Thread ZmnSCPxj via bitcoin-dev
Good morning again Chris,

I am uncertain if you are aware, but some years ago somebody claimed that 
2p-ECDSA could use Scriptless Script as well over on lightning-dev.

* 
https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180426/fe978423/attachment-0001.pdf
* 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001221.html

I cannot claim to follow the math enough to say it is actually secure, but the 
idea does exist.

If this is sufficiently secure, we can fold the Spilman backout into the 
scriptless script swap as well.

* Alice creates secret keypairs A[0] = a[0] * G, A[1] = a[1] * G
* Bob creates secret keypairs B[0] = b[0] * G, B[1] = b[1] * G
* Alice creates (but does not sign) funding from Alice -> A[0] && B[0]
* Bob provides partial signature for A[0] && B[0] -(nLockTime=locktime1)-> 
Alice to Alice and Alice completes this signature and stashes it.
* Bob creates (but does not sign) funding from Bob -> A[1] && B[1]
* Alice provides partial signature for A[1] && B[1] -(nLockTime=lockTime2)-> 
Bob to Bob and Bob completes this signature and stashes it.
* Alice and Bob sign and broadcast their funding transactions.
  * This can safely be done in any order; Bob will refuse to continue with the 
protocol until it sees Alice funding is confirmed, and will abort if locktime2 
is too near.
* Alice waits for Bob funding tx to confirm.
* Alice provides a 2p-ECDSA adaptor signature for A[1] && B[1] --> Alice; the 
adaptor signature, when completed, reveals the secret a[0] to Bob.
* Bob waits for Alice funding tx to confirm.
* Bob provides the partial signature for the given adaptor signature for A[1] 
&& B[1] --> Alice and  Alice completes this signature and stashes it.
* Alice gives a[0] outright to Bob.
* Bob gives b[1] outright to Alice.
* Alice spends the A[1] && B[1] output before locktime2.
* Bob spends the A[0] && B[0] output before locktime1.

I also pointed out the griefing problem in Lightning also applies to SwapMarket.
Bob can limit the griefing problem by requiring that locktime2 <= now + 12, and 
requiring that locktime1 >= now + 60.
This means that Alice has to lock its funds for 10 hours if it forces Bob to 
lock its funds for 2 hours, making it undesirable as an attack on competing 
makers.
This does prevent chaining (no maker is going to accept the outgoing), but if 
Alice wants chaining it can always use the private key handed over to 
immediately start a funding tx with another Bob.

(This is not a good solution for griefing in the Lightning Network since 
channels are intended to be reused there, whereas the Spilman channels in 
CoinSwap exist only to allow funding transactions to confirm in any order 
onchain, and are used only for the specific swap; in Lightning the forwarding 
node has an incentive to release the incoming HTLC immediately instead of 
imposing the incoming wait time since the funding can be reused for a different 
payment, but in CoinSwap it cannot be reused anyway, so it could just let the 
incoming timelock lapse instead of releasing that encumbrance as would be done 
in Lightning.)

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

> I think I'm having trouble understanding this, does it work like this:
>
> Say we're in the 2-party coinswap case (Alice and Bob)
>
> We have Alice's funding transaction:
> Alice UTXO ---> 2of2 multisig (Alice+Bob)
>
> And we have the regular contract transaction
> 2of2 multisig (Alice+Bob) ---> Alice+timelock1 OR Bob+hashlock
>
> And you propose a second pre-signed transaction?
> 2of2 multisig (Alice+Bob) ---> Bob+timelock2

No, it is:

2of2 multisig (Alice+Bob) --(nLockTime=locktime1)-> Alice

The timelock is  imposed as a `nLockTime`, not as an `OP_CLTV` (so not in the 
output of the tx, but part of the tx), and the backout returns the funds to 
Alice, not sends it to Bob.
This transaction is created *before* the contract transaction.

The order is:

* Create (but not sign) Alice funding tx (Alice --> Alice+Bob).
* Create and sign Alice backout transaction (Alice+Bob -(nLockTime=locktime1)-> 
Alice).
* Create (but not sign) Bob funding tx (Bob --> Alice+Bob+sharedSecret).
* Create and sign Bob backout transaction (Alice+Bob+sharedSecret 
-(nLocktime=locktime2)-> Bob) where timelock2 < timelock1.
* Sign and broadcast funding txes.
  * At this point, even if Bob funding tx is confirmed but Alice funding tx is 
not, Bob can recover funds with the backout, but Alice cannot steal the funds 
(since there is no hashlock branch at this point).
* When Alice funding tx is confirmed, create and sign contract transaction 
(Alice+Bob --> Alice+timelock1 OR Bob+hashlock).
* When Bob funding tx is confirmed and Bob has received the Alice contract 
transaction, create and sign Bob contract transaction (Alice+Bob+sharedSecret 
--> Bob+timelock2 OR Alice+hashlock).
* Continue as normal.

In effect, the backout transaction creates a temporary Spilman unidirectional 
time-bound channel.
We just reuse the same timelock on the HTLC we expect to instantiate, as the 
time bound of the Spilman channel; the timelock exists anyway, we might as well 
reuse it for the Spilman.

Creation of the contract tx invalidates the backout tx (the backout tx is 
`nLockTime`d, the contract tx has no such encumbrance), but the backout allows 
Alice and Bob to fund their txes simultaneously without risk of race loss.
However, they do still have to wait for (deep) confirmation before signing 
contract transactions, and Bob has to wait for the incoming contract 
transaction as well before it signs its outgoing contract transaction.

The protocol is trivially extendable with more than one Bob.

The insight basically is that we can split CoinSwap into a "channel 
establishment" phase and "HTLC forwarding" phase followed by "HTLC resolution" 
and "private key handover".
HTLC forwarding and HTLC resolution are "done offchain" in the channels, and 
channel establishment can be done in any order, including reverse.

Indeed, the Spilman channel need not have the same timelock as the HTLC it will 
eventually host: it could have a shorter timelock, since the contract 
transaction has no `nLockTime` it can be instantiated (with loss of privacy due 
to the nonstandard script) before the Spilman timeout.

Regards,
ZmnSCPxj
___
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-05 Thread Chris Belcher via bitcoin-dev
Good day ZmnSCPxj,

>>> But S6 has the mild advantage that all the funding transactions paying to 
>>> 2-of-2s can appear on the same block, whereas chaining swaps will have a 
>>> particular order of when the transactions appear onchain, which might be 
>>> used to derive the order of swaps.
>>
>> On the other hand, funds claiming in S6 is also ordered in time, so
>> someone paying attention to the mempool could guess as well the order of
>> swaps.
>>
>> I think this is wrong, and that it's possible for the funding
>> transactions of chained/routed swaps to all be in the same block as well.
>>
>> In CoinSwap it's possible to get DOS'd without the other side spending
>> money if you broadcast your funding transaction first and the other side
>> simply disappears. You'd get your money back but you have to waste time
>> and spend miner fees. The other side didn't spend money to do this, not
>> even miner fees.
>>
>> From the point of view of us as a maker in the route, we know we won't
>> get DOS'd like this for free if we only broadcast our funding
>> transaction once we've seen the other side's funding transaction being
>> broadcast first. This should work as long as the two transactions have a
>> similar fee rate. There might be an attack involving hash power: If the
>> other side has a small amount of hash power and mines only their funding
>> transaction in a manner similar to a finney attack, then our funding
>> transaction should get mined very soon afterwards by another miner and
>> the protocol will continue as normal. If the other side has knowledge of
>> the preimage and uses it to do CPFP and take the money, then we can
>> learn that preimage and do our own CPFP to get our money back too.
> 
> How about RBF?
> 
> A taker Alice can broadcast the funding tx spending its own funds.
> The funding tx spends funds controlled unilaterally by Alice.
> Alice can sign a replacement transaction for those funds, spending them to an 
> address with unilateral control, and making the funding tx output with all 
> the obligations attached never get confirmed in the first place.
> 
> The chances may be small --- Bob can certainly monitor for Alice broadcasting 
> a replacement and counter-broadcast its own replacement --- but the risk 
> still exists.
> TANSTAAGM (There Aint No Such Thing As A Global Mempool) also means Alice 
> could arrange the replacement by other means, such as not using the 
> RBF-enabled flag, broadcasting the self-paying replacement near miner nodes, 
> and broadcasting the CoinSwap-expected funding tx near the Bob fullnode; Bob 
> fullnode will then reject attempts to replace it, but miners will also reject 
> the CoinSwap-expected funding tx and it will not confirm anyway.
> 
> 
> With the pre-SAS 4-tx setup, this potentially allows Alice to steal the funds 
> of Bob; after Alice gets its funding-tx-replacement confirmed together with 
> the Bob honest-funding-tx, Alice can use the contract transaction and publish 
> the preimage to take the Bob funds.
> Since the Alice-side funding tx has been replaced, knowledge of the hash 
> preimage will not help Bob any: the Alice funding tx has been replaced and 
> Bob cannot use the preimage to claim it (it does not exist).
> 
> 
> With SAS Alice cannot outright steal the Bob funds, but the Bob funds will 
> now be locked in a 2-of-2 and Alice can take it hostage (either Bob gives up 
> on the funds, i.e. donates its value to all HODLers, or Bob gives most of the 
> value to Alice).
> 
> 
> 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.
> 
> This at least makes it costly to perform this attack; you have to lock more 
> of your funds longer in order to induce a competitor to lock its funds.
> 
> 
> Come to think of it, the same issue probably holds for S6 as well, the 
> funding tx with the longest timelock has to confirm first before the next is 
> even broadcast, bleah.

Your RBF observation actually blows my idea out of the water. Not just
because of RBF but because of an attack by a miner.

Supposing that Alice starts with knowledge of the hash preimage, if she
uses RBF to make her funding transaction never confirm but allows Bob's
funding transaction to confirm, then Alice can use her preimage to take
the money from Bob's funding transaction. Bob will learn the value of
the preimage but it won't be much good to him because Alice's funding
transaction isn't valid anymore. Alice will get money from her funding
transaction and also money from Bob's funding transaction.

Because of this attack, it's pretty clear that a CoinSwap peer who
starts _without_ knowledge of the preimage must wait for the other
side's funding transaction to actually confirm, perhaps even with
multiple confirmations if they fear that the other side has access to
hashpower. For example, a miner could play the role of Alice and use
this attack to almost-risklessly steal Bob's 

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

2020-06-05 Thread Aymeric Vitte via bitcoin-dev
Hi,

As far as I understand your answer is "let's try to use what exists",
this is not what I am proposing and not the Tor network, no "standard"
exit nodes, different hidden services, decentralized anonymizer network
unlike the Tor network, nodes are anonymizing themselves

Comments below, please let me know what is unclear in the description of
the project so I can modify it because all the time I get the impression
that it is mixed with the Tor network while it just has a very little to
do with it, and I don't get that the simple principle of communicating
between nodes using the Tor protocol without RDV points is never considered

Regards,

Le 05/06/2020 à 13:44, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>> The issue each time there are discussions/research linking to Tor is that it 
>> is biased since the beginning because based on a wrong postulate: using the 
>> Tor network
>>
> Well, in the interest of using the wrong tool for a highly important job, let 
> me present this thought:
Then for an important job people should use the right tool...
>
> * The Tor network is weakened due to its dependence on a limited set of exit 
> nodes.
And centralized structure, limited set of nodes to make it short, for
some (or a lot) misbehaving, not designed for bitcoin, nothing prevents
bitcoin from operating its own anonymizer system, which I am proposing
> * "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services.
Good to a certain extent... if you want to hide that you are operating a
bitcoin node you can use RDV points (ie hidden services) but if you
don't care you just connect anonymized circuits between bitcoin nodes,
this is more "direct" and does not exist in the Tor network, this
includes light clients that can act as relays also
> * Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet 
> connections, the issue is with Tor-to-clearnet connections.
There are plenty of Tor-to-Tor issues, not theoretical but in the real
world, "Tor-to-clearnet" can be done outside of the Tor network, ie the
bitcoin network
> * Of course, no miner is going to run over Tor because latency, so all the 
> miners will be on clearnet.
Probably, again I am not proposing a remake of the Tor network, I don't
see the use for a miner to hide (neither for a bitcoin node to use RDV
points), but they can be part of the global anonymized system, please
see below
> * So make your own bridge between Tor and clearnet.
> * Run two fullnodes on your computer (with sufficient ingenuity, you can 
> probably share their block storages, or make one pruning).
> * One fullnode is on the public network but runs in `blocksonly` so it does 
> not propagate any transactions (which might be attached to your public IP).
> * The other fullnode is on the Tor network and has an `-addnode` to the 
> public-network node via `localhost`, which I assume is very hard for an 
> eclipse attacker to get at.
> * Use the Tor-fullnode to propagate your transactions.
Yes but one full node should be able to do this alone, ie implement both
interfaces, like miners and everybody in fact (or Peersm bridges with
bittorrent if you look at the history of the project)
>
> Of course, the eclipse attacker can still attack all Tor exit nodes and block 
> outgoing transaction traffic to perform eclipse attacks.
> And if you decide to propagate transactions to the public-network node then 
> you pretty much lose your privacy there.

Please see the convergence link, it's not based on the assumption that
"the more you are the better you can hide and the lesser you can get
attacked", this does not work at all, it's based on the assumption that
even with a reduced set of peers it becomes very difficult to know who
is doing what and whom is talking to whom, the concept of
exiting/bridging to clearnet(s) is not clearly detailed in this version
but appears on the drawings


___
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

2020-06-05 Thread ZmnSCPxj via bitcoin-dev
Good morning Aymeric,

> The issue each time there are discussions/research linking to Tor is that it 
> is biased since the beginning because based on a wrong postulate: using the 
> Tor network
>

Well, in the interest of using the wrong tool for a highly important job, let 
me present this thought:

* The Tor network is weakened due to its dependence on a limited set of exit 
nodes.
* "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services.
* Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet connections, 
the issue is with Tor-to-clearnet connections.
* Of course, no miner is going to run over Tor because latency, so all the 
miners will be on clearnet.
* So make your own bridge between Tor and clearnet.
* Run two fullnodes on your computer (with sufficient ingenuity, you can 
probably share their block storages, or make one pruning).
* One fullnode is on the public network but runs in `blocksonly` so it does not 
propagate any transactions (which might be attached to your public IP).
* The other fullnode is on the Tor network and has an `-addnode` to the 
public-network node via `localhost`, which I assume is very hard for an eclipse 
attacker to get at.
* Use the Tor-fullnode to propagate your transactions.

Of course, the eclipse attacker can still attack all Tor exit nodes and block 
outgoing transaction traffic to perform eclipse attacks.
And if you decide to propagate transactions to the public-network node then you 
pretty much lose your privacy there.

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

2020-06-05 Thread Aymeric Vitte via bitcoin-dev

Le 04/06/2020 à 04:58, ZmnSCPxj via bitcoin-dev a écrit :
>> [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.
>

The issue each time there are discussions/research linking to Tor is
that it is biased since the beginning because based on a wrong
postulate: using the Tor network

I will not elaborate on this again, it's an obvious very bad idea to use
the Tor network for bitcoin

It's not a bad idea to use the Tor protocol with no story of exit nodes
and hidden services, linking again to:
https://github.com/Ayms/node-Tor#phase-4-and-phase-5

And new link: http://www.peersm.com/Convergence-2020.pdf "A universal
and generic architecture to anonymize any application or protocol and
turn it into an independent decentralized p2p network inside browsers
and servers, with browsers acting as servers"

LN and bitcoin nodes would be relays and/or RDV points and/or clients
and serving parties, some Tor network nodes could be used in the middle
also (relays only) but in any case sybils/eclipse attacks become much
more difficult to perform (or unlikely depending on how the peer
discovery system is designed)

bitcoin | node-Tor |bitcoin and LN.pipe(node-Tor)

Then question for possible future tests: is there a simple way to pipe
the bitcoin protocol via stdin/stdout? (the socks interface could be
used but we already saw that it did raise issues)

-- 
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

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