-
Notifications
You must be signed in to change notification settings - Fork 110
swap, contracts, vendor: move to waiver-free simplestswap #1683
Conversation
65e5e5d
to
156b074
Compare
6915f76
to
564f53d
Compare
363ea00
to
c2bb3fd
Compare
c2bb3fd
to
26dbb54
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very welcomed PR! Great simplification.
A couple of comments though, mostly related to comments and minor stuff. But also a couple of potentially important things.
Should we not add a test for Bounced
contracts?
Also, there are conflicts, which appear to have to do with the new vendoring stuff. If you need help resolving, give a shout please.
Finally, AppVeyor is failing, but at first look it looks unrelated to the PR. But maybe we should report it if it is indeed coming from stream
.
contracts/swap/swap.go
Outdated
Beneficiary common.Address | ||
Recipient common.Address | ||
Caller common.Address | ||
TotalPayout *big.Int |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please comment the different payouts. Why is CumulativePayout
different than TotalPayout
? I guess CallerPayout was the amount of the cheque.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added comments.
CumulativePayout
is the value in the cheque. TotalPayout
is what was paid out in this call (e.g. if fully liquid then it would be CumulativePayout
- paidOut
). CallerPayout
is the portion of the payout that goes to the caller of the function, it can be used to incentivise third parties to submit the transaction but we don't use that functionality here. For CashChequeBeneficiary
calls this will always be 0.
swap/swap.go
Outdated
@@ -364,7 +362,7 @@ func (s *Swap) sendCheque(swapPeer *Peer) error { | |||
} | |||
|
|||
// reset balance; | |||
err = s.resetBalance(peer, int64(cheque.Amount)) | |||
err = s.resetBalance(peer, int64(cheque.CumulativePayout)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this still work correctly with the CumulativePayout
? (I did not go and check, just asking, please confirm). We can not just subtract the whole CumulativePayout
from the current balance, or it will overflow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that was correct before (as Amount
also was cumulative, also balance is denominated in honey whereas the payout is in eth) and it's still wrong now. Should we not increase the balance by cheque.Honey
here instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it was incorrect, how come tests don't fail? My comment is actually bad though, this is in sendCheques
, which would be from the debitor/issuer, which would have a negative balance and thus the amount needs to be added, not subtracted.
My question here is this one. Let's assume I have -100 of balance, I send a cheque for 100, then the balance gets back to 0. The cumulative payout is 100 for now. Then I get into a new debt, I get to maybe -100 balance again, issue a new cheque for again 100, now the cumulative payout is 200, but my balance should be reset only by 100. If it is reset with CumulativePayout
, my balance suddenly gets to +100, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the tests don't fail because the only tests that call this are the ones in protocol_test.go
and all of them only send at most one cheque at which point the chequeactualAmount
and the cumulativePayout
will be the same. Regardless it is definitely the wrong thing because accounting needs to be done in honey. As far as I see it the only correct approach is to increase the balance by cheque.Honey
(actualAmount
would also work for now but only because of the hardcode honey price of 1).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I extended the TestTriggerPaymentThreshold
test to trigger a second cheque and as expected it did the wrong thing. Increasing by cheque.Honey
resulted in the expected behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is definitely another major issue with accounting. If two separate nodes run their balance tracking already diverges significantly after the first cheque.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never mind. It only looked this way due to further swap accounting happening in the meantime. Both nodes remain in sync now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is the only actual in-process simulation we should write: That we spawn up a number of nodes, exchange some data and then check that all balances are symmetrical.
24ad566
to
47153ec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only a very minor thing and a major question left.
Please check the comment about resetBalance
swap/swap.go
Outdated
@@ -364,7 +362,7 @@ func (s *Swap) sendCheque(swapPeer *Peer) error { | |||
} | |||
|
|||
// reset balance; | |||
err = s.resetBalance(peer, int64(cheque.Amount)) | |||
err = s.resetBalance(peer, int64(cheque.CumulativePayout)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it was incorrect, how come tests don't fail? My comment is actually bad though, this is in sendCheques
, which would be from the debitor/issuer, which would have a negative balance and thus the amount needs to be added, not subtracted.
My question here is this one. Let's assume I have -100 of balance, I send a cheque for 100, then the balance gets back to 0. The cumulative payout is 100 for now. Then I get into a new debt, I get to maybe -100 balance again, issue a new cheque for again 100, now the cumulative payout is 200, but my balance should be reset only by 100. If it is reset with CumulativePayout
, my balance suddenly gets to +100, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have focused on dependency changes and only technical aspects of this pr. From that point everything is fine including @holisticode comments.
3f15d73
to
935e353
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding the test with the 2nd cheque, that makes me feel more comfortable that it is working correctly :)
935e353
to
d6013bd
Compare
* 'master' of github.com:ethersphere/swarm: swap: fix TestHandshake and TestEmitCheque (ethersphere#1721) cmd/swarm-smoke: prevent smoke test from executing trackChunks twice when we debug (ethersphere#1717) swap, contracts, vendor: move to waiver-free simplestswap (ethersphere#1683)
This PR changes swap to use the new waiver-free SimpleSwap contract.
More precisely it
serial
andtimeout
(as well as the related checks)amount
tocumulativePayout
(to be consistent with naming in new SimpleSwap)ChequeBounced
eventHoney
away fromChequeParams
(which is now only for fields that are actually signed)