Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Puzzle Solving protocol changes (for paymentHub mode) #4

Open
osagga opened this issue Mar 15, 2018 · 4 comments
Open

Puzzle Solving protocol changes (for paymentHub mode) #4

osagga opened this issue Mar 15, 2018 · 4 comments
Assignees

Comments

@osagga
Copy link
Owner

osagga commented Mar 15, 2018

Write up for the Solver protocol (in Payment-Hub mode)

Changes to the Transactions (smart contracts)

T_escr:
        input = A
        output = [Q BTC] -> (T and A) OR (A and tw_1)

Cooperative A and T:

T_cash:
        input= (A and T)
        outputs=
            0. [j BTC] -> T
            1. [Q-j BTC] -> A

Uncooperative A:

T_puzzle:
        input= (T and A)
        outputs=
            0. [j BTC] -> (T and all pre images of specific hash values) OR (A and tw_1) #Check the way the refund is written here.
            1. [Q-j BTC] -> A
T_solve:
        input= (T and all the preimages)
        output= [j BTC] -> T

Uncooperative T:

T_refund (to get money back from T_escr):
        input= (A and tw_1)
        output= [Q BTC] -> A
T_refund (to get money back from T_puzzle):
        input= (A and tw_1)
        output= [j BTC] -> A

How the puzzle solving protocol should behave in this mode

image

(The puzzle solving protocol for Q=1 from the TumbleBit paper, page 10 here)

Mainly the protocol is same as the Q=1 case, except with the following modifications:

On the Tumbler side

  • Overall setup

    • Identify each Alice with her Bitcoin address (ECDSA PK) and the amount Q that was escrowed in T_escr.

    • Keep a counter for the number of puzzles solved for each Alice.

    • Keep solving puzzles for this specific Alice as long as the number of solved puzzles is less or equal to Q

    • If the counter is bigger than Q, Abort (or request more money from Alice?)

  • Transactions

    • Solving the i_th puzzle for Alice
      • After step 7, Alice sends a T_puzzle that gives i BTC to Tumbler if it provides the solution for the i_th puzzle.

        • Note that T_puzzle is not posted to the blockchain but sent to the Tumbler
      • The Tumbler validates T_puzzle (the right amount, ...etc)

      • Send the solution of the i_th puzzle hash pre-images) directly to Alice.

      • Expect Alice to send back T_cash that allows the Tumbler to receive i BTC and gives Alice Q-i BTC.

      • If Alice sends back T_cash (Cooperative Alice):

        • Keep T_cash, continue solving puzzles for Alice as long as i <= Q

        • If cashout, sign and post T_cash that gives the most money to the Tumbler (cashout).

      • If Alice doesn't send bach T_cash (Uncooperative Alice):

        • Sign and post T_puzzle.

        • Form and sign T_solve with the puzzle solution preimages and post it on the Blockchain.

          • Please note that the only harm to the Tumbler from an Uncooperative Alice are the transaction fees associated with posting T_puzzle and T_solve (due to their large size).

On Alice's side

  • Form and post T_escr with Q BTC on the Blockchain.

  • Solving the i_th puzzle from the Tumbler

    • In step 8, form and sign T_puzzle that allocates i BTC to the Tumbler and Q-i to Alice (from T_escr), but instead of posting T_puzzle (like what you would do in Classic Tumbler), send it to the Tumbler directly.

    • Expect the Tumbler to send back the solutions (pre-images) directly.

    • If Tumbler sends back the solutions (Cooperative Tumbler):

      • Continue the protocol as expected (solve more puzzles or finish?)
    • If Tumbler doesn't send back the solutions (Uncooperative Tumbler):

      • Wait till the Tumbler posts T_puzzle and T_solve to cashout the solved puzzles so far.

      • Retrieve the solutions from T_solve.

      • If T_solve is never posted (Tumbler never cashed-out), then wait till tw_1 and post T_refund to get the escrowed money back.

        • No harm to Alice since the money is back to her.

NTumbleBit status regarding the required changes (Needs more research through the code base)

  • Not Implemented:

    • The new smart contracts (T_escr, T_puzzle, ...).
    • The "Overall setup" section mentioned above for the Tumbler.
    • Most of Alice side modifications.
  • Implemented/partially implemented:

    • Right now (Classic mode), Alice receives the solutions from the Tumbler directly (if its cooperative).
      • In Classic mode, it is not expected for Alice to receive the solutions directly from the Tumbler but rather through scanning the Blockchain for T_solve.
        • Refer to this write-up for more details
      • Needed changes would include not posting T_puzzle but rather keep sending it to the Tumbler (along with the other steps mentioned above)
@osagga osagga self-assigned this Mar 15, 2018
@goldbe
Copy link
Collaborator

goldbe commented Mar 15, 2018

Omar, can you revise please? Remember that no transactions are actually posted to the blockchain until the cashout phase. Instead, we just pass transactions back and forth between Alice and Tumbler. We only post the last transaction that we get, once we finish making the last payment.

So you will need to revise the parts where talk about posting please

@osagga
Copy link
Owner Author

osagga commented Mar 16, 2018

Yeah sorry I thought that was already implied. I revised the parts related to posting transactions and tried to state clearly when a transaction is posted or not. Let me know if it's clearer now.

@goldbe
Copy link
Collaborator

goldbe commented Apr 6, 2018

Note:

T_refund (to get money back from T_escr):
input= (A and tw_1)
output= [Q BTC] -> A

There's no way to have tw_1 in the input. That's just the time window. Instead the script will confirm that T_refund was confirmed in a block that was confirmed after time tw_1.

@osagga
Copy link
Owner Author

osagga commented Apr 6, 2018

Yeah I figured, but I tried to keep the structure of the definition of the transaction to be consistent with how the TumbleBit paper defines them (see picture below).
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants