Open chimp1984 opened 4 years ago
This statement sounds a bit confusing to me. I think you refer eith bond to a conceptual "slice" of a bond which is allocated to only 1 trade. The bond itself (I interpret bond as the amount locked up in the bond tx) should be reusable for multiple trades.
Yes in my proposal a bond can be "sliced" and each slice can be allocated to 1 trade. Depending on the size of the bond that can mean more than 1 trade per bond.
Can you specify that? I am not aware of a 3rd party in the preliminary concept needed for verification. The peers are doing it.
3rd party refers to the other peers. The direct participants are the maker and taker. This proposal removes the need for "witnesses" by other peers. This is better for privacy and security.
there is no guarantee for the order and availibility of delivered messages.
This is exactly the point. A scammer (or a bug) could cause an over subscription of a bond. There is no way for any network participant to know for certain if an announcement uniquely connects a bond to a trade.
This is exactly the problem that POW solves. Arriving at a distributed consensus in regards to membership and ordering of txs in blocks in a decentralized way is how bitcoin solves the double spend problem. Everybody knows that everybody knows that a UTXO is unique once its been added to a block.
OTOH if I am a taker and receive the announcement I can not independently verify that the messages are legit, and even with a witness message I have no idea wether or not there has been a network partition and there are contradicting messages being distributed in a different part of the network.
The lockup tx does not require a mandatory change output. See https://docs.bisq.network/dao-technical-overview.html#lockup-tx This could be changed if required but changes in the DAO consensus should be avoided as long not absolutely needed (or for bug fixes).
Adding the need for the BTC change output is backwards compatible and does not need a change in DAO consensus. Its just a simple conditional, if you want to opt in to this scaling solution you must add a change output. You don't have to if your bond is not intended for that use case. This is the only way I can think of to reliably detect a UTXO that can be used for this purpose without a change to the consensus. But perhaps someone else can think of a way.
The proposed solution lacks of details for me to make it possible to think through it. I understand that this is probably intended as a first step and that is fine...
Yes this is just a preliminary draft, many details (that I haven't documented) are omitted. Thank you for your feedback!
- Who is doing the tx (mentioned in your doc), we need to avoid to introduce a centralized entity. If traders are doing it, do we achieve the scaling properties we want?
- When is a commitment tx needed? Trade-offs between security/speed/tx costs and potentially privacy.
I suggest that the traders do it themselves. This is the most decentralized solution. But there is a trade off with scaling obviously. For low frequency traders this is still a gain compared to the current solution but roughly 1 tx per trade would still be required. For traders that do more trades it is up to them when they submit the tx so they can wait a certain time and commit to the tx whenever they are ready to group trades together. Theoretically you can assert as many trades as you want with 1 tx. Its just a matter of timing. The longer you wait the more tx's you can group but the longer the whole trade process lasts which is potentially worse for UX.
Of course if the counterparty accepts the proof without it being confirmed in a block the trade can still move on and the counterparty already has evidence of the intention of the trader. Its just that in case of a scammer its possible that the confiscated bond would later not be able to cover all losses. It is probably a small risk.
So the trade off is: don't wait for conf block - faster trade, good security, risk of over subscribed collateral (meaning non full refund) wait for conf - longer trade, best security, proof that the collateral has not been over allocated
To achieve more scaling you could have a bisq-network provided service that performs the transactions. Then proofs from all traders (or ones that opt-in) could be grouped together. This means better scaling but less decentralization. We don't trade off privacy but we do trade of censorship-resistance. The central service cannot change or forge any data and would not know about any details of trades (as everything is hashed) but could theoretically black list nodes from participating.
Is it possible to only use those commitment txs for the edge cases which might introduce security weaknessed in the preliminary proposal? That way we might get 99% of the time the benefits of not requiring a BTC tx and just in case an edge case occurs (e.g. timeout, disputes,..) the commitment tx is needed to guarantee security. Might be a bit like in Lightning Network as well as the dispute case in relation to privay (usually only the 2 traders know about the trade but in case of a dispute which should be rare the mediator/arbitrator will get involved as well).
This is an interesting idea but wouldn't solve the over-subscription risk. For asserting 'I was promised this' (proof-of-existance) there is no need for a tx.For proving 'And no one else was asserted something that conflicts with this' (proof-of-non-existance) you need the tx. If you leave out the proof-of-non-existance there is an attack vector by which a scammer can start n trades and prove they are collateralized (re-using the bond). Once they have received the value and exit, the DAO can confiscate the bond (it will be clear that there was a scam) but the BSQ would not be enough to cover all the losses.
This is the same risk the previous proposal has. We can of course decide it is acceptable and move forward without the tx (for large trades I wouldn't recommend this). Either way this proposal is also more privacy preserving than the previous one.
Thanks for looking into the concept for an off chain trade protocol.
For reference I refer to the preliminary concept with the version in that document: https://docs.google.com/document/d/1sTbm7SuIGQ5HWCwbxYfnklyMHB_-jIr7kAM9-ZSzzH8
Here a few comments and feedback:
This statement sounds a bit confusing to me. I think you refer eith bond to a conceptual "slice" of a bond which is allocated to only 1 trade. The bond itself (I interpret bond as the amount locked up in the bond tx) should be reusable for multiple trades.
Can you specify that? I am not aware of a 3rd party in the preliminary concept needed for verification. The peers are doing it.
I do not see the direct equivalence to a 0-conf transaction.
Though I share the sentiment that the current idea might be not secure as we only rely on P2P network (beside the initial bond tx) and there is no guarantee for the order and availibility of delivered messages. It still would be interesting to find out in which part(s) of the current protocol the security is flawed.
I discussed that with @sqrrm as well but I did not had time to look closer into the single-use seals concept. I agree that this feels like an interesting path forward but would like to find out first what is broken in the preliminary concept to understand our problem space better.
The lockup tx does not require a mandatory change output. See https://docs.bisq.network/dao-technical-overview.html#lockup-tx This could be changed if required but changes in the DAO consensus should be avoided as long not absolutely needed (or for bug fixes).
The proposed solution lacks of details for me to make it possible to think through it. I understand that this is probably intended as a first step and that is fine...
Some challenges with the single-use seals concept migh be: