knocte · March 16, 2017 16:37
diff --git a/gistfile1.txt b/gistfile1.txt
 knocte> this article claims that you have said that SegWit is not required for NTumbleBit; however, is that really true? if you have transaction malleability, you cannot really use any payment channel securely, right?
 (https://stratisplatform.com/2016/12/07/anonymous-transactions-coming-to-stratis/
 but AFAIU, even someone could malleate a transaction malliciously to break a uni-directional payment channel setup
 they wouldn't be able to take your funds by doing that; but they would be able to freeze your funds (the ones you put in the payment channel) forever
 (unless the operator of the tumbler is a nice guy and gives you an updated transaction signature to get your funds back at channel-expiry time)
 but the point of payment channels is that they should be trustless... so again, AFAIU, you cannot have trustless payment channels (even unidirectional ones) with non-SegWit
 ethan> SegWit is not required for TumbleBit. The freezing attack is not possible, but I think I understand the confusion.
 The freezing attack is possible if you use relative timelocks via CSV or traditional timelocks, but we use absolute CTLV timelocks which doesn't need SegWit.
 You could actually do Lightning with absolute CTLV timelocks and you would need SegWit, but then you'd have to renew your lightning channel every X days, but lightning choose to pursue the more elegant/efficient solution (relative timelocks using CSV) but that also means they need SegWit.
 Lets look at the unidirectional channel using CLTV as TumbleBit does. Alice puts in her Bitcoins in a transaction with the following spending rules:
 Spendable:
 If signed by Alice and Tumbler
 or
 If LT on spending transaction > CTLV and signed by Alice.
 thus if Alice holds her secret key, she can create a fresh refund transaction at any point, but that refund transaction would only be valid after X blocks.
 If the txid of the escrow transaction is changed, she can just generate a new refund transaction and sign it.\
 knocte> but that needs to be signed by the Tumbler as well, and the tumbler gave Alice a signature that depended on the escrow transaction which was malleated, and then invalid, no?
 ethan> the refund transaction does not need to be signed by the Tumbler
 the refund transaction only needs to be signed by Alice
 knocte> ah I see
 ethan> Its super confusing due to the three different timelock mechanisms in Bitcoin.
 knocte needs to read the CTLV / TumbleBit spec then
 ethan> CTLV is really awesome
 Our first version, Blindly Signed Contracts has that exact weakness you pointed (without segwit). We were super happy when CTLV came out because we could fix it.
 Actually I'm wrong, CTLV came out in time and we changed Blindly Signed Contracts at the last moment to add CHECKLOCKTIMEVERIFY and not have to worry about that.
 knocte> so then what's better than BSC about TumbleBit?
 ethan> TB is much better than BSC:
 1. BSC requires a soft-fork to work (this the biggest drawback) TB is compatible with today's Bitcoin,
 2. BSC as a payment hub is vulnerable to an abort attack, TB fixes this,
 3. BSC as a payment hub requires two escrows per user, TB only requires one,
 4. BSC as a payment hub requires very strong timing coordination between Alices and Bobs this is difficult to achieve in practice, TB does not have this requirement,
 5. BSC as a payment, in terms of privacy does not handle Alice-Tumbler or Bob-Tumbler collusion well, TumbleBit fixes the Alice-Tumbler collusion privacy problem,
 6. BSC as a Tumbler requires at minimum three block confirmations rather than TumbleBit's two confirmation (this could be fixed borrowing a technique from TumbleBit).


 BUT WHAT IS TUMBLEBIT???

 The physical analogue of the TumbleBit protocol would be a store (i.e. the Tumbler) which:
 1. sells lockboxes for 10 cents that contain banker cheques worth 1.10 dollars,
 2. and sells magical single use keys which open these lockboxes for 1 dollars and 20 cents.
 A can pay D 1 Dollar by asking D to buy a lockbox, then buying a key and sending the key to D. D opens the lockbox with the key and cashes the backer cheque getting 1.10 dollars (minus the 10 cent cost of the lockbox D has received 1 dollar).
 The store doesn't learn that A is paying D, just that A is paying someone who bought a lockbox. In TumbleBit we use cryptography to ensure:
 * that "the lockbox" (which is actually an encrypted Bitcoin transaction) must contain the expected value (preventing the Tumbler from cheating),
 * that a key can only be used once
 * and that after 5 days the value inside the lockbox returns to the Tumbler.


 How to do a payment network with TumbleBit (equivalent to Lightning Network):
 ------------------------------------------------------------------------------

 H1 and H2 are TumbleBit payment hubs.A wants to pay B.
 A--->H1-->H2--->BIf B learns the solution e2  to the puzzle z2 then B gets 1 BTC. If H2 learns the solution e1 to the puzzle z1 H2 gets 1 BTC. Thus, if A learns e2 it can pay B.1. A offers to pay H1 if it learns blinded(e2),
 2.  H1 runs PSP with H2 to learn blinded(e2),
 3. A then atomically swaps 1 BTC with H1 for the solution to blinded(e2),
 4. A sends e2 to B to pay B 1 BTC.H1 learns that A is paying someone connected to H2 but doesn't learn who at H2 A is paying.
 H2 learns that H1 just bought a solution but doesn't learn who at H2 is getting paid and doesn't learn who at H1 is paying.



 nicolasdorier
 1:28 PM
 @ethan H2 is unaware that H1 is a hub ?
 1:31
 ha no
 1:32
 I wonder how to generalize that to n hops

 ethan
 11:33 PM
 @nicolasdorier  You can generalize it to n hops. Ask H1 for e5, H1 asks H2 for e5 in exchange for 1 BTC, etc... Each hop can be reblinded. After two hops you don't get any privacy benefits over onion routed LN channels. So to save computation time  A should just setup an onion routed LN channel from her to H1 and then do the above protocol to pay B through H1 and H2.
	knocte> this article claims that you have said that SegWit is not required for NTumbleBit; however, is that really true? if you have transaction malleability, you cannot really use any payment channel securely, right?
	(https://stratisplatform.com/2016/12/07/anonymous-transactions-coming-to-stratis/
	but AFAIU, even someone could malleate a transaction malliciously to break a uni-directional payment channel setup
	they wouldn't be able to take your funds by doing that; but they would be able to freeze your funds (the ones you put in the payment channel) forever
	(unless the operator of the tumbler is a nice guy and gives you an updated transaction signature to get your funds back at channel-expiry time)
	but the point of payment channels is that they should be trustless... so again, AFAIU, you cannot have trustless payment channels (even unidirectional ones) with non-SegWit
	ethan> SegWit is not required for TumbleBit. The freezing attack is not possible, but I think I understand the confusion.
	The freezing attack is possible if you use relative timelocks via CSV or traditional timelocks, but we use absolute CTLV timelocks which doesn't need SegWit.
	You could actually do Lightning with absolute CTLV timelocks and you would need SegWit, but then you'd have to renew your lightning channel every X days, but lightning choose to pursue the more elegant/efficient solution (relative timelocks using CSV) but that also means they need SegWit.
	Lets look at the unidirectional channel using CLTV as TumbleBit does. Alice puts in her Bitcoins in a transaction with the following spending rules:
	Spendable:
	If signed by Alice and Tumbler
	or
	If LT on spending transaction > CTLV and signed by Alice.
	thus if Alice holds her secret key, she can create a fresh refund transaction at any point, but that refund transaction would only be valid after X blocks.
	If the txid of the escrow transaction is changed, she can just generate a new refund transaction and sign it.\
	knocte> but that needs to be signed by the Tumbler as well, and the tumbler gave Alice a signature that depended on the escrow transaction which was malleated, and then invalid, no?
	ethan> the refund transaction does not need to be signed by the Tumbler
	the refund transaction only needs to be signed by Alice
	knocte> ah I see
	ethan> Its super confusing due to the three different timelock mechanisms in Bitcoin.
	knocte needs to read the CTLV / TumbleBit spec then
	ethan> CTLV is really awesome
	Our first version, Blindly Signed Contracts has that exact weakness you pointed (without segwit). We were super happy when CTLV came out because we could fix it.
	Actually I'm wrong, CTLV came out in time and we changed Blindly Signed Contracts at the last moment to add CHECKLOCKTIMEVERIFY and not have to worry about that.
	knocte> so then what's better than BSC about TumbleBit?
	ethan> TB is much better than BSC:
	1. BSC requires a soft-fork to work (this the biggest drawback) TB is compatible with today's Bitcoin,
	2. BSC as a payment hub is vulnerable to an abort attack, TB fixes this,
	3. BSC as a payment hub requires two escrows per user, TB only requires one,
	4. BSC as a payment hub requires very strong timing coordination between Alices and Bobs this is difficult to achieve in practice, TB does not have this requirement,
	5. BSC as a payment, in terms of privacy does not handle Alice-Tumbler or Bob-Tumbler collusion well, TumbleBit fixes the Alice-Tumbler collusion privacy problem,
	6. BSC as a Tumbler requires at minimum three block confirmations rather than TumbleBit's two confirmation (this could be fixed borrowing a technique from TumbleBit).


	BUT WHAT IS TUMBLEBIT???

	The physical analogue of the TumbleBit protocol would be a store (i.e. the Tumbler) which:
	1. sells lockboxes for 10 cents that contain banker cheques worth 1.10 dollars,
	2. and sells magical single use keys which open these lockboxes for 1 dollars and 20 cents.
	A can pay D 1 Dollar by asking D to buy a lockbox, then buying a key and sending the key to D. D opens the lockbox with the key and cashes the backer cheque getting 1.10 dollars (minus the 10 cent cost of the lockbox D has received 1 dollar).
	The store doesn't learn that A is paying D, just that A is paying someone who bought a lockbox. In TumbleBit we use cryptography to ensure:
	* that "the lockbox" (which is actually an encrypted Bitcoin transaction) must contain the expected value (preventing the Tumbler from cheating),
	* that a key can only be used once
	* and that after 5 days the value inside the lockbox returns to the Tumbler.


	How to do a payment network with TumbleBit (equivalent to Lightning Network):
	------------------------------------------------------------------------------

	H1 and H2 are TumbleBit payment hubs.A wants to pay B.
	A--->H1-->H2--->BIf B learns the solution e2 to the puzzle z2 then B gets 1 BTC. If H2 learns the solution e1 to the puzzle z1 H2 gets 1 BTC. Thus, if A learns e2 it can pay B.1. A offers to pay H1 if it learns blinded(e2),
	2. H1 runs PSP with H2 to learn blinded(e2),
	3. A then atomically swaps 1 BTC with H1 for the solution to blinded(e2),
	4. A sends e2 to B to pay B 1 BTC.H1 learns that A is paying someone connected to H2 but doesn't learn who at H2 A is paying.
	H2 learns that H1 just bought a solution but doesn't learn who at H2 is getting paid and doesn't learn who at H1 is paying.



	nicolasdorier
	1:28 PM
	@ethan H2 is unaware that H1 is a hub ?
	1:31
	ha no
	1:32
	I wonder how to generalize that to n hops

	ethan
	11:33 PM
	@nicolasdorier You can generalize it to n hops. Ask H1 for e5, H1 asks H2 for e5 in exchange for 1 BTC, etc... Each hop can be reblinded. After two hops you don't get any privacy benefits over onion routed LN channels. So to save computation time A should just setup an onion routed LN channel from her to H1 and then do the above protocol to pay B through H1 and H2.
No results found