-
Notifications
You must be signed in to change notification settings - Fork 36
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
Security considerations for LIST / BUY #11
Comments
Yea was expecting this race condition. If we're still playing with thesis "all UI need to obey" which we are, things can go wrong on so many levels.. first I can think of looking for finalized block but what if someone submit tx and it was already sold on background meanwhile till user loads and decides, no-one will return that money back. We can double-check just before signing and broadcasting tx if art is still on sale. 4. Dedicated time window for heavily interested buyer. |
another option could be treating "LIST"/"BUY" as just another form of (pay-to-bid) auction, specifically a first-bid-wins auction, where every purchaser makes a bid to purchase - the winner simply wins the right to make the purchase in some range of future blocks - in scenarios of low liquidity, these two operations can happen in the same batch, at the behest of potential purchasers, but in periods of high liquidity, they may wish to split their bid into one block and see if they have won before paying the full BUY price. |
I have limited understanding still, but so far I like the idea of using something like mempool listener to keep track of pending treansactions to double check pending remarks Although it's not 100% guarantee I think |
So option 3, yeah. It would need to reliably read the mempool AND the unfinalized blocks, recognize IDs and remove them from the UI. I don't know how robust nodes are against a barrage of RPC calls of this type though. |
When minting, race conditions don't really matter or happen. However, with the upcoming LIST / BUY functionality, any UI displaying a list of NFTs for sale has no idea if someone has already issued a transaction towards it. This can lead to several purchases for a single NFT, where it would be the seller's responsibility to refund those whose purchases did not go through. We can't really count on people's goodness here, so two solutions are possible:
mightwill figure out how to send bogus WS messages and block UI for everyone else, effectively hoarding all the items.The text was updated successfully, but these errors were encountered: