search

bisq-network / bisq

A decentralized bitcoin exchange network
https://bisq.network
GNU Affero General Public License v3.0
4.69k stars 1.26k forks source link

Seeding signed accounts #3576

Closed sqrrm closed 4 years ago

sqrrm commented 4 years ago

With the release of Bisq version 1.2.0 the concept of signed accounts went live. This will build a web of trust between users/accounts of Bisq. After a trade between an unsigned account and an account that has signer rights the unsigned account will be signed. Initially the accounts with signer rights were accounts signed by arbitrators. Those accounts had been in a dispute such that arbitrators could verify they were trading honestly.

Currently there is a lack of accounts that has signer rights, especially in the GBP and BRL markets. Some options on how improve the situation:

eigentsmis commented 4 years ago

Another small market in my opinion is CAD. Wasn't able to see any signed account offers for 0.01BTC or under in last two weeks. The method of payment in this market is "Interac e-Transfer". My suggestion to minimize chargeback risk from unsigned accounts would be to impose a 24 or 48hr wait window after the BTC seller marks payment received before the security deposit is returned to BTC buyer.

ripcurlx commented 4 years ago

I'm pro letting vetted mediators sign new accounts, so market makers in specific markets could agree with trading peer to open a mediation case and let, after payment verification by the mediator, sign both accounts. Just lifting limits in some markets might create new opportunity for scammers and won't work on the long run.

eigentsmis commented 4 years ago

I'm pro letting vetted mediators sign new accounts, so market makers in specific markets could agree with trading peer to open a mediation case and let, after payment verification by the mediator, sign both accounts. Just lifting limits in some markets might create new opportunity for scammers and won't work on the long run.

Great idea!

MwithM commented 4 years ago

Just lifting limits in some markets might create new opportunity for scammers and won't work on the long run.

What about establishing a certain volume levels where limits are not lift?

sqrrm commented 4 years ago

@MwithM That's what we have now. We have a few markets with enough volume that we consider risky and those require signing to lift limits.

FKrauss commented 4 years ago

Talking as a guy hearing a lot of people on the ground in the bisq-brasil group on telegram.

I like the first option better than the others. It is more reliance on the mediator, but that is already a Bonded role and that is a temporary role they will perform.

Once there are enough accounts signed mediators don't need to have that function anymore. Or are you proposing that mediators permanently retain that role?

How is then signing when a new payment method is introduced? because I am working on exactly that for BRL and there will be no one signed in it at first.

sqrrm commented 4 years ago

@FKrauss We have had some thoughts about how to bootstrap new markets and BRL is almost like a new market with regards to signed accounts. We haven't come to a conclusion previously on how to do it but considering the first batch of signed accounts were signed by arbitrators it makes sense to introduce that for mediators in new markets. I think it should be temporary until there is enough signed accounts to keep it self sustained.

mpolavieja commented 4 years ago

I am not completely sure that doing it through mediators is secure. Using arbitration cases was secure the first time it was done. But if scammers know that is going to be the process from now on, couldn´t they make a fake trade, open a dispute, then agree quickly on resolution and therefore trick the mediator? This could work for sure only if the mediator has a proof that the bank payment did take place.

Another possibility is that accounts that have long term bonded reputation attached are able to sign (see @wiz proposal). In this case, if a scammer sets up a bonded account (which is already unlikely) and signs other stolen accounts, he will have to wait very long for the BSQ to unlock before he can use the stolen accounts, so probabilities are higher that he might have lost access to those stolen accounts.

In any case, I believe that in the long run whatever the signing process is, it is important to have a good detection system to quickly detect rotten branches, so the signed tree gets more trustworthy over time.

FKrauss commented 4 years ago

Hey guys, shall we arrive to a conclusion here? Also, Shall we finish discussing this on keybase?

eigentsmis commented 4 years ago

Maybe we can setup specific Keybase channels for certain bisq issues on github? So that we can discuss easier, with less friction?

3576_SeedingSignedAccounts (or something of this nature, to reference the specific open github issue)

FKrauss commented 4 years ago

I think that's a good idea. But we need to check how archiving works there. We wouldn't want to have a huge list of archived channels showing up whenever people want to manage their notifications. In slack it's pretty straight forward, but keybase seems to be a bit behind in things like that.

Let me check that and I'll be back in a min

On Sun, 1 Dec 2019, 02:53 eigentsmis, notifications@github.com wrote:

Maybe we can setup specific Keybase channels for certain bisq issues on github? So that we can discuss easier, with less friction?

3576_SeedingSignedAccounts (or something of this nature, to reference the

specific open github issue)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bisq-network/bisq/issues/3576?email_source=notifications&email_token=ABEY5S7VGRT2F5INCOQ5AU3QWMKH3A5CNFSM4JKHDKY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFQYILA#issuecomment-560038956, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEY5S3G66J6YU4HG5EJP2TQWMKH3ANCNFSM4JKHDKYQ .

FKrauss commented 4 years ago

You can't really archive a channel but we can rename it. So once the channel is done, we add a Z to its name. (at least this is the access I have)

That's not elegant, but that's what we have to go around now.

Shall we?

On Sun, 1 Dec 2019, 12:25 Fabio Krauss Stabel, fabio.krauss.s@gmail.com wrote:

I think that's a good idea. But we need to check how archiving works there. We wouldn't want to have a huge list of archived channels showing up whenever people want to manage their notifications. In slack it's pretty straight forward, but keybase seems to be a bit behind in things like that.

Let me check that and I'll be back in a min

On Sun, 1 Dec 2019, 02:53 eigentsmis, notifications@github.com wrote:

Maybe we can setup specific Keybase channels for certain bisq issues on github? So that we can discuss easier, with less friction?

3576_SeedingSignedAccounts (or something of this nature, to reference

the specific open github issue)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bisq-network/bisq/issues/3576?email_source=notifications&email_token=ABEY5S7VGRT2F5INCOQ5AU3QWMKH3A5CNFSM4JKHDKY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFQYILA#issuecomment-560038956, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEY5S3G66J6YU4HG5EJP2TQWMKH3ANCNFSM4JKHDKYQ .

m52go commented 4 years ago

I would suggest keeping discussion about an issue on the GitHub issue so it remains more public/accessible and available indefinitely. Better for transparency overall.

eigentsmis commented 4 years ago

I think might be a matter of how much debating needs to take place and also the timeliness of the issue. Case A: If it's say a very important proposal that needs to be addressed in couple days and also needs agreement between 10 people then a keybase chat seems a bit more appropriate (assuming a video call is out of question) Then the outcome of the keybase "debate" can be "archived" into github. Case B: If it's a long term discussion then github can be used. Now that I think about it - I kinda like the idea of using keybase as a more lean communication system and then using github to archive/document the summary and action points. Just my 2 lightning sats..

FKrauss commented 4 years ago

well, can we resume this discussion? it will and should be here on gh.

and I vouch for the first solution proposed by @sqrrm

Let mediators sign accounts after a resolved dispute where the trading parties acted correctly Good: Fast way to get new signers as anyone signed this way would be a signer immediately Good: Easy to implement Bad: Trades need to get to mediation to get anyone signed Bad: More reliance on more arbitrator/mediator key

Because this is simply the old risk profile we had and we don't open any new can of worms. In Brazil in particular I would be more worried about scams proliferating (thus not option 3) then Bisq relying on mediators/arbitrators for the signing.

I would rule out option 2 because yes, I agree that it is quite unusual that a signed trader from EUR or USD will know another trader in BRL. In my case in particular I know a couple but having the responsibility of seed signing is quite a big trusted role for 1 new person to have. I myself could not vouch for any of the traders I know in BRL simply because I know them from chatting on telegram, not from completing trades with them. Additionally this option brings a very loosely defined criteria for signing the accounts.

sqrrm commented 4 years ago

I think @mpolavieja has a good point that the initial signing by arbitrators was safe in that it wasn't foreseeable by scammers. Introducing signing by mediators in new markets has a different risk profile. I should have mentioned that in the initial post but I forgot about it. I like the idea of bonded roles having the signing power. I think it would be feasible to implement too.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] commented 4 years ago

This issue has been automatically closed because of inactivity. Feel free to reopen it if you think it is still relevant.