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

Security considerations for LIST / BUY #11

Open
Swader opened this issue Mar 3, 2021 · 4 comments
Open

Security considerations for LIST / BUY #11

Swader opened this issue Mar 3, 2021 · 4 comments

Comments

@Swader
Copy link
Contributor

Swader commented Mar 3, 2021

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:

  1. Use a centralized DB and communicate through it with the UI.
  • Pros:
    • Easy to quickly disable / remove an item that's being purchased
    • Might work faster than a chain-native solution
  • Cons:
    • Might crash during high demand periods.
    • Centralized
    • ?

  1. Add a "centralized" relayer of websockets through which all the different decentralized (IPFS / local) UIs will communicate with each other. The only purpose of this relayer would be to recognize when a TX is in progress for a certain item and to disable that item in other UIs.
  • Pros:
    • More decentralized than the above option
  • Cons:
    • Need to implement in such a way that the WS emitter checks the API connection for Kusama, the TX for a pending one, and makes sure the TX exists in the nodes the other UIs have connected to, for safety.
    • Even with the above, someone might will figure out how to send bogus WS messages and block UI for everyone else, effectively hoarding all the items.
    • Still has a central element

  1. Add a pending and non-finalized BUY watcher, which would disable an item if it detects a BUY for it in the mempool or an unfinalized block, and put it back if the tx is dropped or the block is forked out.
  • Pros:
    • Decentralized
  • Cons:
    • Hard to reliably implement?
@Swader Swader changed the title Pending TX Watcher Security considerations for LIST / BUY Mar 3, 2021
@yangwao
Copy link

yangwao commented Mar 3, 2021

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.
OR
We can come up with some lock period for particular buyer, like handshake window for lockup period (time) which is dedicated to particular buyer, here i can brainstorm more on stake on art which we've been exploring in past and have some knowledge there

4. Dedicated time window for heavily interested buyer.

@jam10o-new
Copy link

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.

@Yuripetusko
Copy link
Member

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

https://github.com/protofire/polkadot-mempool-explorer/blob/main/api/services/polkadot/index.js#L224

Although it's not 100% guarantee I think

@Swader
Copy link
Contributor Author

Swader commented Mar 3, 2021

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.

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

4 participants