Coder Social home page Coder Social logo

teleport-transactions's Introduction

Teleport Transactions

Teleport Transactions is software aiming to improve the privacy of Bitcoin.

Suppose Alice has bitcoin 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 Bitcoin 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. 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 institutions want to collect all of Alice's and Carol's data, such privacy improvement is incredibly valuable. And the doubt added to every transaction would greatly boost the fungibility of Bitcoin and so make it a better form of money.

Project design document: Design for a CoinSwap Implementation for Massively Improving Bitcoin Privacy and Fungibility

Contents

State of the project

The project is nearly usable, though it doesnt have all the necessary features yet. The code written so far is published for developers and power users to play around with. It doesn't have config files yet so you have to edit the source files to configure stuff. It is possible to run it on mainnet, but only the brave will attempt that, and only with small amounts.

How to create a CoinSwap on regtest with yourself

  • Install rust on your machine.

  • Start up Bitcoin Core in regtest mode. Make sure the RPC server is enabled with server=1 and that rpc username and password are set with rpcuser=yourrpcusername and rpcpassword=yourrpcpassword in the configuration file.

  • Download the latest release. Open the file src/lib.rs and edit the RPC username and password right at the top of the file. Make sure your Bitcoin Core has a wallet called teleport, or edit the name in the same place.

  • Create three teleport wallets by running cargo run -- --wallet-file-name=<wallet-name> generate-wallet thrice. Instead of <wallet-name>, use something like maker1.teleport, maker2.teleport and taker.teleport.

  • Use cargo run -- --wallet-file-name=maker1.teleport get-receive-invoice to obtain 3 addresses of the maker1 wallet, and send regtest bitcoin to each of them (amount 5000000 satoshi or 0.05 BTC in this example). Also do this for the maker2.teleport and taker.teleport wallets. Get the transactions confirmed.

  • Check the wallet balances with cargo run -- --wallet-file-name=maker1.teleport wallet-balance. Example:

$ cargo run -- --wallet-file-name=maker1.teleport wallet-balance
coin             address                    type   conf    value
8f6ee5..74e813:0 bcrt1q0vn5....nrjdqljtaq   seed   1       0.05000000 BTC
d548a8..cadd5e:0 bcrt1qaylc....vnw4ay98jq   seed   1       0.05000000 BTC
604ca6..4ab5f0:1 bcrt1qt3jy....df6pmewmzs   seed   1       0.05000000 BTC
coin count = 3
total balance = 0.15000000 BTC
$ cargo run -- --wallet-file-name=maker2.teleport wallet-balance
coin             address                    type   conf    value
d33f06..30dd07:0 bcrt1qh6kq....e0tlfrzgxa   seed   1       0.05000000 BTC
8aaa89..ef5613:0 bcrt1q9vyj....plh8x37n7g   seed   1       0.05000000 BTC
383ffe..127065:1 bcrt1qlwzv....pdqtrg0xuu   seed   1       0.05000000 BTC
coin count = 3
total balance = 0.15000000 BTC
$ cargo run -- --wallet-file-name=taker.teleport wallet-balance
coin             address                    type   conf    value
5f4331..d53f14:0 bcrt1qmflt....q2ucgf2teu   seed   1       0.05000000 BTC
6252ee..d827b0:0 bcrt1qu9mk....pwpedjyl9u   seed   1       0.05000000 BTC
ac88da..e3ead6:0 bcrt1q3xdx....e7gxtcgrfg   seed   1       0.05000000 BTC
coin count = 3
total balance = 0.15000000 BTC
  • On another terminal run a watchtower with cargo run -- run-watchtower. You should see the message Starting teleport watchtower. In the teleport project, contracts are enforced with one or more watchtowers which are required for the coinswap protocol to be secure against the maker's coins being stolen.

  • On one terminal run a maker server with cargo run -- --wallet-file-name=maker1.teleport run-yield-generator 6102. You should see the message Listening on port 6102.

  • On another terminal run another maker server with cargo run -- --wallet-file-name=maker2.teleport run-yield-generator 16102. You should see the message Listening on port 16102.

  • On another terminal start a coinswap with cargo run -- --wallet-file-name=taker.teleport do-coinswap 500000. When you see the terminal messages waiting for funding transaction to confirm and waiting for maker's funding transaction to confirm then tell regtest to generate another block (or just wait if you're using testnet).

  • Once you see the message successfully completed coinswap on all terminals then check the wallet balance again to see the result of the coinswap. Example:

$ cargo run -- --wallet-file-name=maker1.teleport wallet-balance
coin             address                    type   conf    value
9bfeec..0cc468:0 bcrt1qx49k....9cqqrp3kt0 swapcoin 2       0.00134344 BTC
973ab4..48f5b7:1 bcrt1qdu4j....ru3qmw4gcf swapcoin 2       0.00224568 BTC
2edf14..74c3b9:0 bcrt1qfw6z....msrsdx9sl0 swapcoin 2       0.00131088 BTC
bd6321..217707:0 bcrt1q35g8....rt6al6kz7s   seed   1       0.04758551 BTC
c6564e..40fb64:0 bcrt1qrnzc....czs840p4np   seed   1       0.04947775 BTC
08e857..c8c67b:0 bcrt1qdxdg....k7882f0ya2   seed   1       0.04808502 BTC
coin count = 6
total balance = 0.15004828 BTC
$ cargo run -- --wallet-file-name=maker2.teleport wallet-balance
coin             address                    type   conf    value
9d8895..e32645:1 bcrt1qm73u....3h6swyege3 swapcoin 3       0.00046942 BTC
7cab11..07ff62:1 bcrt1quumg....gtjs29jt8t swapcoin 3       0.00009015 BTC
289a13..ab4672:0 bcrt1qsavn....t5dsac43tl swapcoin 3       0.00444043 BTC
9bfeec..0cc468:1 bcrt1q24f8....443ts4rzz0   seed   2       0.04863932 BTC
973ab4..48f5b7:0 bcrt1q5klz....jhhtlyjpkg   seed   2       0.04773708 BTC
2edf14..74c3b9:1 bcrt1qh2aw....7xx8wft658   seed   2       0.04867188 BTC
coin count = 6
total balance = 0.15004828 BTC
$ cargo run -- --wallet-file-name=taker.teleport wallet-balance
coin             address                    type   conf    value
9d8895..e32645:0 bcrt1qevgn....6nhl2yswa7   seed   3       0.04951334 BTC
7cab11..07ff62:0 bcrt1qxs5f....0j8khru45s   seed   3       0.04989261 BTC
289a13..ab4672:1 bcrt1qkwka....g9ts2ch392   seed   3       0.04554233 BTC
bd6321..217707:1 bcrt1qat5h....vytquawwke swapcoin 1       0.00239725 BTC
c6564e..40fb64:1 bcrt1qshwp....3x8qjtwdf6 swapcoin 1       0.00050501 BTC
08e857..c8c67b:1 bcrt1q37lf....5tvqndktw6 swapcoin 1       0.00189774 BTC
coin count = 6
total balance = 0.14974828 BTC

How to create a CoinSwap on networks other than regtest

  • This is done in pretty much the same way as on the regtest network. On public networks you don't always have to coinswap with yourself by creating and funding multiple wallets, instead you could coinswap with other users out there.

  • Teleport detects which network it's on by asking the Bitcoin node it's connected to via json-rpc. So to switch between networks like regtest, signet, testnet or mainnet (for the brave), make sure the RPC host and port are correct in src/lib.rs.

  • You will need Tor running on the same machine, then open the file src/directory_servers.rs and make sure the const TOR_ADDR has the correct Tor port.

  • To see all the advertised offers out there, use the download-offers subroutine: cargo run -- download-offers:

$ cargo run -- download-offers
n   maker address                                                          max size     min size     abs fee      amt rel fee  time rel fee minlocktime
0   5wlgs4tmkc7vmzsqetpjyuz2qbhzydq6d7dotuvbven2cuqjbd2e2oyd.onion:6102    348541       10000        1000         10000000     100000       48
1   eitmocpmxolciziezpp6vzvhufg6djlq2y4oxpm436w5kpzx4tvfgead.onion:16102   314180       10000        1000         10000000     100000       48
  • To run a yield generator (maker) on any network apart from regtest, you will need to create a tor hidden service for your maker. Search the web for "setup tor hidden service", a good article is this one. When you have your hidden service hostname, copy it into the field near the top of the file src/maker_protocol.rs. Run with cargo run -- --wallet-file-name=maker.teleport run-yield-generator (note that you can omit the port number, the default port is 6102, specifying a different port number is only really needed for regtest where multiple makers are running on the same machine).

  • After a successful coinswap created with do-coinswap, the coins will still be in the wallet. You can send them out somewhere else using the command direct-send and providing the coin(s). For example cargo run -- --wallet-file-name=taker.teleport direct-send max <destination-address> 9bfeec..0cc468:0. Coins in the wallet can be found by running wallet-balance as above.

How to recover from a failed coinswap

  • CoinSwaps can sometimes fail. Nobody will lose their funds, but they can have their time wasted and have spent miner fees without achieving any privacy gain (or even making their privacy worse, at least until scriptless script contracts are implemented). Everybody is incentivized so that this doesnt happen, and takers are coded to be very persistent in reestablishing a connection with makers before giving up, but sometimes failures will still happen.

  • The major way that CoinSwaps can fail is if a taker locks up funds in a 2-of-2 multisig with a maker, but then that maker becomes non-responsive and so the CoinSwap doesn't complete. The taker is left with their money in a multisig and has to use their pre-signed contract transaction to get their money back after a timeout. This section explains how to do that.

  • Failed or incomplete coinswaps will show up in wallet display in another section: cargo run -- --wallet-file-name=taker.teleport wallet-balance. Example:

= spendable wallet balance =
coin             address                    type   conf    value
9cd867..f80d57:1 bcrt1qgscq....xkxg68mq02   seed   212     0.11103591 BTC
13a0f4..947ab8:1 bcrt1qwfyl....wf0eyf5kuf   seed   212     0.07666832 BTC
901514..10713b:0 bcrt1qghs3....qsg8al2ch4   seed   95      0.04371040 BTC
2fe664..db1a59:0 bcrt1ql83h....hht5vc97dl   seed   94      0.50990000 BTC
coin count = 4
total balance = 0.74131463 BTC
= incomplete coinswaps =
coin             type     preimage locktime/blocks conf    value
10149d..0d0314:1 timelock unknown         9        24      0.00029472 BTC
b36e34..51fa3b:0 timelock unknown         9        24      0.00905248 BTC
2b2e2d..c6db9e:1 timelock unknown         9        24      0.00065280 BTC
outgoing balance = 0.01000000 BTC
hashvalue = a4c2fe816bf18afb8b1861138e57a51bd70e29d4
  • In this example there is an incomplete coinswap involving three funding transactions, we must take the hashvalue a4c2fe816bf18afb8b1861138e57a51bd70e29d4 and pass it to the main subroutine: cargo run -- --wallet-file-name=taker.teleport recover-from-incomplete-coinswap a4c2fe816bf18afb8b1861138e57a51bd70e29d4.

  • Displaying the wallet balance again (cargo run -- --wallet-file-name=taker.teleport wallet-balance) after the transactions are broadcast will show the coins in the timelocked contracts section:

= spendable wallet balance =
coin             address                    type   conf    value
9cd867..f80d57:1 bcrt1qgscq....xkxg68mq02   seed   212     0.11103591 BTC
13a0f4..947ab8:1 bcrt1qwfyl....wf0eyf5kuf   seed   212     0.07666832 BTC
901514..10713b:0 bcrt1qghs3....qsg8al2ch4   seed   95      0.04371040 BTC
2fe664..db1a59:0 bcrt1ql83h....hht5vc97dl   seed   94      0.50990000 BTC
coin count = 4
total balance = 0.74131463 BTC
= live timelocked contracts =
coin             hashvalue  timelock conf    locked?  value
452a99..95f364:0 a4c2fe81.. 9        0       locked   0.00904248 BTC
dcfd27..56108a:0 a4c2fe81.. 9        0       locked   0.00064280 BTC
6a8328..f2f5ae:0 a4c2fe81.. 9        0       locked   0.00028472 BTC
  • Right now these coins are protected by timelocked contracts which are not yet spendable, but after a number of blocks they will be added to the spendable wallet balance, where they can be spent either in a coinswap or with direct-send.

Developer resources

How CoinSwap works

In a two-party coinswap, Alice and Bob can swap a coin in a non-custodial way, where neither party can steal from each other. At worst, they can waste time and miner fees.

To start a coinswap, Alice will obtain one of Bob's public keys and use that to create a 2-of-2 multisignature address (known as Alice's coinswap address) made from Alice's and Bob's public keys. Alice will create a transaction (known as Alice's funding transaction) sending some of her coins (known as the coinswap amount) into this 2-of-2 multisig, but before she actually broadcasts this transaction she will ask Bob to use his corresponding private key to sign a transaction (known as Alice contract transaction) which sends the coins back to Alice after a timeout. Even though Alice's coins would be in a 2-of-2 multisig not controlled by her, she knows that if she broadcasts her contract transaction she will be able to get her coins back even if Bob disappears.

Soon after all this has happened, Bob will do a similar thing but mirrored. Bob will obtain one of Alice's public keys and from it Bob's coinswap address. Bob creates a funding transaction paying to it the same coinswap amount, but before he broadcasts it he gets Alice to sign a contract transaction which sends Bob's coins back to him after a timeout.

At this point both Alice and Bob are able to broadcast their funding transactions paying coins into multisig addresses, and if they want they can get those coins back by broadcasting their contract transactions and waiting for the timeout. The trick with coinswap is that the contract transaction script contains a second clause: it is also possible for the other party to get the coins by providing a hash preimage (e.g. HX = sha256(X)) without waiting for a timeout. The effect of this is that if the hash preimage is revealed to both parties then the coins in the multisig addresses have transferred possession off-chain to the other party who originally didn't own those coins.

When the preimage is not known, Alice can use her contract transaction to get coins from Alice's multisig address after a timeout, and Bob can use his contract transaction to get coins from the Bob multisig address after a timeout. After the preimage is known, Alice can use Bob's contract transaction and the preimage to get coins from Bob's multisig address, and also Bob can use Alice's contract transaction and the preimage to get the coins from Alice's multisig address.

Here is a diagram of Alice and Bob's coins and how they swap possession after a coinswap:

                                              Alice after a timeout
                                             /
                                            /
Alice's coins ------> Alice coinswap address
                                            \
                                             \
                                              Bob with knowledge of the hash preimage


                                          Bob after a timeout
                                         /
                                        /
Bob's coins ------> Bob coinswap address
                                        \
                                         \
                                          Alice with knowledge of the hash preimage

If Alice attempts to take the coins from Bob's coinswap address using her knowledge of the hash preimage and Bob's contract transaction, then Bob will be able to read the value of the hash preimage from the blockchain, and use it to take the coins from Alice's coinswap address. This happens in the worst case, but in virtually all real-life situations it will never get to that point. The contracts usually always stay unbroadcasted.

So at this point we've reached a situation where if Alice gets paid then Bob cannot fail to get paid, and vice versa. Now to save time and miner fees, the party which started with knowledge of the hash preimage will reveal it, and both parties will send each other their private keys corresponding to their public keys in the 2-of-2 multisigs. After this private key handover Alice will know both private keys in the relevant multisig address, and so those coins are in her sole possession. The same is true for Bob.

Alice's coins ----> Bob's address

Bob's coins ----> Alice's address

In a successful coinswap, Alice's and Bob's coinswap addresses transform off-chain to be possessed by the other party

Bitcoin's script is used to code these timelock and hashlock conditions. Diagrams of the transactions:

= Alice's funding transaction =
Alice's inputs -----> multisig (Alice pubkey + Bob pubkey)

= Bob's funding transaction =
Bob's inputs -----> multisig (Bob pubkey + Alice pubkey)

= Alice's contract transaction=
multisig (Alice pubkey + Bob pubkey) -----> contract script (Alice pubkey + timelock OR Bob pubkey + hashlock)

= Bob's contract transaction=
multisig (Bob pubkey + Alice pubkey) -----> contract script (Bob pubkey + timelock OR Alice pubkey + hashlock)

The contract transactions are only ever used if a dispute occurs. If all goes well the contract transactions never hit the blockchain and so the hashlock is never revealed, and therefore the coinswap improves privacy by delinking the transaction graph.

The party which starts with knowledge of the hash preimage must have a longer timeout, this means there is always enough time for the party without knowledge of the preimage to read the preimage from the blockchain and get their own transaction confirmed.

This explanation describes the simplest form of coinswap. On its own it isn't enough to build a really great private system. For more building blocks read the design document of this project.

Notes on architecture

Makers are servers which run Tor hidden services (or possibly other hosting solutions in case Tor ever stops working). Takers connect to them. Makers never connect to each other.

Diagram of connections for a 4-hop coinswap:

        ---- Bob
       /
      /
Alice ------ Charlie
      \
       \
        ---- Dennis

The coinswap itself is multi-hop:

Alice ===> Bob ===> Charlie ===> Dennis ===> Alice

Makers are not even meant to know how many other makers there are in the route. They just offer their services, offer their fees, protect themselves from DOS, complete the coinswaps and make sure they get paid those fees. We aim to have makers have as little state as possible, which should help with DOS-resistance.

All the big decisions are made by takers (which makes sense because takers are paying, and the customer is always right.) Decisions like:

  • How many makers in the route
  • How many transactions in the multi-transaction coinswap
  • How long to wait between funding txes
  • The bitcoin amount in the coinswap

In this protocol it's always important to as much as possible avoid DOS attack opportunities, especially against makers.

Protocol between takers and makers

Alice is the taker, Bob, Charlie and Dennis are makers. For a detailed explanation including definitions see the mailing list email here. That email should be read first and then you can jump back to the diagram below when needed while reading the code.

Protocol messages are defined by the structs found in src/messages.rs and serialized into json with rust's serde crate.

 | Alice           | Bob             | Charlie         |  Dennis         | message, or (step) if repeat
 |=================|=================|=================|=================|
0. AB/A htlc     ---->               |                 |                 | sign senders contract
1.               <---- AB/A htlc B/2 |                 |                 | senders contract sig
2.    ************** BROADCAST AND MINE ALICE FUNDING TX *************** |
3.    A fund     ---->               |                 |                 | proof of funding
4.               <----AB/B+BC/B htlc |                 |                 | sign senders and receivers contract
5. BC/B htlc     ---------------------->               |                 | (0)
6.               <---------------------- BC/B htlc C/2 |                 | (1)
7. AB/B+BC/B A+C/2--->               |                 |                 | senders and receivers contract sig
8.    ************** BROADCAST AND MINE BOB FUNDING TX ***************   |
A.    B fund     ---------------------->               |                 | (3)
B.               <----------------------BC/C+CD/C htlc |                 | (4)
C. CD/C htcl     ---------------------------------------->               | (0)
D.               <---------------------------------------- CD/C htlc D/2 | (1)
E. BC/C htlc     ---->               |                 |                 | sign receiver contract
F.               <---- BC/C htlc B/2 |                 |                 | receiver contract sig
G.BC/C+CD/C B+D/2----------------------->              |                 | (7)
H.   ************** BROADCAST AND MINE CHARLIE FUNDING TX ************** |
I.   C fund      ---------------------------------------->               | (3)
J.               <----------------------------------------CD/D+DA/D htlc | (4)
K. CD/D htlc     ---------------------->               |                 | (E)
L.               <---------------------- CD/D htlc C/2 |                 | (F)
M.CD/D+DA/D C+D/2---------------------------------------->               | (7)
N.   ************** BROADCAST AND MINE DENNIS FUNDING TX *************** |
O. DA/A htlc     ---------------------------------------->               | (E)
P.               <---------------------------------------- DA/A htlc D/2 | (F)
Q. hash preimage ---->               |                 |                 | hash preimage
R.               <---- privB(B+C)    |                 |                 | privkey handover
S.    privA(A+B) ---->               |                 |                 | (R)
T. hash preimage ---------------------->               |                 | (Q)
U.               <---------------------- privC(C+D)    |                 | (R)
V.    privB(B+C) ---------------------->               |                 | (R)
W. hash preimage ---------------------------------------->               | (Q)
X                <---------------------------------------- privD(D+A)    | (R)
Y.    privC(C+D) ---------------------------------------->               | (R)

Note on terminology: Sender and Receiver

In the codebase and protocol documentation the words "Sender" and "Receiver" are used. These refer to either side of a coinswap address. The entity which created a transaction paying into a coinswap address is called the sender, because they sent the coins into the coinswap address. The other entity is called the receiver, because they will receive the coins after the coinswap is complete.

Further reading

Chris Belcher's personal roadmap for the project

  • ☑ learn rust
  • ☑ learn rust-bitcoin
  • ☑ design a protocol where all the features (vanilla coinswap, multi-tx coinswap, routed coinswap, branching routed coinswap, privkey handover) can be done, and publish to mailing list
  • ☑ code the simplest possible wallet, seed phrases "generate" and "recover", no fidelity bonds, everything is sybil attackable or DOS attackable for now, no RBF
  • ☑ implement creation and signing of traditional multisig
  • ☑ code makers and takers to support simple coinswap
  • ☑ code makers and takers to support multi-transaction coinswaps without any security (e.g. no broadcasting of contract transactions)
  • ☑ code makers and takers to support multi-hop coinswaps without security
  • ☑ write more developer documentation
  • ☐ set up a solution to mirror this repository somewhere else in case github rm's it like they did youtube-dl
  • ☑ implement and deploy fidelity bonds in joinmarket, to experiment and gain experience with the concept
  • ☑ add proper error handling to this project, as right now most of the time it will exit on anything unexpected
  • ☑ code security, recover from aborts and deveations
  • ☑ implement coinswap fees and taker paying for miner fees
  • ☑ add support for connecting to makers that arent on localhost, and tor support
  • ☑ code federated message board seeder servers
  • ☑ ALPHA RELEASE FOR TESTNET, REGTEST, SIGNET AND MAINNET (FOR THE BRAVE ONES)
  • ☑ have watchtower store data in a file, not in RAM
  • ☐ study ecdsa-2p and implement ecdsa-2p multisig so the coinswaps can look identical to regular txes
  • ☐ have taker store the progress of a coinswap to file, so that the whole process can be easily paused and started
  • ☐ add automated incremental backups for wallet files, because seed phrases aren't enough to back up these wallets
  • ☐ code fidelity bonds
  • ☐ add support precomputed RBF fee-bumps, so that txes can always be confirmed regardless of the block space market
  • ☐ automated tests (might be earlier in case its useful in test driven development)
  • ☐ move wallet files and config to its own data directory ~/.teleport/
  • ☐ add collateral inputs to receiver contract txes
  • ☐ implement encrypted contract txes for watchtowers, so that watchtowers can do their job without needing to know the addresses involved
  • ☐ implement branching and merging coinswaps for takers, so that they can create coinswaps even if they just have one UTXO
  • ☐ add encrypted wallet files
  • ☐ reproducible builds + pin dependencies to a hash
  • ☐ break as many blockchain analysis heuristics as possible, e.g. change address detection
  • ☐ create a GUI for taker
  • ☐ find coins landing on already-used addresses and freeze them, to resist the forced address reuse attack
  • ☐ payjoin-with-coinswap with decoy UTXOs
  • ☐ convert contracts which currently use script to instead use adaptor signatures, aiming to not reveal contracts in the backout case
  • ☐ create a web API similar to the one in joinmarket
  • ☐ randomized locktimes, study with bayesian inference the best way to randomize them so that an individual maker learns as little information as possible from the locktime value
  • ☐ anti-DOS protocol additions for maker (not using json but some kind of binary format that is harder to DOS)
  • ☐ abstract away the Core RPC so that its functions can be done in another way, for example for the taker being supported as a plugin for electrum
  • ☐ make the project into a plugin which can be used by other wallets to do the taker role, try to implement it for electrum wallet

Community

teleport-transactions's People

Contributors

a455bcd9 avatar chris-belcher avatar eupn avatar geneferneau avatar maxhillebrand avatar mojox911 avatar pulpcattel avatar pwltr avatar riccardomasutti avatar thestack avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

teleport-transactions's Issues

Outputs to stdout gone when running maker

I just noticed now almost all the messages to stdout are missing when running the maker.

It seems the log::trace! is being made silent. Interestingly the taker messages are all outputted even though it also uses trace!

Presumably happened after #22

Dependency duplication for `bitcoin*`

It seems there are some dependency duplication happening for bitcoin and bitcoin_hashes crate.

$ cargo build
   ...
   Compiling bitcoin_hashes v0.9.4
   Compiling bitcoin_hashes v0.7.6
   Compiling jsonrpc v0.11.0
   Compiling bitcoin v0.25.2
   Compiling bitcoin v0.21.0
   ...

Probably due to some upstream crates.

Creating an issue to register it.

Implement PTLC scripts

Point Time Locked Contracts (PTLC) scripts allow for swaps to look like normal transactions. Especially with Taproot, Schnorr signatures and tapscripts greatly increase the ability to blend into the crowd (enhancing user privacy). PTLCs can also be implemented with ECDSA signatures, though the setup and cryptography are more complex.

PTLCs, by using adaptor signatures, also remove the necessity of manually transferring a secret key (hash_preimage) between the maker and taker. This simplifies, and increases the security of the protocol.

Here is a basic, work-in-progress outline of how a PTLC protocol would work with coinswaps:

CoinSwap PTLC protocol

Add multiple debug message levels

Right now the project just uses println! when printing any kind of messages.

It would be good to have multiple message levels, other projects use ones like INFO, WARNING and DEBUG.

Ideally the logging mechanism would also save debug information to a file.

better test script

I noticed that your test script requires a running regtest node and a wallet:
https://github.com/bitcoin-teleport/teleport-transactions/blob/master/tests/init.sh
I'm writing a similar program for atomic swaps, and with my test script, no manual regtest and wallet creation is needed. A local data dir is created and used, and all RPC configuration parameters etc. are set in the script. Feel free to use the code to improve your test script, it is the same licence:
https://github.com/FrankBuss/pktbtcswap/blob/main/test.sh

teleport attempts to use jsonrpc 2.0 despite it not being supported by Core

After unsuccessful attempt to try this out I recorded the communication and it looks like jsonrpc 2.0 is the problem:

Recorded request from teleport:

POST /wallet/teleport HTTP/1.1
Host: localhost:18441
Content-Type: application/json
Authorization: Basic X19jb29raWVfXzowMzM4Nzc1MTMyOGVmOTJiNGEzOGIxNDg2MDY5NmNkNzg3YWQ2ZWNkNWNiYmE1NGFjOTI2YzM2YmQwMjYwNThm
Content-Length: 65

{"method":"getblockchaininfo","params":[],"id":1,"jsonrpc":"2.0"}

Request from bitcoin-cli:

POST / HTTP/1.1
Host: 127.0.0.1
Connection: close
Content-Type: application/json
Authorization: Basic X19jb29raWVfXzowMzM4Nzc1MTMyOGVmOTJiNGEzOGIxNDg2MDY5NmNkNzg3YWQ2ZWNkNWNiYmE1NGFjOTI2YzM2YmQwMjYwNThm
Content-Length: 50

{"method":"getblockchaininfo","params":[],"id":1}

(don't worry about the "leak", it's a disposable VM :))

  • Commit: edbc4b7
  • Using cookie authentication (with patched path)
  • Command used to record the request: socat TCP-LISTEN:18441,fork,reuseaddr SYSTEM:'tee /proc/self/fd/2 | nc 127.0.0.1 18444 | tee /proc/self/fd/2' (yes, my ports are correct)
  • Attempted teleport command: sudo -u bitcoin-regtest ./target/debug/teleport --wallet-file-name=maker1.teleport generate-wallet
  • Bitcoin Core version: 0.21.1
  • No relevant logs in bitcoind debug.log
  • Yes, the network was initialized by mining a bunch of blocks (101)

I'm still confused how come this wasn't discovered already...

P.S.: thanks a lot for working on this project!!!

Clippy Warnings

It seems clippy is complaining at multiple places.

$ cargo clippy
    Checking teleport v0.1.0 (/home/mojox911/github-repo/teleport-transactions)
warning: this function has too many arguments (10/7)
   --> src/contracts.rs:188:1
    |
188 | / pub fn validate_and_sign_senders_contract_tx(
189 | |     multisig_key_nonce: &SecretKey,
190 | |     hashlock_key_nonce: &SecretKey,
191 | |     timelock_pubkey: &PublicKey,
...   |
198 | |     wallet: &mut Wallet,
199 | | ) -> Result<Signature, &'static str> {
    | |____________________________________^
    |
    = note: `#[warn(clippy::too_many_arguments)]` on by default
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_many_arguments

warning: question mark operator is useless here
   --> src/maker_protocol.rs:564:13
    |
564 | /             Ok(wallet_ref
565 | |                 .find_swapcoin_mut(&swapcoin_private_key.multisig_redeemscript)
566 | |                 .ok_or("multisig_redeemscript not found")?
567 | |                 .apply_privkey(swapcoin_private_key.key)?)
    | |__________________________________________________________^
    |
    = note: `#[warn(clippy::needless_question_mark)]` on by default
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_question_mark
help: try
    |
564 |             wallet_ref
565 |                 .find_swapcoin_mut(&swapcoin_private_key.multisig_redeemscript)
566 |                 .ok_or("multisig_redeemscript not found")?
567 |                 .apply_privkey(swapcoin_private_key.key)
    |

warning: this function has too many arguments (13/7)
   --> src/taker_protocol.rs:688:1
    |
688 | / async fn send_proof_of_funding_and_get_contract_txes(
689 | |     socket_reader: &mut BufReader<ReadHalf<'_>>,
690 | |     socket_writer: &mut WriteHalf<'_>,
691 | |     funding_txes: &[Transaction],
...   |
701 | |     hashvalue: [u8; 20],
702 | | ) -> Result<(SignSendersAndReceiversContractTxes, Vec<Script>), Box<dyn Error>> {
    | |_______________________________________________________________________________^
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_many_arguments

warning: writing `&PathBuf` instead of `&Path` involves a new object where a slice will do
  --> src/main.rs:22:38
   |
22 | fn generate_wallet(wallet_file_name: &PathBuf) -> std::io::Result<()> {
   |                                      ^^^^^^^^ help: change this to: `&Path`
   |
   = note: `#[warn(clippy::ptr_arg)]` on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg

warning: writing `&PathBuf` instead of `&Path` involves a new object where a slice will do
  --> src/main.rs:68:37
   |
68 | fn recover_wallet(wallet_file_name: &PathBuf) -> std::io::Result<()> {
   |                                     ^^^^^^^^ help: change this to: `&Path`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg

warning: writing `&PathBuf` instead of `&Path` involves a new object where a slice will do
   --> src/main.rs:113:45
    |
113 | fn display_wallet_balance(wallet_file_name: &PathBuf, long_form: Option<bool>) {
    |                                             ^^^^^^^^ help: change this to: `&Path`
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg

warning: writing `&PathBuf` instead of `&Path` involves a new object where a slice will do
   --> src/main.rs:162:42
    |
162 | fn display_wallet_keys(wallet_file_name: &PathBuf) {
    |                                          ^^^^^^^^ help: change this to: `&Path`
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg

warning: writing `&PathBuf` instead of `&Path` involves a new object where a slice will do
   --> src/main.rs:173:44
    |
173 | fn print_receive_invoice(wallet_file_name: &PathBuf) {
    |                                            ^^^^^^^^ help: change this to: `&Path`
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg

warning: writing `&PathBuf` instead of `&Path` involves a new object where a slice will do
   --> src/main.rs:194:32
    |
194 | fn run_maker(wallet_file_name: &PathBuf, port: u16) {
    |                                ^^^^^^^^ help: change this to: `&Path`
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg

warning: writing `&PathBuf` instead of `&Path` involves a new object where a slice will do
   --> src/main.rs:216:32
    |
216 | fn run_taker(wallet_file_name: &PathBuf) {
    |                                ^^^^^^^^ help: change this to: `&Path`
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg

warning: 10 warnings emitted

    Finished dev [unoptimized + debuginfo] target(s) in 1.05s

I guess we can ignore them for now. But maybe something to tidy up later.

No download-offers subroutine

In README.md it says to use the download-offers subcommand to see offers, after executing cargo run -- download-offers:

error: Found argument 'download-offers' which wasn't expected, or isn't valid in this context

USAGE:
    teleport.exe [FLAGS] [OPTIONS] <SUBCOMMAND>

For more information try --help
error: process didn't exit successfully: `target\debug\teleport.exe download-offers` (exit code: 1)

Dedicated Maker Taker structure

Currently all the maker and taker functionalities are done via open function calls.
Which works ok, when running demons, but we might wanna eventually have dedicated structure
for both maker and taker.

This will allow us to get some compile time checking and also have the code organized more structurally.

Opening this issue to open discussion regarding this.

[QnA] How about RON for Wallet data encoding?

Digging into serde made me realize we can use lots of its flexibility.

One such will be, having a new kinda of data encoding with more semantic information than json.
Ex: https://github.com/ron-rs/ron [Rusty Object Notation]

I personally have preference towards "rust" way of doing stuffs, and it seems like most other rusty things, RON is quite there for encoding human readable data.

Later on we can have our config files written in RON too.

Opened this for discussion on it.

Non-hardcoded configuration - use `configure_me`?

Hardcoding configuration makes it annoying to debug things. I suggest to use my crate configure_me to do that and offer making a full PR as well as adding required features (subcommand support) to the library. The primary advantage of configure_me is support of config files and dirs out of the box. configure_me is used in electrs among other projects.

structopt vs configure_me

Common properties

  • Declarative syntax
  • Parse and validate Rust types - no manual conversion
  • Correct support of non-uf8 paths (Path{Buf}, OsStr{ing}); I think structopt requires enabling this explicitly?
  • Generate help page
  • Environment variable support

Advantages of configure_me

  • Support of config files and dirs with ability to override things and include files from arguments
  • Generate man pages
  • Explicitly correct GNU-style params/switches (--key val, --key=val, -xyzkval...; maybe structopt is still good enough?)
  • Toml file enables processing by external tools
  • MSRV will always support the Rust version available in Debian stable

Advantages of structopt

  • Not using Toml makes it work with IDEs and the struct is more obvious
  • Generate shell completions
  • Mature and popular
  • Native subcommand support (this should be irrelevant here since I'm willing to add support)

Disclaimer: I may be missing some things, feel free to point out/ask.

Creating a secp256k1 context singleton

Right now the project creates a new secp256k1 context a lot.

This is kind of slow. Though speed isn't a huge priority for this project since everything is slowed down by the requirement to wait for blocks.

However I really noticed a slowdown when coding fidelity bonds, which creates about 980 addresses on startup, so I made a single context and passed it as an argument:

let secp = Secp256k1::new();

I was thinking about good ways to have a secp256k1 context singleton. I gave up fairly quickly because as I said speed isn't a huge priority, but it would be a nice-to-have. So if someone else wants something to do and feels like playing around with rust, try this issue.

One way I considered was to add the context to the Wallet struct, but some functions don't have access to it, such as the Swapcoins structs (and they have to serialized to file too, the secp256k1 context isnt serializable).

Another way I tried was the lazy_static crate but I couldn't get it to work because of some rust syntax issues with the generic arguments to Secp256k1.

Another way I considered was adding the context as an argument to every single function, but that's a bit rubbish.

Implement normal spend from wallet

We need a new main method which sends bitcoins out from the wallet. It would take a destination address and amount as input, and create a regular transaction just like any other bitcoin wallet does.

Because of the way coinswap works with the multisig and private key handover, it's not possible to send a coinswap directly to any address like you can with coinjoin/joinmarket. You first need to do a coinswap and then spend those coins (when coinswap is used by regular users these two functions can be combined into one button so that the user doesn't have to think).

Now is the right time to implement this is because we can use the same function to test how watchtowers respond to a coinswap peer deviating from the protocol. We could use this method to simulate a malicious taker who broadcasts a contract transaction instead of continuing the protocol. And then they could spend it with the timelock or hashlock branch, or some other way, and we could test what the watchtower does in response.

The new main method should allow coin control by optionally accepting a list of outpoints in our wallet to spend. That's part of the reason why I made the 568a4e..83a2e8:0 shortened format for easier copypasting.

If not using coin control, you can have Bitcoin Core select coins to spend in the same way that the teleport wallet already does:

let psbt_result = rpc.wallet_create_funded_psbt(

Probably the best way to implement this in code is to generalize the code in the create_spending_txes function and reuse that code for this new method.

The new main method should allow choosing the amount to spend, but also allow a sweep spend where the entire list of UTXO are sent without creating a change address. Electrum uses the "!" character on the command line to mean sweep, so maybe the command line option can be either a number of satoshis or a "!" character.

Remember that right now in the code there's three kinds of UTXOs we are able to spend 1) single-sig UTXO from the HD wallet 2) 2of2 multisig UTXO from a successful coinswap and 3) UTXO protected by a timelock from an aborted coinswap following the timeout branch.

So for example these are command lines which spend:

cargo run -- direct-send 1000000 bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq (sending a million satoshi to the given address)

cargo run -- direct-send ! bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq (sending all the money in the wallet to the given address)

cargo run -- direct-send 1000000 bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq 568a4e..83a2e8:0 (sending a million satoshi to the given address by only spending the given outpoint, sending the rest to a change address)

cargo run -- direct-send 1000000 bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq 568a4e..83a2e8:0 4ef47f..c8744c:1 (sending a million satoshi to the given address by only spending the two given outpoints, sending the rest to a change address)

cargo run -- direct-send ! bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq 568a4e..83a2e8:0 4ef47f..c8744c:1 (sending all the money in those two given outpoints to the given address)

(I don't know if direct-send is the best name for this method, it's just something I made up now, maybe send or normal-send is better, but it doesn't really matter)

ECDSA-2P resources

Here are some resources I've managed to collect so far.

I'm not working on ECDSA-2P yet, but sharing this in case other people want to spend time on it.

2018 scaling bitcoin
a talk by lightning labs iirc
http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/scriptless-ecdsa/
https://github.com/cfromknecht/tpec

2019 scaling bitcoin
threshold scriptless scripts
has a list of all threshold ecdsa papers from 2017 until today

lindell's paper is the starting point for most
presented at the conference crypto 2017 apparently
one protocol uses pallier
another protocol uses which works better with EC

big list of resources
https://github.com/rdragos/awesome-mpc

theres an iphone wallet called zengo which apparently uses ecdsa-2p
mentioned here https://stephanlivera.com/episode/119/

https://twitter.com/NicolasDorier/status/1307333060996689925

14/10/2020
https://github.com/ZenGo-X/multi-party-ecdsa
is this one of the rust libs you mentioned? https://github.com/ZenGo-X/multi-party-ecdsa the examples there are pretty cool

Fixing overly verbose de/serialization on wire protocol

Currently the project uses rust's serde to handle protocol messages. This is nice but sometimes creates larger-than-necessary messages. We should try to reduce the size of these messages as much as possible. Smaller messages really help with censorship-resistance, decentralization and privacy. The smaller messages can be harder to detect and cost less especially in perhaps third world countries or burner SIM cards where internet bandwidth is more limited.

The messages are defined in the file src/messages.rs

For example see this serialization of ProofOfFunding, which has a huge amount of wasted space. The funding transactions have witnesses which are serialized as lists of comma-separated numbers, which is pretty wasteful. A better way might be to somehow serialize those transactions in network format (i.e. as a big hex string)

{"method":"proofoffunding","confirmed_funding_txes":[{"funding_tx":{"version":2,"lock_time":0,"input":[{"previous_output":"808cba6ad9ca4339cf6b7a1ce0dfc2419f6b71506b6c6e40f15c47dfcb4b4b00:1","script_sig":"","sequence":0,"witness":[[48,69,2,33,0,172,242,95,170,93,8,11,86,213,158,3,244,62,84,37,62,99,170,14,91,230,139,26,84,181,221,11,234,22,11,244,252,2,32,1,107,114,138,182,116,77,184,124,209,4,91,74,83,45,105,213,188,88,113,239,176,42,243,254,198,187,158,83,174,154,235,1],[3,144,16,150,236,5,184,239,225,112,70,71,85,136,90,215,212,140,54,95,173,116,37,81,95,93,220,173,92,10,124,26,36]]},{"previous_output":"7a7e61fdf221761d74bbb222b5e102a45e63e9bbd90dee0184547f6b738dd0a3:1","script_sig":"","sequence":0,"witness":[[],[48,69,2,33,0,156,21,218,170,167,68,188,186,74,137,111,212,60,47,129,45,48,237,20,216,23,109,135,75,57,33,210,209,31,71,14,153,2,32,104,200,75,77,227,75,108,139,42,233,21,185,203,123,58,164,230,29,75,187,166,240,95,155,109,35,108,213,61,245,186,207,1],[48,69,2,33,0,146,159,250,174,125,183,73,233,155,247,57,90,35,177,4,77,195,176,85,148,100,130,212,51,29,231,190,179,212,123,103,48,2,32,96,124,88,78,233,42,230,194,153,39,13,17,37,9,231,24,246,95,20,221,129,230,240,13,20,183,3,43,105,65,162,41,1],[82,33,2,88,167,91,153,45,237,19,0,19,207,44,105,7,41,12,144,244,199,43,224,163,22,253,229,48,87,200,57,189,142,13,76,33,3,218,156,42,131,43,176,85,199,3,144,246,93,71,253,125,108,8,15,149,119,112,82,219,205,107,9,169,161,200,2,116,79,82,174]]},{"previous_output":"bc078620097c4c037dbf7547ebd560d660d3c18352b81428c34120f98b3a1ab0:0","script_sig":"","sequence":0,"witness":[[],[48,68,2,32,20,231,123,87,145,9,205,101,118,63,240,2,87,184,201,245,151,29,92,145,55,246,88,105,18,244,16,8,104,44,50,54,2,32,84,32,171,21,64,133,10,189,74,60,214,134,49,17,136,31,62,26,176,113,2,119,168,4,158,100,45,89,214,238,65,130,1],[48,69,2,33,0,204,177,223,112,5,73,3,182,0,195,35,169,194,141,236,57,230,123,34,106,197,194,185,9,10,149,29,123,174,233,159,140,2,32,120,44,110,27,168,17,81,68,225,163,12,141,163,176,42,184,112,223,87,223,62,5,121,248,14,157,112,45,5,81,174,166,1],[82,33,3,195,10,155,69,54,207,10,76,207,35,20,76,78,199,140,221,12,219,229,163,40,217,69,92,151,11,181,75,46,228,139,109,33,3,239,193,123,235,77,216,86,221,165,234,216,52,121,122,249,251,247,222,197,95,202,118,209,161,7,77,215,37,50,78,58,41,82,174]]}],"output":[{"value":190015,"script_pubkey":"00203b181aaddd59457e45a336893e727d120d320ff1eb94260312c5039885e704e6"},{"value":1014560,"script_pubkey":"0014eefbe91835f348e5b14cc5ac36d37437678e15ab"}]},"funding_tx_merkleproof":"00000020268af582b0bb4bdb9b7515232649fab5023c4ae8723e4c2afbcd0bfedbe46346f5611e0ad84014830fc2009965988ba9ca7038237b4c1da454b919bad3c3db831187bb60ffff7f20030000000400000003a417b469a0e5df8478de553ae6228dbeaf96d33103885663875768c0b18bd851f99e42f5b87dc1c1e66ac6424ecec46a56e628c877569a6ba53e78e4cb0bba665c74288f9a9e3dac010745cc720a6d45a292db93ca7014067bec93d76716b628010b","multisig_redeemscript":"522102fe8ecc46c0d8bec30030670b6b021114fc0e843cc61622b8a3e7469934b3bb4221035cca74550e338599db8c5a5fa57b9cba0ae2301ffeeca79c21313b8d20b4fd0d52ae","multisig_key_nonce":"1caa072ecb693512de17731ea0f2c8b25e8902003b32915d2d7907d04aef9965","contract_redeemscript":"827ca9146ad908ce5acc2e74995d1894813b6a611b91a7a3876321033aa9f24c4984847649fecfd72dd28ce78b5a5019e14bd9653a5660c2857d75c9012051672103f0ca6f6e2a15f04a93521915144904a3977db9447c36b06deaec973c39dbec0100012868b2757b88ac","hashlock_key_nonce":"d9408d8d0a94f232436b9fb8ed8031d009be7517c16d6d4d8fc5a1471bf1a540"},{"funding_tx":{"version":2,"lock_time":0,"input":[{"previous_output":"57f5d32ee574d98f28f66664224d2dbf74aa90e4471b351a46d8fdb9049bf142:1","script_sig":"","sequence":0,"witness":[[48,69,2,33,0,191,66,131,130,205,45,119,77,118,218,167,104,42,135,212,36,115,214,150,24,208,66,207,91,35,33,153,124,216,190,183,225,2,32,38,146,235,192,249,206,197,16,8,150,200,127,24,1,6,128,32,186,163,148,239,80,126,165,83,111,253,118,212,16,207,210,1],[3,87,136,122,207,251,59,161,89,254,157,20,132,220,248,42,63,179,92,229,209,119,114,139,208,20,253,87,250,151,77,171,19]]},{"previous_output":"dfa9293d4acddbaf2453d7edc134267ae8dc9ff6c771bff42553c2fff25d8b79:0","script_sig":"","sequence":0,"witness":[[],[48,69,2,33,0,163,16,136,197,229,117,105,117,75,94,38,226,206,63,71,181,212,183,81,149,27,210,128,2,210,134,246,110,177,149,179,54,2,32,87,126,236,101,27,32,208,229,74,48,212,208,51,161,241,248,31,51,169,72,119,158,163,232,98,176,180,119,156,104,141,47,1],[48,68,2,32,41,184,77,55,243,4,131,18,209,33,31,101,42,123,185,239,252,68,61,226,2,182,176,212,18,134,120,13,131,64,147,26,2,32,52,253,82,160,172,136,200,175,43,45,191,29,254,186,22,224,171,207,22,214,232,107,204,17,227,66,91,3,141,146,98,40,1],[82,33,2,221,3,13,249,198,138,98,24,226,152,104,211,143,92,127,90,120,160,8,244,139,95,89,163,33,143,28,72,43,199,125,42,33,2,239,216,184,91,173,92,64,172,255,8,201,82,253,250,234,189,144,146,44,77,214,95,40,81,238,150,39,42,127,205,208,79,82,174]]}],"output":[{"value":56031,"script_pubkey":"0020202d7a02d9e73e44b6a7bd1181a4e4af1f9ba8c47b52c13bfc1c1551f6aae5b4"},{"value":1124499,"script_pubkey":"00142badebf2a107c2dc3790a1d8b4891a6456796f73"}]},"funding_tx_merkleproof":"00000020268af582b0bb4bdb9b7515232649fab5023c4ae8723e4c2afbcd0bfedbe46346f5611e0ad84014830fc2009965988ba9ca7038237b4c1da454b919bad3c3db831187bb60ffff7f2003000000040000000395874728ea7dae24527f7c751f6e0572b33c052d753c6fed1024fa47dbdefa1f391278807864fb2249b468332b0c27f7def0f7eae1f2a84c17a9881c7c0e52df7c30bf78315a90d5190c32d34a551d1b78cedc75c3d741e621248b4bc2db4f01010d","multisig_redeemscript":"522102df73a047903f2ab0f018c6124fac49f46c1d8715f9831ffc6825253924ca29e121038c6007545a0961ba8e585e39e56c23dcaf8500a596a99912992f87431438b6c752ae","multisig_key_nonce":"e7a7277920661d81d735f17a39a72369c375fc76ca221013fa5e2a7eb962e107","contract_redeemscript":"827ca9146ad908ce5acc2e74995d1894813b6a611b91a7a38763210275936721be65b5704c6438a32cc29dfd67a5868db676e06d4ecc86b617eb0db0012051672103cb49c11f978d22154c1892d4d96448c13dc412efdcf494ea5c6066782130f48400012868b2757b88ac","hashlock_key_nonce":"460a50d9a721f9ffd5b37649a59e3208e31b4dc30ffb351024cc4f807f166ef6"},{"funding_tx":{"version":2,"lock_time":0,"input":[{"previous_output":"aebd85476582ae34e74962f997ba62000eb9216d69ebf5c7fbf31316cb09225d:1","script_sig":"","sequence":0,"witness":[[],[48,69,2,33,0,173,5,212,154,49,31,137,190,92,69,29,6,251,252,129,248,244,29,33,69,196,198,87,49,236,151,189,31,195,84,30,21,2,32,111,188,195,214,128,11,163,10,199,151,94,43,129,222,93,195,117,87,22,211,59,134,203,248,121,190,105,80,215,131,64,151,1],[48,68,2,32,4,225,38,188,168,247,155,211,7,79,30,185,59,184,146,126,150,210,110,117,138,221,151,186,60,198,1,5,136,14,185,209,2,32,19,83,115,219,102,143,215,227,65,138,147,116,57,69,84,33,74,69,92,97,71,160,41,208,124,95,65,18,4,137,207,152,1],[82,33,2,223,133,159,135,251,230,7,93,219,208,58,170,0,209,28,64,106,145,199,148,161,122,220,215,201,134,140,150,231,232,186,80,33,3,94,67,74,57,209,194,13,111,19,118,169,244,210,78,239,70,249,230,68,140,176,143,230,249,89,1,157,239,86,186,128,220,82,174]]},{"previous_output":"95a2d692e3be31087f37fbea99dd1f85c578752eca4175fe68e16c6ff8e961c0:1","script_sig":"","sequence":0,"witness":[[48,69,2,33,0,131,230,212,181,135,248,216,238,158,180,50,127,163,198,118,84,109,129,204,225,47,52,135,239,123,163,79,24,79,195,197,45,2,32,119,10,11,109,220,104,181,239,81,60,39,214,193,16,101,198,202,191,235,134,137,199,18,132,252,210,244,114,15,188,81,64,1],[3,204,151,21,0,49,78,90,230,18,96,123,189,182,110,93,53,47,164,215,212,51,231,49,188,66,41,187,15,94,244,80,58]]}],"output":[{"value":253954,"script_pubkey":"002003124fabf5648b3d783f99c59ce34d460a9578dba1d45f404b7233d10c4d11a0"},{"value":1062426,"script_pubkey":"0014102a8b15b6ed6552c27fea7a7b4de8eb584ebfb7"}]},"funding_tx_merkleproof":"00000020268af582b0bb4bdb9b7515232649fab5023c4ae8723e4c2afbcd0bfedbe46346f5611e0ad84014830fc2009965988ba9ca7038237b4c1da454b919bad3c3db831187bb60ffff7f2003000000040000000395874728ea7dae24527f7c751f6e0572b33c052d753c6fed1024fa47dbdefa1f391278807864fb2249b468332b0c27f7def0f7eae1f2a84c17a9881c7c0e52df7c30bf78315a90d5190c32d34a551d1b78cedc75c3d741e621248b4bc2db4f010115","multisig_redeemscript":"522102bcaf6932f690616537e5283f27940d2c4dfa7e754e966b7c4b9f1fc7fb2cb16b2103e586e27b36f48b0885994ea14528b0c42a1dc2b181e92b154883e4d6c8359c4652ae","multisig_key_nonce":"ea3b2a108e05610ba5ccca2a544b62a8a40edb0184c968211ae433f43110e36c","contract_redeemscript":"827ca9146ad908ce5acc2e74995d1894813b6a611b91a7a3876321023afa07b7029313d32cd928fd3aedd6477681d582009548190cae947936991ad90120516721024bc3f49155c489ede98896c189abe2237eabe5525687215083b46b12225684a100012868b2757b88ac","hashlock_key_nonce":"57509a3ce6e183a7da6204483f118c3b2d9680e3528a7b9ee6205e4405d1494c"}],"next_coinswap_info":[{"next_coinswap_multisig_pubkey":"0336b46ed75c1c4e5a68e5f137ac48dfae12ccaf87d14ee2dfab19de8fd1e0f49a","next_hashlock_pubkey":"0367531813abe902473bda22c4318443607217d33e23b09c4a4df021a58ca14f5a"},{"next_coinswap_multisig_pubkey":"03d9e3192493f8c173b734dcc2c7c31ef5dfb50c0eb42c9074cda0a3e2ca8bb44f","next_hashlock_pubkey":"0360dc9b76a301e192098768a5d799004cc71b96c9d3dfddc5030ead117e9ba275"},{"next_coinswap_multisig_pubkey":"030cbcc691edbb1febd4a8e7640bd7d7b9ca0e6f32407f0170e1e5d233b4691702","next_hashlock_pubkey":"02931899d36052273a92488d9ea0f8dce889a807eb525404645105e359b8c968c1"}],"next_locktime":35}

Another instance of waste is using hex strings, and to me it seems base64 or base84 would be better for size. For example these two messages:

{"method":"receiverscontractsig","sigs":["304402203bfae22451977e8abd36c2f626ff3412dde1d4bd30b3e4a16388eb1b3cc2029802202ed10c1f8be11c9db4bb390360bc8ad7a260bab9907db35aa0ffd41e26c5012a","304402206099943ee887eec2fe8e6b872ee1eb1e8704b5d81b68ebfcced82822c265dbdc02201299b67ceb79cd17b86fd278ac1b1b6306fbd004b002bce9eddc0a3ac7e75bc7","3044022010f4abcdc7c462cca2093da1746039c266d450f90794b8d5d8ad15debf2b414102200ff9b31b4890a3e15082dfc5333eff20642c8a9db01594947c3b3b9ca200a81e"]}

{"method":"privatekeyhandover","swapcoin_private_keys":[{"multisig_redeemscript":"522102957cf49797b648f2de8d6393a728e93505b7e8b360191326fb21312a86e648cd210336b46ed75c1c4e5a68e5f137ac48dfae12ccaf87d14ee2dfab19de8fd1e0f49a52ae","key":"16184d12d87c88a84721bc2da80844d048d8157a2f20b953aec23a984b426345"},{"multisig_redeemscript":"522102155d2677b34a07dcb57b7deee6bd06ce3786dbca1b0d56e1f4b2d4f0e8ba714f2103d9e3192493f8c173b734dcc2c7c31ef5dfb50c0eb42c9074cda0a3e2ca8bb44f52ae","key":"8c31af1f1f47e32b870f1b354b6359e990acadec01e010df78443aa0bf36c04f"},{"multisig_redeemscript":"522102130819e8ef82c2dac6f104a87c561a7ed32537cbd2635219bb3aaebfaaeb9b9f21030cbcc691edbb1febd4a8e7640bd7d7b9ca0e6f32407f0170e1e5d233b469170252ae","key":"f5f1644ba11ebde84aed198c7447a244cd662f4dbf0def68a2afb529233d23b1"}]}

Another example is here, which also has "hash value" serialized as another comma-separated list of numbers.

{"method":"signsenderscontracttx","txes_info":[{"multisig_key_nonce":"1caa072ecb693512de17731ea0f2c8b25e8902003b32915d2d7907d04aef9965","hashlock_key_nonce":"d9408d8d0a94f232436b9fb8ed8031d009be7517c16d6d4d8fc5a1471bf1a540","timelock_pubkey":"03f0ca6f6e2a15f04a93521915144904a3977db9447c36b06deaec973c39dbec01","senders_contract_tx":{"version":2,"lock_time":0,"input":[{"previous_output":"66ba0bcbe4783ea56b9a5677c828e6566ac4ce4e42c66ae6c1c17db8f5429ef9:0","script_sig":"","sequence":0,"witness":[]}],"output":[{"value":189015,"script_pubkey":"00206cdf8789b8ba64eb3eeca5f34e3f14d45cca3cda9316097a6365beb1b701151f"}]},"multisig_redeemscript":"522102fe8ecc46c0d8bec30030670b6b021114fc0e843cc61622b8a3e7469934b3bb4221035cca74550e338599db8c5a5fa57b9cba0ae2301ffeeca79c21313b8d20b4fd0d52ae","funding_input_value":190015},{"multisig_key_nonce":"e7a7277920661d81d735f17a39a72369c375fc76ca221013fa5e2a7eb962e107","hashlock_key_nonce":"460a50d9a721f9ffd5b37649a59e3208e31b4dc30ffb351024cc4f807f166ef6","timelock_pubkey":"03cb49c11f978d22154c1892d4d96448c13dc412efdcf494ea5c6066782130f484","senders_contract_tx":{"version":2,"lock_time":0,"input":[{"previous_output":"df520e7c1c88a9174ca8f2e1eaf7f0def7270c2b3368b44922fb647880781239:0","script_sig":"","sequence":0,"witness":[]}],"output":[{"value":55031,"script_pubkey":"0020a0d54633f126fe99b6269fb28d4adcc0825199979dae75f625536db91d4725ce"}]},"multisig_redeemscript":"522102df73a047903f2ab0f018c6124fac49f46c1d8715f9831ffc6825253924ca29e121038c6007545a0961ba8e585e39e56c23dcaf8500a596a99912992f87431438b6c752ae","funding_input_value":56031},{"multisig_key_nonce":"ea3b2a108e05610ba5ccca2a544b62a8a40edb0184c968211ae433f43110e36c","hashlock_key_nonce":"57509a3ce6e183a7da6204483f118c3b2d9680e3528a7b9ee6205e4405d1494c","timelock_pubkey":"024bc3f49155c489ede98896c189abe2237eabe5525687215083b46b12225684a1","senders_contract_tx":{"version":2,"lock_time":0,"input":[{"previous_output":"014fdbc24b8b2421e641d7c375dcce781b1d554ad3320c19d5905a3178bf307c:0","script_sig":"","sequence":0,"witness":[]}],"output":[{"value":252954,"script_pubkey":"0020c1be327ce4a160f310ad59959a0131f1049faf17c830895548e239370a4b8fd1"}]},"multisig_redeemscript":"522102bcaf6932f690616537e5283f27940d2c4dfa7e754e966b7c4b9f1fc7fb2cb16b2103e586e27b36f48b0885994ea14528b0c42a1dc2b181e92b154883e4d6c8359c4652ae","funding_input_value":253954}],"hashvalue":[106,217,8,206,90,204,46,116,153,93,24,148,129,59,106,97,27,145,167,163],"locktime":40}

There is documentation here https://serde.rs/field-attrs.html which could be useful. The tag #[serde(with = "module")] is one possible method to change the serialization of the messages.

One thing we could consider is moving away from json serialization entirely and making everything be binary? Though theres downsides to that too.

On the other hand, this whole issue might be a case of premature optimization(?)

Incoming/Outgoing SwapCoins incorrectly use Hash256

Not a huge deal but I just noticed the IncomingSwapCoin and OutgoingSwapCoin types use the type Hash256 for the hash preimage, but that is conceptually wrong, because the preimage isn't a hashvalue.

pub hash_preimage: Option<Hash256>,

pub hash_preimage: Option<Hash256>,

Again I emphasize it's not a huge deal, just conceptually wrong. Maybe it could be replaced with a type Preimage which could be created if it doesnt already exist, or just revert back to [u8; 32].

Using BDK (Bitcoin Development Kit)

I studied this library (https://github.com/bitcoindevkit/bdk) to see if it could be useful to Teleport.

Right now Teleport uses rust-bitcoin, bitcoincore-rpc and Bitcoin Core's RPC for almost everything it does. Moving to BDK would be done by using it's Wallet struct. It could help in a few ways:

  • BDK supports RBF, that could be useful later then Teleport ends up supporting multiple pre-signed RBF transactions.
  • If we ever create a taker Teleport app then BDK's implementation of client side block filters would help for private wallet sync. On the other hand this still requires downloading many GB, so not really an option for a limited-data mobile wallet.
  • BDK supports miniscript. Right now teleport builds up scripts from rust-bitcoin's library see example. Miniscript might be a bit cleaner, also it might be useful if/when scriptless scripts get added to bitcoin if miniscript supports them in a cleaner way.
  • Using BDK's wallet struct would be a bit cleaner.

So a useful thing to do one day might be to have Teleport use BDK.

CI failure at grcov 0.8.3

grcov v0.8.3 has build failure and this is making our CI coverage reporting crash. Happened after latest 0.8.3 release.

$ cargo install grcov --force --version 0.8.3
    Updating crates.io index
  Installing grcov v0.8.3
error: failed to compile `grcov v0.8.3`, intermediate artifacts can be found at `/tmp/cargo-installBzAsmH`

Caused by:
  failed to select a version for the requirement `tera = "^1.14"`
  candidate versions found which didn't match: 1.12.1, 1.12.0, 1.11.0, ...
  location searched: crates.io index
  required by package `grcov v0.8.3`

Easy fix: pin it to 0.8.2.

Issue created for tracking purpose.

Payjoin - bip78 crate

I noticed there's payjoin task in README, I guess it's not a priority but you may want to know that I'm working on a bip78 crate which could be helpful. Will be happy to receive a feedback on it.

Feel free to close this to de-noise if you like.

Create better way of controlling acceptable protocol methods

Right now the maker server handles protocol messages by having a big match statement that handles each message:

let outgoing_message = match request {
TakerToMakerMessage::TakerHello(_message) => {
connection_state.allowed_method = None;
None
}
TakerToMakerMessage::GiveOffer(_message) => {
let max_size = wallet.read().unwrap().get_offer_maxsize(rpc)?;
let tweakable_point = wallet.read().unwrap().get_tweakable_keypair().1;
connection_state.allowed_method = Some("signsenderscontracttx");
Some(MakerToTakerMessage::Offer(Offer {
absolute_fee: 1000,
amount_relative_fee: 0.005,
max_size,
min_size: 10000,
tweakable_point,
}))
}
TakerToMakerMessage::SignSendersContractTx(message) => {
connection_state.allowed_method = Some("proofoffunding");
handle_sign_senders_contract_tx(wallet, message)?
}
TakerToMakerMessage::ProofOfFunding(proof) => {
connection_state.allowed_method = Some("sendersandreceiverscontractsigs");
handle_proof_of_funding(connection_state, rpc, wallet, &proof)?
}
TakerToMakerMessage::SendersAndReceiversContractSigs(message) => {
connection_state.allowed_method = Some("signreceiverscontracttx");
handle_senders_and_receivers_contract_sigs(connection_state, rpc, wallet, message)?
}
TakerToMakerMessage::SignReceiversContractTx(message) => {
connection_state.allowed_method = Some("hashpreimage");
handle_sign_receivers_contract_tx(wallet, message)?
}
TakerToMakerMessage::HashPreimage(message) => {
connection_state.allowed_method = Some("privatekeyhandover");
handle_hash_preimage(wallet, message)?
}
TakerToMakerMessage::PrivateKeyHandover(message) => {
handle_private_key_handover(wallet, message)?
}
};

However a taker can't validly send any message at any time, they have to follow a specific sequences of messages. So after the fact while coding I added code such as connection_state.allowed_method which checks that the protocol message is allowed e.g.

let request_json: Value = match serde_json::from_str(&line) {
Ok(r) => r,
Err(_e) => return Err(Error::Protocol("json parsing error")),
};
let method = match request_json["method"].as_str() {
Some(m) => m,
None => return Err(Error::Protocol("missing method")),
};
let is_method_allowed = match connection_state.allowed_method {
Some(allowed_method) => method == allowed_method,
None => NEWLY_CONNECTED_TAKER_ALLOWED_METHODS
.iter()
.any(|&r| r == method),
};
if !is_method_allowed {
return Err(Error::Protocol("unexpected method"));
}
and
//TODO
//this using of strings to indicate allowed methods doesnt fit aesthetically
//with the using of structs and serde as in messages.rs
//there is also no additional checking by the compiler
//ideally this array and the other strings in this file would instead be
//structs, however i havent had time to figure out if rust can do this
pub const NEWLY_CONNECTED_TAKER_ALLOWED_METHODS: [&str; 5] = [
"giveoffer",
"signsenderscontracttx",
"proofoffunding",
"signreceiverscontracttx",
"hashpreimage",
];

However this is based on string comparisons, and is very un-rust-like. There is no checking by the compiler. A typo or other error would have to be detected at runtime instead of compile-time. We should be able to do a lot better.

I originally thought there could be some kind of list of structs which could control which enum is allowed to be deserialized, but I think that cant be done in rust. I was reading again the rust book: https://doc.rust-lang.org/book/ch06-00-enums.html and I think the only way to deal with the message enums and structs is to use match and if let.

One possible way of recoding the maker to improve this situation is to remove the big match statement that handles each message, and have the maker server be a state machine. If the state is waiting for one specific protocol message (for example TakerHello, SendersAndReceiversContractSigs or PrivateKeyHandover) then the code can use if let to check that the protocol message really is that message, and if not then create an error. If the state of the server is waiting for multiple possible protocol messages (for example GiveOffer, ProofOfFunding or HashPreimage) then there can be a match statement handling only those acceptable messages, and if something else arrives then create an error.

Other ways might be possible too.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.