Conversation
| // USDFC sybil fee support | ||
| address public usdfcTokenAddress; | ||
| uint256 public usdfcSybilFee; | ||
| address public paymentsContractAddress; |
There was a problem hiding this comment.
this is a bit sad .. making pdpverifier aware of the outside world, poor innocent little child, blissfully being concerned about its one thing, now it has to care about two new outside things
IMO a whitelist would have been fine, but whatever
There was a problem hiding this comment.
Haha yeah I know how you feel. It was something @jennijuju really didn't want and ultimately I became convinced this was the least dirty of the two approaches. But I agree still sad.
|
This and FilOzone/filecoin-services#437 seem fine, but have you got any ideas about how we test this without too much hassle? I'm a little worried about the rail->auction mechanism actually working. |
I'll run a calibnet deployment and test to check that the funds land in the payment contract's account. As long as that is happening we should be good. I can additionally run a microbot that claims auction results to verify that FIL is getting burnt here too. |
|
|
||
| _refundExcessSybilFee(sybilFee); | ||
| uint256 balanceAfter = _getPaymentsUsdfcBalance(); | ||
| ensureBurned(USDFC_SYBIL_FEE > 0 && balanceAfter >= balanceBefore + USDFC_SYBIL_FEE, defaultToFilBurn); |
There was a problem hiding this comment.
We can require USDFC_SYBIL_FEE > 0 in constructor
| function createDataSet(address listenerAddr, bytes calldata extraData) public payable returns (uint256) { | ||
| uint256 sybilFee = _validateAndBurnSybilFee(); | ||
|
|
||
| function createDataSet(address listenerAddr, bytes calldata extraData, bool defaultToFilBurn) |
There was a problem hiding this comment.
can we use msg.value > 0 for defaultToFilBurn?
There was a problem hiding this comment.
actually this is a good suggestion, and we could get rid of the 3-arg form of createDataSet and just use the value transfer as the signal for ensureBurned; caller paying suggests maybe they should pay, but also if they shouldn't we refund them anyway
There was a problem hiding this comment.
also the overloaded addPieces is the same
|
|
||
| function _getPaymentsUsdfcBalance() internal view returns (uint256) { | ||
| if (PAYMENTS_CONTRACT_ADDRESS == address(0) || USDFC_TOKEN_ADDRESS == address(0)) return 0; | ||
| try IFilecoinPay(PAYMENTS_CONTRACT_ADDRESS).accounts(USDFC_TOKEN_ADDRESS, PAYMENTS_CONTRACT_ADDRESS) returns ( |
There was a problem hiding this comment.
can we do without the try/catch in here? we're already guarded by the if just above so why would this revert? and if it does revert and we're in a new world where Curio isn't sending 0.1 FIL, calls will fail with UsdfcSybilFeeNotMet and you won't know why; should we just make this call and let the revert come from this site if there's going to be one? or is there something about this call that makes it important to try/catch?
This is the pdpverifier piece to close out FilOzone/filecoin-services#435