@bisq-network improvement proposals
Home Page: https://bisq.wiki/Proposals
See issues for the current list of open proposals and read the documentation at https://docs.bisq.network/proposals.html for complete details.
When a contributor files a proposal in the Bisq app they have to add the link to the Github issue where the content of the proposal is described.
Once the proposal period has ended the content of that link should be persisted to an immutable datastore so it cannot be changed or deleted.
It would be good if we can use the Github API to snapshot the issue and then commit it. It would be also good if the data is still readable (html) but I think that is not a hard requirement. It can be expected that there are no conflicts anyway which require to lookup an old proposal.
Not sure what would be the best and easiest way how to implement that. A special service which gets triggered by the first block after the proposal phase to snapshot the issues and then make a commit of that data. Multiple nodes (e.g. seed nodes) could do that and before committing they check if there is already a commit with that hash.
I am not sure if that feature is really important at least for the start probably not. But I wanted to write it down here for discussion and to for maybe implementing it later.
Based on discussions in compensation requests bisq-network/compensation#96 and bisq-network/compensation#95 we should decide on how we want to proceed with translation/review compensation before next voting round.
@BravoIndia, @HarryMacfinned and @ripcurlx had a call on this topic last Sunday with following outcome:
Translation and review contributions are up for compensation when following criteria is met:
added based on discussions below:
For languages that are not included within the client the translator/reviewer is advised to spark a discussion in the #transifex channel why this new language should be integrated (e.g. translator also acts as market maker for this market). Decision is made on a case-by-case basis. As soon as language is included within the Bisq client it is up for compensation.
If this one criteria is met all translations that are done in Transifex are up for compensation even if they have not been released yet. We plan to release once a month and all translations will be updated by the Transifex admin anyways before each release.
As it would be quite complicated to come up with a perfect formular to calculate the compensation amount we'll do it as usual and let it evolve organically out of compensation requests. This should give new translators/reviewers an idea what to expect for compensation.
Voting on compensation requests (or more general proposals) requires time and expertise to evaluate the proposal. If the voter does not have sufficient time for due diligence it leads to a better total vote result to not vote rather that to follow how others have voted or to vote based on "feeling".
Best would be if we could delegate vote to others where we know they are more expert or familiar with the request but that is not planned for the first version of the BSQ/DAO due to added complexity and effort (it might be added at some later stage). But we could gain a similar effect if those who are not experts on the subject and/or do not spend sufficient time to evaluate the proposal cast their vote as zero and therefore give those who do vote more relative voting power.
Of course it is important to emphasize that any BSQ stakeholder can vote on whatever they like—but they should keep in mind that the goal of voting is to make the best management decision for the project (and their BSQ stake represents the share of the overall value of the project). So anyone is welcome to become expert and spend enough time to be able to meaningful valuate others proposal, though if that is not the case then it is better for the project to not vote and leave it to others who can fulfill that.
I think many proposals have usually only one or two other contributors who work with them more closely or who are closely familiar with the field the contributed worked on.
Another note:
Please vote explicitly 0 and do not just ignore a vote so everyone can see whether the stakeholder intended to "delegate" their vote or if they just did not care to vote at all.
Please give a thumbs up or thumbs down if you support this proposal as a general guideline or not.
We will use the normal trade protocol for trading BSQ with BTC (BSQ is treated like any other altcoin). That way we don't have extra effort for supporting BSQ trading.
Because BSQ is technically BTC (a colored coin) we could use a single atomic transaction to swap BSQ with BTC (not to be confused with atomic cross chain tx - we don't have the cross chain aspect and therefor all is much easier).
Let's assume Alice wants to buy 100 BSQ for 0.1 BTC.
The tx would look like that (ignoring miner fee, trade fee and change outputs):
Input 1 (Alice): 0.01 BTC
Input 2 (Bob): 100 BSQ
Output 1 (Alice): 100 BSQ
Output 2 (Bob): 0.01 BTC
Such a transaction is completely trustless and has zero risk, as it either gets confirmed and both users get their funds or nothing happens (atomic property).
Beside having a better, faster, cheaper and more secure trade option for BSQ we could enable automatic swaps and make first time BSQ purchase easier.
The user who has no BSQ need to buy first BSQ on the market to be able to get the discounted trade fee. With the atomic swap we could offer a "Get BSQ at best market rate" button where the app takes the best market price offered for a BSQ/BTC swap. Any market maker could add offers to that dedicated offerbook and the user experience would only be interrupted by the requirement to wait for 1 blockchain confirmation until he can use his received BSQ. But even for that there might be a solution if the BSQ seller is paying the trade fee for the users via a protocol extension (to be defined how to do in detail, but I think that should work and then the user do not need to wait for the block confirmation).
Technically it can be built based on the part of the take-offer protocol where the desposit tx gets created. So there will be a handshake protocol where both users exchange the required data to co-sign the tx.
The trade fee could be deducted from the BSQ output and some BSQ get burned so that would solve the first user who has no BSQ cannot pay the trade fee issue. The BSQ seller also need to add a bit more BSQ to his input as it would be the case of the pure exchange rate and therefor also pays his part of the fee. E.g. the burnt BSQ is the sum of maker and taker trade fee.
Let's assume a BSQ fee of 0.05 BSQ for both traders. The tx would look like that (excluding miner fee and change outputs):
Input 1 (Alice): 0.01 BTC
Input 2 (Bob): 100.05 BSQ
Output 1 (Alice): 99.95 BSQ
Output 2 (Bob): 0.01 BTC
Burnt BSQ: 0.1 BSQ
While completing the BSQ/DAO we think of any potential use cases which would make sense to support so we are flexible enough to support any of those in future. If it is consensus relevant it would otherwise require a hard fork as old not-updated clients would get a different result if we add new features which they don't know how to interpret.
Of course we don't want to add complexity and effort for stuff what we even don't know for sure but there are features which are already implemented for special purpose DAO use cases (like bonding or parameter change) and those might be extended for a more general purpose variant without much effort.
I will give here an overview about the already implemented and planned features and how they can be extended to more generic types.
Voting on DAO parameters to change the DAO itself
We have already the voting for parameter change implemented (see list of current params here [1]). Many DAO parameters like the fees for proposals, voting or trade or the required quorum and threshold for voting or even the nr. of blocks of the different DAO phases (like the voting phase) can be changed by voting and will be applied in the next voting cycle. There is a hard coded enumeration of such parameters and adding new ones is a hard fork. All of those parameters (beside the BTC trade fee) has direct effects on BSQ/DAO consensus. So we are not very flexible with that approach.
Voting on parameters to change Bisq behavior
We have planned (not impl. yet but rather trivial) a variant to case 1 but without consequences for the BSQ/DAO consensus though consequences in Bisq: The "Remove altcoin" proposal is such a use case. If the proposal gets accepted the altcoin will get removed from the supported currencies (technically it gets filtered away from the currency list so users cannot use it anymore but is still in the code).
Voting on a statement without triggering anything in Bisq
Another proposal type which we have in planned (not impl. yet but even more trivial) is the "Generic proposal": Here a user can make any statement to be voted on. It does not has any code-based consequences but the result might give some signal. E.g. If a user makes a request for "Bisq should put priority on SegWit" and if it gets accepted by voting it will not auto-magically add segWit support :-) to Bisq but might give a strong signal to developers to pot priority on that topic.
Voting on arbitrary statements and exposing the result as an oracle
We could use the same concept as in case 2 but with a more flexible data structure. So again it will not has direct effect on the BSQ/DAO consensus but it could be used in a code-based context new yet-not-known use cases. For a flexible data structure we can use a hashMap (key and value are strings) and users can make a proposal where they define the key and the value what should be voted on, so it is completely open which keys and values will be used here and how and by whom they will get interpreted later. If that proposal gets accepted by voting it could be used either in a Bisq context and a new software release could add code to interpret that "accredited-by-voting" data. Users who have updated will execute that data others will ignore it.
It also could be used outside of a Bisq context and others could access that data and use it in their context (e.g. some smart contracts or as non-code based signal). If the data consumers would run Bisq they can access the data securely otherwise if accessed via an API or webpage they need to trust the data provider (there could be several to reduce risks).
One use case which came to my mind would be a kind of reputation poll. One could ask the Bisq stakeholders a question like: "Would you trust Craig Wright with giving him a loan of 100 000 USD?" (key: "trustCraigWrightWith100kForLoad", value: "yes"). It should has a pgp signed statement (on the linked Github issue) and the stakeholder can vote with accept/decline or ignore. If the outcome was the he got majority acceptance the proposal requester could use that outcome in a lending market as sign for reputation (that BSQ stakeholders would trust him I doubt it in that example ;-)). The peer giving him the loan could either run Bisq to look up the result himself or there might be some APIs which present those oracle results to the outside world.
Maybe we could add here additionally a "burn BSQ" feature so it will have some extra costs (can be defined by the requester) for requesting an oracle result. That would add some weight to the result as it shows that the requester was willing to take some risk to lose that BSQ in case he would not receive acceptance.
I don't have other concrete use cases in mind yet, but I think to expose the power of meritocracy based voting could be an important extension and the technical effort and complexity is rather low.
The trust model for those oracles is based on the group who produces the voting: The BSQ stakeholders. Voting is backed by 2/3 meritocracy and 1/3 stake. That has to be kept in mind and adds clearly limitation of the possible use cases. E.g. using the oracle for financial products (prediction markets) might be problematic.
Other limitations come from the BSQ/DAO market capitalization and connected volatility and manipulation risks as well as trust in the BSQ implementation as well as ultimately in BTC (as BSQ is based on BTC).
Please let me know what do you think and if you have some ideas with other use cases!
In order to avoid that bisq-trades can be assigned to a person via time/amount analyses (on the fiat side), it is recommended to trade with full euro amounts (0 cents), as there are then on average 39 times as many transfers of exactly the same amount on the same day in the entire currency area (compared to the average of the frequencies of the other 99 possibilities .xy).
With the current crooked amounts, it is only a question of time when many of them can be assigned to a person after the fact, since the complete history of the amounts/times is public. The smaller a currency area is, the more important this is, since the same amounts occur less frequently on the same day than for dollars and euros. Unfavorable cents such as.74 and.93 are even 390 times less common than rounded amounts and there is a high risk to be the only person in the currency area using the same amount on the same day.
Coinigy is a commercial, subscription-based charting platform, which seems to be the best of the kind for crypto at this point.
Coinigy
I and an associate propose to fund an integration with it for the bisq network.
Purpose:
A. Increase liquidity on bisq by:
My bet is that this will bring more professional, HF traders to bisq, and consequently increase liquidity when they bring arbitration and market maker bots on the emerging trading API.
Proposed actions:
A. Fund the one-time fee to Coinigy for the basic charting integration.
B. Fund, create and operate a persistent bisq and bitcoin node that will supply Coinigy with bisq markets data via websockets.
Please give this issue a thumbsup, if you think this is a worthwhile integration, which would merit BSQ compensation.
Thank you for your attention.
During the last few voting rounds I have found that some requests for compensation might have needed more time for review and discussion.
In general, out of self interest to get a reasonable proposal accepted it's good to post it early if there is any reason to believe it might be contentious. Additional discussion around it could help to make voters understand the reason and perhaps give some time to modify the request. The reverse is true for an unreasonable proposal (eg, asking for compensation for work not done, changing parameters to weaken the DAO). By posting it late and giving no time for review and discussion voters might choose to abstain and with only a few yes votes the proposal would get passed.
It's expected that contributors understand what they vote on and should thus reject unreasonable proposals. However, with the idea of delegated voting and that the default is to abstain when not sure that opens up for passing unreasonable proposals.
I propose to prolong the break (BREAK1) between proposal (PROPOSAL) and voting (BLIND_VOTE) phases to have time for reasonable review and discussion. Two or three days rather than just a few blocks would give sufficient time for contributors to voice their opinion on any unreasonable proposals.
By adding more time between proposal and vote resolution there is a potentially longer time between work and reward.
@flix1 suggested an interesting idea how we could use reputation without running into the sybil attack problem: To use negative reputation and tie it to the payment account (bank account).
A Bisq identity (onion address) can be easily changed but not a bank account.
Not using positive reputation avoids that a user could trade with himself and increasing reputation that way.
The arbitrator acts as trusted party who gives negative reputation in case of severe trade contact breaches. By default the score of a user is 0. With each severe contract breach the score decreases by a value of 1 to 10.
We try to improve security in ways which are compatible with the privacy protection of the users.
Bad actors hurt the platform and should be kept out.
We have seen in the past 2 charge back cases we had so far that the scammer was involved in several disputes earlier. At least in the recent charge back case the scammer tried a triangular scam attempt (and failed), which would have led clearly to a negative score (a bold -10) with that new model.
Also in the first charge back scam a year ago the scammer had canceled several trades, though that was not such a clearly severe case (he reached his monthly bank transfer limit) but as it happened repeatedly it would have likely summed up to some negative score as well.
Beside detecting clear scammers it helps to detect users who are abusing the system for instance by "future trading" (canceling if the price moves against them). Such less severe and not 100% clear cases would be treated with a smaller score hit (e.g. just adding -1 to their overall score).
In case of a severe trade contract breach the arbitrator can add a negative value (0-10) to the score of a user's payment account as well as to his onion address. The onion address is not a strong base, as he can easily change his onion address so we cannot count on that too much. Though it helps to potentially spread the score to other accounts of that user. The payment account is unique and usually users don't have a large variety of payment accounts.
The hash of the payment account is used as the key for that score. The score of the maker will be displayed in the offer. A taker will see that score before taking the offer. A maker can decide to only accept takers above a certain score level. The score can be displayed by a few icons with the score value (e.g. green icon with score 0, yellow icon for score 0 to -10, red icon for scores below -10).
The verification is done only in the trade process (similar as account age witness). The offer cannot be verified as the account data are not included in the offer, but if a maker would us an invalid hash in his offer (which would result in a wrong score) the trade will fail once a taker takes the offer and detects the invalid data while verifying the account data and the hash.
One problem with that scheme might be that a heavy trader who ends up in lots of disputes has a higher risk to collect negative score. Though in case the trader acts correctly there should not be any reason the arbitrator gives negative score. Only traders acting on the "edge" have higher risks here.
The arbitrator gets some extra burden by not only resolving the dispute but also by judging the severity of the contract breach. But that is done already now as the arbitrator can decide how much of the security deposit goes to the other peer. Maybe we could even combine that so the payout of the security deposit reflects the score? I would though prefer to keep it separate and use the negative score only for really severe cases. But that is up for discussion...
The score data is tied to the hash of the bank ID (e.g. IBAN + BIC) as well as to the onion address.
The data structure is a hashmap with the hash as key and a list of data items with the score, the signature and the index of arbitrators pubKey as value. Each time the arbitrator adds a negative score an entry will be added to the list. The total score is the sum of all entries in the list.
The arbitrator signs the hash + score and his signature as well the index of his public key (list of all arbitration pubKeys are hard coded in app) are attached to the data.
Data structure:
hash = RIPEMD160(SHA256(bank ID))
signature = EC sig (hash + score)
dataItem = score, signature, index of arbitrators pubKey
Hashmap:
Key: hash
Value: list of data items
The same data structure is used for onion addresses, just that instead of the bank ID the onion address is used.
The offer contains the hash. With that each user can lookup the total score and it would get automatically updated in case there is a dispute where the maker receives negative score while having an open offer.
We cannot use a salt together with the Bank ID like we use it in the account age witness because a user with negative score could change simply his salt to reset his score. In the account age witness case the data represents a positive asset to the user so he is not interested to lose that by changing the salt. In this model the data is a negative asset.
By not using a salt a bank or anyone who knows the bank ID of the user could calculate the hash and then lookup the score hashmap for that user. If they can find an entry they would know that this user is a Bisq user who received a negative score.
We consider it less critical here because by default a user has no entry in that hashmap, only if he received a negative score. This problem also seems rather theoretical and with the reference text the bank has a much easier way to find a pattern which suggests that a client is a Bisq user.
Though if anyone has an idea how to improve that aspect, please share it!
I am proposing a module to provide a full Bisq node as a headless "Black Box" with Rest interface. It is optional from command line to launch a http API interface on localhost and/or the javaFX GUI client.
Code and instructions can be found here: bisq-engine
Presently, the Bisq business logic resides in the dataModels of the gui module. Engine uses interfaces on the io.bisq.gui classpath for the REST service to interact with the logic. Minor refactoring on some dataModel 's is needed to prune out pre-existing GUI logic that would throw errors in headless.
This is done by:
dataModel class over to bisq-engine on it's existing classpath, thus overriding gui.It is envisaged that this will allow development of bisq-engine to be unhindered, while providing a clear space for diffs and collaboration on building a common, gui agnostic, business logic architecture for the whole stack.
After discussions and feedback from various contributors I think there are several good reasons to rethink our current policy that requests are only done for shipped code.
As we have seen with the long lasting projects the current policy comes with several drawbacks.
I would suggest that we change the current policy from "being shipped" to "being merged to master". I think that still holds the goal that we don't spend funds on work which might never lead to value for a user but reduces delays, gives more motivation and reduces risks.
@cbeams What do you think?
This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.
Since we began submitting and voting on compensation requests more than 9 months ago, @bisq-network/role-owners have taken various approaches to requesting compensation for their efforts.
Generally, those who have "hard costs" such as hosting fees always request that amount as part of their overall compensation request, but the "softer costs" of time and effort involved in carrying out the duties of their role have not been well-accounted for.
I have just published a new 'Roles' in bisq-network/bisq-docs#46 that lays out specific instructions for how role owners should account for these costs as part of their monthly reporting and compensation requests. These instructions can be found in the https://docs.bisq.network/roles.html#compensation section. Please read this section and respond here with any questions or clarifications. As per usual, please also react to this proposal with a 👍, 😕 or 👎 as appropriate.
The goal of getting this document and proposal out now (July 10th) is to be able to start following this new practice in next month's Aug 1st–3rd compensation voting.
For those who play a repository maintainer role, please also see the https://docs.bisq.network/roles.html#maintainer-duties section and pay special attention to the "Maintainers are not Developers or Reviewers" admonition. Separating PR development and review from the strictly defined work of maintenance is an important part of keeping role compensation accounting simple and largely repeatable from month to month.
As a final note, I want to acknowledge the overhead that dealing with compensation requests and monthly reporting causes for people, especially those who still own a large number of roles. My goal is to refine these processes until they are as smooth and efficient as they possibly can be, but doing so requires constant attention and refinement along the way. It's extremely important to the future of BSQ that users understand and have confidence in the way we account for our efforts as contributors and role owners. Thanks everyone for helping to achieve this goal. Please provide whatever feedback you think will accelerate or improve the process.
This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.
As documented at bisq-network/mailchimp#9 and elsewhere, MailChimp shut our account down. This leaves us with no way to communicate with our ~3,000 mailing list subscribers.
We have our own mailing list infrastructure at https://lists.bisq.network; let's use it.
I propose we create a new read-only [email protected] mailing list that we use for broadcasting important announcements about Bisq and the Bisq Network, including:
To date, our newsletter has been low-volume to a fault—we virtually never used it. I propose that this new newsletter would remain low-volume, but perhaps aim for a cadence of one or two emails per month. It would remain primarily focused on letting users know about new features and releases, and we would never want it to feel overtly promotional or slick. The medium is really the message here; by moving to a lo-fi Mailman mailing list, we're letting people know that this is a no-frills, value-oriented communication channel, not a marketing tool designed to surveil and manipulate.
Can we automate the process of signing up for a Mailman list? i.e. such that users can fill out a form field on the https://bisq.network website and subscribe to the list? This is potentially important because the Mailman web UI is super minimal and old-school. It's great for technical people, but may turn off or turn away less savvy people. And in general, it would just be good to be able to streamline this, such that we can have a simple newsletter signup form on the website. @Emzy, can you look into this? Note that even though our website is statically generated, we can hook in handling form submissions via our hosting provider, Netlify. So it is possible for us to have a bit of code that does whatever is necessary to subscribe someone.
Anti-spam compliance. MailChimp and other providers go to all sorts of lengths to ensure compliance with CAN-SPAM and other regulations. As far as I know, it's enough to have the usual unsubscribe link at the bottom of Mailman-generated emails. We're not a company, we don't have an address or contact information, etc, so we shouldn't need to put any of that stuff in the footer of these emails. I don't see how this list would be any different than any other open source mailing list, but I'm not a lawyer, so if someone can provide confirmation about this, please do.
What to do with the existing 3,000 list subscribers. I've been able to extract the set of current subscribers from our MailChimp account before being locked out forever, and I have that data now in CSV form such that we can import it into the new bisq-announce list. I would just want to confirm with everyone here that we in fact do want to do that. I don't see a strong reason not to; these subscribers did opt-in to getting announcements about Bisq, and we'd be transferring them from the old newsletter infrastructure to the new bisq-announce infrastructure that has essentially the same purpose. This seems like an entirely legit thing to do, but if anyone has a reason to object to this, please speak up.
This list will need an owner. I don't want to see us set up this infrastructure only to fail to use it like we did with MailChimp, and I don't want to assume this role myself. @m52go, you mentioned in bisq-network/roles#27 (comment) that you'd be interested in taking on this kind of role. I'd see the minimum set of duties being making sure that we get an email out to the bisq-announce mailing list every time there's a Bisq Desktop release, and to take the time to craft that communication a bit so that it's something more substantive than just a copy-and-paste of the release notes.
Whoever plays the bisq-announce mailing list admin would have write access to the list. Anyone who wants to can subscribe to the list and read it, and of course the archives would be publicly visible at https://lists.bisq.network like all our other lists.
Subscribers would not be able to respond to emails though, in order to avoid the list becoming too noisy and people dropping off. We'd want to have a standard footer that directs people to ask questions via the Bisq Forum, Slack, etc.
If this proposal is approved, I would want to announce it via Twitter in conjunction with making a bit of noise about MailChimp shutting us down. People should know that MailChimp is doing this to honest Bitcoin projects, but we shouldn't make that noise without also giving people something to do about it, like signing up for our new bisq-announce newsletter. So I'm holding off on any MailChimp tweets for now, until we've approved this and gotten everything set up.
Note that I also removed links to the old newsletter from the website, and I would also add those links back in when we announce this new list.
Thanks for reading. Please take some time to think about this and provide feedback, thanks!
We could add a referrer Id to the offer (we can use the extraMap hashMap which would not cause backward compatibility issues)to track offers created by the API and reward those who provide the API. That would deliver a metric as base for compensation requests.
This is a very rough first draft idea and I wanted to request feedback before specifying it more in detail.
We've had the proposals repository here for a number of months, and we've used it in a variety of ways over that time. I'm proposing the following clarifications and refinements to the proposals repository and to the overall proposal process to help everybody use this resource to best effect:
Write proposals for specific changes you want to see in Bisq and the Bisq DAO, especially for changes that would benefit from or otherwise require feedback and agreement from other contributors. For example, proposals are a good way to get feedback about introducing a whole new Bisq component or making a big change to an existing one, and proposals are good for making changes to the way we work together under the Bisq DAO. Proposals are not so good, however, for discussing smaller or more low-level changes to existing components. That kind of thing should be done with normal issues and/or pull requests in components' dedicated repositories.
Aim for rough consensus, and avoid voting on proposals whenever possible.
Write proposals in a way that makes it as easy as possible to achieve rough consensus. This means that proposals should be as simple, focused, concrete and well-defined as possible. Your goal as a proposal author should be to make it as easy as possible for your fellow Bisq contributors to understand and agree with you about your proposal.
Get to rough consensus using 👍 and 👎 reactions to proposal GitHub issues. If you give a 👎, say something about why. Explain your objections, so they can be addressed. If you don't explain your objection, don't be surprised when it gets ignored. If you do explain your objection, you should expect it not to be ignored; that is, proposal authors should address all reasonable concerns and objections.
When reviewing proposals, ignore the ones you don't care about or don't know enough about to have an opinion on, and do not hesitate to give a 👎 reaction to proposals you do not want to see enacted.
Start by writing a proposal issues like this one. Only write a proposal documents if and when necessary.
As the author of a proposal, you are 100% responsible for that proposal's success. It is not the @bisq-network/proposals-maintainers' job to see your proposals succeed. If people aren't responding or reacting to your proposal, it's your job to solicit that feedback more actively.
Never assume that anyone other than yourself is going to do the work described in your proposals. If your proposal does place expectations on other contributors, or requires them to change their behavior in any way, be explicit about that.
@bisq-network/proposals-maintainers should assign proposals to their original authors to make it clear who is responsible for them. Assignments can be changed on request, e.g. if someone is handing off a proposal to be managed by someone else.
Proposal owners should aim to get to rough consensus within a week or two. That's enough time for everyone who might care to have a look and comment and for any necessary discussion to ensue. Much longer than that and the proposal will probably "die on the vine" and ultimately get closed due to inactivity.
@bisq-network/proposals-maintainers should close proposals after a month of inactivity. Proposals can always be re-opened. The purpose is to keep the set of open proposals small and with a high degree of "liveness" to make it easy for people to review open proposals without risking wasting their time. Basically, the proposals maintainer's job is to make sure there are no "broken windows", that stale / inactive proposals get closed, and that existing open proposals follow whatever best practices we decide on like the ones above.
@bisq-network/contributors should click the "Watch" button on the proposals GitHub repository to be notified of new proposal issues and comments on existing proposals. Individual proposals issues you don't care about can always be muted / unsubscribed from.
The point of all this is to make proposals simple and easy to use for everyone involved. As we move away from co-founders being the prime movers and decision makers, these proposals will only get more important. Let's start using them more systematically now, and start building the kind of decision-making culture we want to see in Bisq's future.
So, if you're on board with the clarifications and refinements above, please give this issue a 👍 below. If not, please give it a 👎 and explain your concerns or objections. Thanks.
One solution for the problem that the offer maker need to be online could be that we offer a new feature with a new type of offer.
This new type - lets call it "trade intent" - would not have BTC reserved and a taker cannot take it directly. It would only give an option that an interested taker can contact the maker and then the maker receives a message and has to go online to convert his intent into a real offer. Then the taker receives a message so that he can browse that offer and can take it.
So there would be an out-of-system notification method required which helps to bring both parties online at the same time.
Here of course is the challenge which notification system we can use which does not require a running Bisq app. It could be simply email or any messenger but that comes with privacy and security (phishing) risks and it will not integrate well with the process.
Better would be a proxy system where the messages are routed over our P2P network and utilize the Bisq mobile app. There though we have atm only the solution where your Bisq app need to be online, but there are ideas/discussions to extend that model to support offline mode.
Unfortunately there is no perfect trust-minimized way to achieve that, but at least it might be useful for those who prefer convenience and it would extend the reach of Bisq to such users and with that increase liquidity.
Just wanted to push that idea out for further discussion and conceptual refinement if it is considered worth to go further.
This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.
UPDATE:
We have altered the initial idea to keep the arbitration as option. Details will get added soon.
Here is a short summary of the key points of that proposal:
We suggest a change of the current Bisq trade protocol which is based on a 2-of-3 MultiSig deposit transaction where an arbitrator is the 3rd key holder who helps in case of disputes and can make the payout transaction with one of the traders. The new protocol would be based on a 2-of-2 MultiSig deposit tx where only the 2 traders are the key holders. We would delegate the dispute resolution (which in fact is 99.9% customer care work and no real disputes) to the users as first step and if they cannot resolve the issue themselfes to mediators. In case the peers do not cooperate to sign the payout transaction as defined in the trade contract there is an option for the victim of getting reimbursed for the lost BTC amount by the BSQ stakeholders. If the request gets accepted in DAO voting by the stakeholders he get issued the amount of BSQ which is equivalent to the lost BTC. To avoid abuse we introduce a time locked transaction which will send the fund from the 2-of-2 MultiSig deposit tx to the receiver of the Bisq donations (see #48). Before being able to request for reimbursement that timelocked payout tx to the donation receiver need to be confirmed.
This model actually is an insurance model where in case of damage for one trader he can get compensated by the BSQ stakeholders. For the BSQ stakeholders it still is much cheaper than spending lots of funds on arbitrators. It is assumed and need to be achieved that reimbursement requests are rather rare (not more then a few a month - or even less). The system is flexible and there is no automatation which leads to reimbursements, so it can be adjusted over time to optimize the results.
The current arbitration system comes with several problems:
Bisq actually started with the idea of a 2-of-2 Multisig deposit tx and only after concerns regarding potential blackmail risks in such a scenario we dropped that idea and introduced the arbitration system with the 2-of-3 Multisig.
The trade protocol is similar like now just that there is no 3rd key in the Multisig deposit tx. the 2 traders are the only keyholders. In case the trade gets successfully completed both traders sign the payout transaction as defined in the trade contract.
After the traders have created the 2of2 Multisig deposit tx they will additionally create a payout transaction which is timelocked for about 1 month and where the receiver is the donation address defined by the Bisq DAO (see #48). In case both traders do not cooperate to make a normal payout any of the 2 traders can (but don't need to) publish that transaction and therefor spending the funds from the deposit transaction to the donation receiver address. If both agree they can still wait longer and can still create a normal payout at any time. But any of the 2 traders have the power to terminate the trade by publishing the alternative tx. This will be the requirement for requesting a reimbursement.
The technical details which form of timelock (nLocktime, CLTV) we will use is up for discussion and need more investigation.
There is a non-atomic process of the co-signing of the timelocked payout tx (TLP). The seller has more to lose (as he has the trade amount added in the deposit tx) so we will let him be in the role of the deposit tx publisher. He will hold back the fully signed deposit tx before he has received the fully signed TLP tx.
Here is a rough sketch of the protocol:
The seller has the security that his trade amount is only locked in the deposit tx if he has the fully signed TLP tx which would enable him to request for reimbursement in case the buyer do not cooperate.
The buyer will only send the fiat/altcoin payment if the seller has followed the protocol and sent him the TLP tx. If the seller would have broadcast the deposit tx without a TLP tx the buyer would not start the payment. The seller cannot request the reimbursement as there is no TLP signed by both. In such a case the buyer would also lose his deposit but the seller has much more to lose, so it would be an economically irrational strategy.
From our experience as arbitrators we have seen that the huge majority of cases are no disputes but cases with bugs, banking problems or usability issues/user mistakes. Real disputes have been maybe 1 or 2 - I even can't remember any. Sometimes a user does not respond and with the currently short tolerance of 2 days response time such cases get closed then in favor to the other trader. Other cases are "future trades" - in times of high price volatility the trader who would have a disadvantage by completing the trade with the "old" price "cancels" the trade by not completing it. Only the BTC buyer can do that. This is the reason why we have a higher security deposit for the buyer (which he loses in such cases).
We need to increase that security deposit to make such cases very rare.
We want to delegate most of the conflict resolution process to the traders and if needed to mediators. There will be a direct in-app messaging system (like the current one in the arbitration system) which provides encrypted and signed communication. This is important to be able to proof abuse (trolls, scam attampts in chat,...). This communication will be on a per-trade base, so with each trade you can see the history of the messages.
The mediator is basically a customer care agent who can help if needed. The details of that need more discussion but it should be implemented with scalability and flexibility in mind. It should be easy to become a mediator. The current support section in the Bisq Forum is close to such a goal. It is open if that need to be a bonded role but likely it will be. Mediator migh play a role for applying negative reputation score (#27) in case of misbehaviour.
The whole traders communication and mediator area needs more discussion and refinement.
The traders can agree to change the normal payout as defined in the contract in case something went wrong or if a peer violated the trade protocol. We got several cases of such "light" violations: Paying too late, using a different bank account as defined in Bisq or using BTC in the reference field, etc. Such "light" cases could be resolved by the traders agreeing to an alternative payout (e.g. a part of the security deposit goes to the other peer). Another scenario is that the fiat transfer failed (e.g. banking problems) and the seller need to get the refund.
The process would be that the peers agree on a payout and then send their signed payout tx to the other peer who will then broadcast the tx.
In case a trade does not get completed because the peer is either not willing to complete, not responding or a scammer, the victim can make a request for reimbursement of his lost BTC.
He need to broadcast first the timelocked payout transaction where the funds goes to the donation address (can only be done after the lock time has passed). In the voting phase the stakeholders will vote on that request and if it gets sufficient support he will get the BSQ issued which are the equivalent amount to his lost BTC. To avoid abuse we might set the reimburesement rate a bit lower (e.g. only 90% get reimbursed).
With the requirement that the funds in the deposit tx are spent to the donation address we avoid that a scammer could run 2 Bisq nodes, trade with himself, simulate that he got scammed and request a reimbursement. After he received the BSQ he could make the payout to himself and thus have gained the BSQ without haveing lost any BTC. As we require that the funds are spent to the donation address this attack is not possible. Furthermore we add a small loss by only reimbursing 90%. Beside that it requires time and effort to get the reimbursement which should limit it to those rare cases where the traders cannot come to a cooperation.
It is assumed that the donation receiver address is a NGO-like organisation (e.g. Tor,...) or personality with a very high reputation (like Andreas Antonopoulos,...) and that those donation receivers will change from time to time via voting. Thus the theoretical risk that the donation receiver is the scammer (or colluding) and doing reimbursement requests as described above is very low. Beside that, the BSQ staekholders do not need to accept requests and if they are too frequent or there is some suspicious for abuse they can decline it. They can also change the donation receiver if there is any reason for doubt.
It is not intende to be used for those cases where makers or taker lose the trade fee because of technical problems. We will continue to reimburse those in a non-beaurocratic way and those amounts are too low to justify the friction and costs it would create to use the reimburesemnet request model.
This change will be a kind of hard fork on the trade protocol level. We could support both protocols in parallel but probably it is better to make a hard change. Old client will still be able to trade between other old clients but all those who will update are moving to the new protocol. We should also have a defined timeout for not supporting the old protocol anymore and to make it possible to revoke all arbitrators. We should try to implement a conversion of existing offers to the new protocol so the makers are not losing already paid maker fees.
Details about the deployment need further discussion.
There are several other open proposals and we need to consider if we should combine those if do a bigger change and a "hard fork":
Related to a not yet published proposal for a bigger change of the arbitration system we might have the situation that we have to make reimbursements to users who experienced losses in a trade (e.g. the peer did not respond or was a scammer).
Without going more into the details of that new dispute resolution concept we would need a solution for paying out such reimbursements in a decentralized way.
We could add a new proposal type to the DAO for reimbursements. If it gets voted ok the user who filed the request gets issued the requested amount. Technically it is the same like a compensation request and therefore it is quite easy to implement.
It is NOT intended for the current lost trade fee reimbursements which is often about very small amounts (cents to a few dollars). That would create too much "spam" for the voting process and should be still handled in some other - not yet defined - way, but as those amounts are relatively small I would not give priority for finding a solution for that. Best solution is to fix those bugs which causes it ;-).
I know that this proposal might be not 100% clear without knowing the details of those plan for the dispute resolution process but as I need to finalize the DAO and once the DAO is live on mainnet it will be hard to add any changes, I wanted to share the idea.
Beside that concrete use case it could be also use more generic for any cases where a reimbursement might make sense, for instance if users lose funds dua a bug or hack in the DAO.
This is not really a proposal intended to be implemented short term but with the DAO/BSQ we will have new interesting options I would like to share.
The current on-chain trade protocol with the 2-of-3 MutiSig deposit tx has several disadvantages:
With the DAO/BSQ we have a new feature at disposal which we can use to solve all of the above problems: BSQ bonding
BSQ bonding was introduced mainly for adding security for roles which cannot meaningfully be decentralized like holding the domain name or owning the Github account. Those role owners need to lock up a certain amount of BSQ as security that they do not abuse their powerful position.
The lockup mechanism in BSQ is rather simple. We add a special OpReturn data which marks a BSQ tx as lockup tx as well as the unlockTime (used when unlocking the bond). A locked up BSQ bond cannot be spent as no other peer would accept an output from a locked up tx. The only way to spend it is to make a unlock tx (again a special opReturn data marking that tx as unlock tx) to athe users own address. With that unlock tx the unlocking time starts (was defined in blocks in the lockup tx.) After the defined number of blocks has been passed the user can spend that tx output like any other BSQ output - it is now fully unlocked.
So there are 3 states:
In case for bonded roles the role owner need to lock up the required amount and keep that locked until he revokes the role. Then he need to wait for the unlockTime until he can spend that BSQ normally.
If during that time (lockup time or unlocking time) anyone makes a confiscation request for the role owners bond because of some clear evidence of abuse by the role owner (e.g. I as Bisq domain name owner promote on the Bisq webpage BSQ-Cash as the real and only BSQ ;-)) then his locked up bonds can be confiscated. That will require a very high quorum (e.g. min. 100 000 BSQ are needed as stake in voting) and threshold (e.g. > 85% must accept the proposal). That should limit such confiscations to very clear cases where the BSQ stakeholders are very sure that the role-owner has violated his role duties. The confiscation is just marking the BSQ output invalid and no other user would accept such BSQ, so they got un-colored (burnt) and have lost their value.
Confiscation could be done also partially - so that only part of the bond gets burnt (not impl. yet but probably planned to do it to be more flexible).
This model of bonding could be used for other use cases as well:
A offer maker can make a BSQ bond and add the hash of his signature pub key to the OpReturn data of that lockupTx. With that he can later proof with a signature that he is the owner of that bond. E.g. he receives some challenge data, creates a signature from it using his private key and provide his public key as well as the txId of the lockup Tx. The peer can then verify that the hash of the pubKey matches the hash in the lockupTx's opReturn data, the lockupTx is unspent and that the signature is valid by verifying it with the pubKey.
The maker could add the signature of the maker fee txId (no one can re-use that signature as there will be a different txId) to the offer as well as the pubKey and the lockup txId. Any taker can verify the amount of locked up bonds and that the maker is the owner of the bond. The maker could require that the taker also use a reputation bond for securing the trade and would verify that the takers bond is correct when he takes the offer.
This model would only require to put a bit of extra data into the offer and do the required verification in case the bond is used. Implementation effort should be rather low.
One use case could be to use a bonded reputation to guarantee that the trader is not making a charge back in case unsafe payment methods like Venmo or CashApp are used. The unlock time need to be rather long for such cases as charge back might be still possible after a few months.
It also can be used for securing Face to Face trades against risk of robbery - though here it might be more difficult to deliver temper proof evidence, but the fact that such a trade might require a BSQ bond might be enough to keep criminals out as they run a higher risk to lose more money as they could gain and they don't know in advance if the peer can provide good evidence after a theft (e.g. using public cameras footage, police report,...).
But we could go further and remove the security mechanisms we use atm completely (deposit, 2-of-3 MultiSig) and use the security of the bonds as sole protection. This would make the trade completely independent of any crypto currency as smart contract carrier (beside that BSQ is technically Bitcoin ;-)).
The maker can define a contract from some templates (e.g. use public Bisq arbitrators or use private arbitrator or whatever he defines). The taker will view the trade contract before taking the offer so when taking it he agrees to the makers contract. The trade itself can be then completely off-chain: It does not require a crypto currency at all, e.g. it could be a USD-EUR exchange.
In case of a dispute the arbitrator (or whatever is defined in the contract for dispute resolution) would investigate and make his judgement. This judgement can be taken as base for a confiscation request to freeze the locked up bonds of the misbehaving peer. The modality of the contact and dispute resolution can be defined arbitrarily and the publicly exposed facts about the trade required for the stakeholders to make a decision can be limited to a binary recommendation of the arbitrator. With that the privacy is protected to a high degree and only the arbitrator will learn about the details of the trade. But it is just one possible contract/dispute scenario, it is basically totally open to whatever the peers define among themselves.
If Bitcoin is part of the trade it can be sent via Lightning network without requiring to implement a smart contract on Lightning (which would be a big challenge).
This model will remove the requirement for designing a fully decentralized and safe arbitration system (the arbitrator as key holder in the trade has some problematic consequences) as well as the dependency on low miner fees and it avoids the privacy weaknesses with on-chain transactions. The power of the arbitrator is now more limited as he has no partial control over the trade funds anymore. Worst case he can make wrong judgements, but then the traders still have time and opportunity to proof their case publicly in front of the stakeholders to convince them to not follow the arbitrators wrong judgement. And most importantly the public Bisq arbitrators will be just one of many possibilities for dispute resolution.
A bond which is sufficient for covering the max. damage of one trade might not be sufficient anymore if the trader is doing multiple trades in parallel.
E.g. A trader locks up 1000 BSQ (let's assume 1 BSQ = 1 USD) for securing a trade with 1000 USD.
If the trader use the same bond for another trade and would scam both traders his max. damage from confiscation is 1000 BSQ but he might have gained 2000 USD.
To avoid that problem we could use the trade statistic (both peers publish that at taker offer time to the P2P network) and add some extra data for the bond there. So the second trader can lookup how many trades have been done in the past with that bond. As it can be assumed that a trade is completed in at least a few days he can get a good estimation of how well secured a bond is. There might be even some improvements possible to mark the completion of a trade as well, but it need to be checked that this is not violating privacy of the traders.
The bond would become an identifying asset which would connect past trades. But it is up to the trader to use either one or a few bonds for many trades or one bond per trade to not lose privacy. On the other side the number of trades would provide some sort of reputation by indicating how many trades a peer has done. It is the users choice what they prefer here: Building up reputation from past trades or privacy.
For getting a high security against charge back the model might add high costs for locking up bonds to cover the trade amount for longer periods. E.g. if a user trades about 10 000 USD over 3 months he would need to lock up 10 000 BSQ for about 6-9 months. It is an open question if that is a big problem and it would mostly apply to those payment methods which have a long charge back risk period. Compared to the current model it would not be worse even if the bond is not covering such a long period. So that strict long term bonds would apply mostly to high risk payment methods and then a better trade price should pay it off.
Another aspect to consider is volatility of BSQ. If BSQ price goes up it comes with the disadvantage to not be able to sell the BSQ quickly, though that might have a positive stabilization effect on the BSQ market. If BSQ price goes down then the bond which was sufficient at take offer time might not be sufficient anymore during the trade. But such high short term volatility spikes should be an exception and a higher BSQ bond should cover that.
Of course that model would be optional to the current trade protocol also because to use BSQ you need to first buy it on Bisq, so there would be a chicken and egg problem if we would replace the current model completely. Also some users might prefer to not need to use another token and stick with BTC only.
The DAO/BSQ is pretty far from development and bonding is basically implemented. I hope we can launch end of August on testnet.
This idea and model is still very fresh and not thought out in all details but I think it will solve a lot of the problems with the current trade protocol and the challenge how to decentralize the arbitration system. Please let me know what you think and if you find any weaknesses or flaws in the concept!
This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.
After a discussion with @flix1 we came up with an idea how to implement binary option trading in the BSQ system. That could be extended to other trading products later but binary options is the most simple one so it is good to use that as a base.
For users who are mainly interested in speculation such financial tools are more suited than normal exchange as they usually only want to bet on the price and not buy or sell the counter currency.
There are 2 traders (lets call them A and B) making a contract for a binary option. They put in the same amount of money to the contract and if a certain event in the future confirms to a true result trader A gets all the money, otherwise trader B.
There are 2 problems to solve:
Problem 1 can be solved within the BSQ system. Problem 2 could be solved if the result is a BTC trade price. Bisq could provide a decentralized price feed if trade volume is sufficiently high to not get gamed by self trades. There is a direct relation between volume (fees causing costs for manipulation attempts) and the security of the price feed. So it could be used already now for small scale trades (e.g. 0.1% of trade volume of a currency pair).
There might be other open problems to solve to get a trust-minimized price feed from Bisq (network related issues, current concept of the trade statistic data is not built with such use cases in mind and might require changes) but that is out of the scope of that discussion.
For the sake of that discussion let's ignore the oracle problem (assume it can be either solved for certain trade limitations or a model like oraclize provides sufficient security or use semi-trusted/centralized intermediate solution is used until a better model is available).
One could argue if the source of the result is not decentralized then the decentralized execution has also no value, but that is not true as once a solution for a decentralized source is found (or at least within certain transparent limitations) decentralized execution is needed to make the whole system decentralized.
The smart contract is based on BSQ burning and issuance and would work like following:
Both traders burn the agreed amount in an atomic (all-or nothing) tx. In the opReturn there is the hash of the contract and the contract is published in the Bisq P2P network.
Trader A requests the inputs and change output from trader B and then creates a BSQ tx where he burns x BSQ, signs his inputs and sends that pre-signed tx to B. Trader B finalizes the tx with signing his inputs and then broadcast the tx. At that moment both traders have burned x BSQ in one atomic tx. If one of them is not cooperating it would have no effect to the other trader as then his BSQ are not burned as well. This model is similar like the creation of the deposit tx in Bisq trade protocol.
Example tx for burning 1000 BSQ on both sides, assume a miner fee of 0.005:
Input 1: Trade A - 10 000 BSQ
Input 2: Trade B - 5 000 BSQ
Input 3: Trade A - 0.01 BTC for miner fee (we could also split the miner fee that both pay but lets keep it simple here)
Output 1: Trade A - 9 000 BSQ (BSQchange - 1000 BSQ got burned)
Output 2: Trade B - 4 000 BSQ (BSQ change - 1000 BSQ got burned)
Output 3: Trade 1 - 0.003 BTC (BTC change - 0.002BTC or 2000 BSQ got burned,
so 0.005 required fee minus 0.002= 0.003 BTC)
Output 4: opReturn which has a typeByte, version byte
and the 20 bytes hash of the contract
If burned BSQ has more underlying BTC value as required for miner fee would add BTC change outputs to the traders.
Additionally both traders create an issuance tx where they issue 2 x BSQ to themselves. That is invalid as long the contract result execution is not completed. This is similar to BSQ compensation requests. That tx has some costs in BTC as the BTC input needed ("printing cost") has to be paid from the traders. We can consider that as trade costs like a fee.
The contract contains the block height when a certain price is expected and the execution price (price which triggers true/false) as well as the currency pair. If an oracle is used it would contain the relevant data for that as well (e.g. sending pubKey/address of oracle...).
Lets discuss first the model where we use Bisq's internal price feed (based on Bisq trading) so we have a decentralized data source (within certain limitations). Using a trusted 3rd party provider would work similar and will be discussed later.
When the defined block height is reached all BSQ nodes will calculate the price of the currency pair and will check if it was below or above the trigger price. If it was above it will mean that trader A's issuance tx becomes valid and he has issued BSQ to himself. Otherwise trader B will have his issuance tx validated. To avoid the rare case that the price is exactly the trigger price (no winner, no loser) we can introduce another rule to ensure that there is only one winner (e.g. use tx IDs and sort them and take the first, so the winner will be pseudo randomly taken).
If we want to use a trusted 3rd party (oracle) as data source provider it could work like that:
The oracle publishes the price at block height in a tx using opReturn). In the contract the sender address of the oracle was defined so any BSQ node can look up that tx and can read out the price for comparing it with the trigger price. As it was sent from the address the oracle owner is the only one who can create that tx.
I think the basic concept can work but of course the details specially on the trusted price source problem need to be investigated further. It has to be clear that any such model will have limitation in which is can be considered to work "good enough". We could use the Bisq price feed for very low trades even now (at least those currency pairs which have already some volume like EUR, USD and XMR). For trade amounts of say 100 USD that is already good enough from my guts feeling (would require a bit of simple math with the fees to see what are the costs to game the price).
There will be more problems with using the trade statistic data as they are P2P network data and therefore only comes with eventual consistency which will have consensus implications. But that would be topic for future work to see it there are solutions for that...
There are no plans to work on that but as we want to be sure the BSQ system is future proof I think its worth to think about that.
To integrate the Bisq HTTP-API work from @mrosseel and @blabno I suggest following proposal.
Adjust the BisqAppMain and BisqExecutable so that it can configure the correct startup for 3 different modes:
The HTTP-API comes with it's own option keys which will be supported as well. The details how that will be done is not decided yet.
A big part of startup code is currently in MainViewModel and that has to be refactored to the core project.
The HTTP-API specific code would be added in a new project (bisq-http-api). There it might have initially still duplicated code which got extracted from ViewModel classes. That should be cleaned up over time by refactored code where code which is used now both from the UI and the API will be refactored to classes inside core, so we get rid of those code duplication.
An open question is we should already prepare also support for a grpc API model. I suggest to not do that now but once it is implemented.
One concern of @blabno is that we get too many different combinations of possible combinations how to run the app. I don't see that as an issue at least at the current state of basically possible 3 options. The grpc API would add another option but I doubt that all possible combinations makes sense. So from a first thought on it I assume there will be added 2 new options: grpc-only and grpc+Desktop. I don't see a use case to run both grpc + HTTP-API together. It might be well the case that the HTTP-API will wrap the grpc inside.
@cbeams, @mrosseel, @blabno: What is your opinion about that proposal?
This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.
Due to very low trade activity with Litecoin as base currency, I would suggest to remove it as base currency.
The latest trade has been at Feb. 7th. 2018. Currently there are 0 offers and beside the seed nodes only 1 peer online.
I run 2 LTC seed nodes and the arbitrator. To maintain and monitor those takes some effort. Even that effort is not big the close to zero activity does not justify it IMO.
The code base for supporting other base currencies will stay intact only the UI element for selecting another base currency would be removed (as we removed DASH and DOGE for the same reason already).
To have the option for alternative base currency gives Bisq more resilience but practice has shown that bootstrapping another network is difficult and we don't have the resources to focus on multiple markets beside the BTC market. Also it would partition the user base thus making the market bootstrapping on BTC even harder.
Please comment below if you agree or oppose to that proposal. If we get sufficient feedback and if the proposal gets support I might add the removal to the upcoming 0.7.0 release.
Enabling face to face (F2F) trades like offered at LocalBitcoins is an often requested feature but has not been considered to be added because Bisq has a different security model compared to LocalBitcoins and with our model we cannot provide sufficient security to make F2F trades safe. E.g. LocalBitcoins uses ID verification and reputation. Bisq uses the security deposit and the arbitrator as security protection which both would not help much in the context of a F2F trade.
Though there might be an interesting idea to allow us to support F2F trades.
It is based on the game theoretical idea of "mutual assured destruction" which is basically just the idea that if both traders do not come to a cooperative result both will lose all what they have put in the trade (e.g. trade amount and security deposits).
That model was actually used in the very first concept of Bisq and is used in some other projects like BitMarkets and BitHalo/Nightrader.
The reason why we went away from that model was because Adam Gibson found a severe risk for a blackmail scenario.
In short, there is always an asymmetry of the max. loss of each trader due to the fact of the non-atomic exchange on the fiat side. That enables that one trader could blackmail the other who has more to lose to agree to a different payout result as it was originally agreed on. An economic rational trader getting blackmailed in that way would agree to the changed payout to have less financial loss than if he would stick to the original contract and risks that his funds will be locked up forever.
This risk is specially serious in the context of an anonymous global online market.
But we do not suggest a pure "mutual assured destruction" model (based on 2of2 Multisig) but rather to use our existing arbitration system to add more flexibility and to reduce the blackmail risk.
People meeting physically have a different risk exposure compared to the anonymous online market situation. E.g. The possibility of physical access makes unscrupulous behavior less likely. We can assume that the risk of a blackmail is much lower in such a context.
Of course physical access comes also with new forms of risks (robbery) but that has to be mitigated by the selection of a safe public meeting location. The general risk for violence in a certain country has to be taken in consideration as well.
There is no guarantee that the funds will be locked up forever as the arbitrator can do the payout as he thinks it is fair and/or at any time in the future. The threat that the funds are lock up forever is not a strong motivation anymore for the blackmailed person to agree to an altered payout. He rather would try to convince the arbitrator for his side.
If those assumptions holds we could use that model as basic protection for F2F trades.
The payment method will contain an email and/or mobile number field which will be used by the traders to exchange the details for arranging the meeting place.
Beside that there will be the location data (country, city, maybe map coordinates).
In a first version it should be a basic feature but could later be improved by implementing a map to set the position of the trader. Though exact positions of the traders address have to be avoided for security reasons.
Maybe we should add "terms and conditions" the users can define. At LocalBitcoins they often require ID verification of the peer. That should be done only in person to avoid risk of identity theft.
Offers for F2F trades will display additionally the location. In a first version that can be added to the payment method info. A filter option to search for traders by country and city would be good as well. In a later version we could implement a map to look up nearby traders.
Once an offer gets taken both traders get in touch by email or mobile and arrange a meeting place and time.
We could consider that both traders bring their laptop and do the trade process similar like with an online payment. Though the additional risk for theft if they might have more BTC on their wallet as well as the inconvenience and risk to carry the laptop represents some downsides with that simple approach.
They could alternatively meet without any laptop and just do the Fiat transfer and when back home do the confirmation in Bisq for the Fiat sent and received events.
That would reduce the risk of theft to the Fiat amount but it does not feel very safe to hand over Fiat without getting immediately anything back in exchange.
We could require a hand signed contract so both would have at least some form of evidence. Better would be a digital system which is integrated with the Bisq trade process. LocalBitcoins uses Secret codes to be exchanges by the traders but I am not sure if that adds really much protection.
Ultimately there is no solution as the Fiat transfer is not an atomic transfer in exchange to a digital transfer of a signature. The best we can achieve is to bring the moments of both events close together.
Another approach might be to combine a repeated partial payment with repeated confirmations via a mobile app.
E.g. if the trade amount is 1000 USD the BTC buyer could start to hand over 100 USD to the seller. Next step is that the seller confirms on a mobile app the receipt of 100 USD. Then the next 100 USD will be handed over and then confirmed again. That will be repeated until the final amount has been transferred. It would lower the risk that the peer can run away quickly with the money without confirming the receipt. The receipt could be done as simple email to the BTC buyer or via any messenger app. The proof is not strong but at least it adds difficulty for a potential scammer to fake those messages. Best would be a mobile App which is connected to the Bisq trade and provides signed and encrypted messages. But that is too much effort for a first version. It is also questionable if people are really that paranoid and use that repeated payment method or prefer to hand it over in one part and then do the confirmation.
That area needs more though how to deal best with it. For the most simple version lets assume there is a paper contract signed by both traders.
The arbitrator cannot help much in case of a dispute as in most cases there will be testimony against testimony and he cannot get a reliable proof about the transaction. So the standard resolution of any F2F trade disputes will be that both traders will got frozen their funds forever. Though they have the option at any time in the future to still come to an agreement and then tell the arbitrator to do the payout according to the result both have agreed on.
The arbitrator can also choose to make whatever payout he thinks is fair according to the testimonies of both traders. This option makes blackmail even less likely as there is no guarantee that the funds will be kept frozen. Also the blackmailing person will have likely higher risk to lose the case and the arbitrator decides in favor of the other peer. ID verification can be required as well from the arbitrator - a request scammers usually don't want to follow.
One problem is for sure that the dispute resolution adds much higher pressure to the arbitrator as he will not have a tamper proof evidence. But as said to not do the payout at all is a valid default option for the arbitrator. Different arbitrators might have different policies how to deal with disputes which again makes blackmail less likely as the arbitrators strategy is hard to predict.
It can be expected that real disputes are super rare (as with online trades) but most cases are caused by usability issues or bugs. For those cases the resolution process will work like any other payment methods.
In case of theft or blackmail attempt the victim can file a police report and present that to the arbitrator. This will have a lot of weight in the dispute process as it can be assumed the the scammer will unlikely go to that step to trick an innocent peer.
It will require more analysis how the security deposit should be set for F2F trades and it will depend on the model how the Fiat transfer will be executed.
The risks and different rules for dispute resolution have to be very clearly presented and accepted by both traders.
We could add that payment method as experimental for a test run to see how it works in reality and see how much demand exists for it. Before that it would be good to make a poll to see how much demand is really there for F2F trade. The still limited volume on Bisq will be an even bigger issue when it adds a location limitation as well.
Depending on the open questions regarding the fiat exchange process the implementation effort should not be very high. It is mostly UI work and does not require any deeper changes for a fist version. For map integration though the effort will be higher but that should be left for later after a test run has shown how much demand for that payment method exists.
I think we should add more research about the usual issues with F2F trades on LocalBitcoins or other platforms.
If anyone can volunteer to do that research or if anyone has first-hand experience please add it below!
Generally speaking, Bisq DAO roles should have at least two owners, in order to ensure that operational know-how, passwords, keys and other secrets are "backed up" in at least two brains instead of just one. Basically, we want to avoid the situation where any one contributor is a single point of failure for the Bisq DAO.
With that said, some roles do not require active participation from two or more role owners. It is enough, in many cases, for a "primary" role owner to be identified, and for this person to carry out normal duties, respond to requests, and so forth by default, and for the "secondary" role owner to be "on call" should the primary role owner become indisposed for any reason.
Here are a few examples of roles where a primary / secondary distinction makes sense:
@alexej996 is the primary Forum Admin role owner, and @Emzy is the secondary. Emzy has all the keys to Discourse and the box it lives on, knows how to administer things, etc, but @Emzy does not do anything with the forum on a day-to-day basis. He would only respond to a request if asked explicitly to do so.
@mrosseel is the primary Freenode Admin role owner, but @ManfredKarrer and @cbeams both have op status in the Freenode #bisq and #bitsquare channels, so are secondary role owners.
@ripcurlx is the primary YouTube Admin, but @cbeams has full access too.
The proposal here is simple: Role owners should keep their issue descriptions up to date with regard to which assignees are primary and which are secondary. That is, all role owners should be assignees to their respective GitHub issues, but the GitHub issue description should call out which are Primary and which are Secondary. You can see an example of this in bisq-network/roles#56 (YouTube Admin) and bisq-network/roles#22 (Freenode Admin).
Related to the earlier proposal I would like to discuss the policy for filtering inactive coins.
I would suggest those criteria:
minNumTrades and if it did not exceed minTotalTradeAmount it will be marked as inactiveThe question is which values we should apply for minNumTrades and minTotalTradeAmount.
I think minNumTrades=10 and minTotalTradeAmount=1 BTC would be reasonable thought that would lead that we remove most of our assets (only 4 remain). So I think we need to be more tolerant here and rather use minNumTrades=3 and minTotalTradeAmount=0.01 BTC. Those values can be changed over time on
When an asset is marked inactive it is not displayed in the payment account combobox as well in the currency selection in the settings (already selected currencies will stick there). An account with an asset which got deactivated is still valid and can be used. As well offers and trades can be continued. So there is no hard filter. It would make all much more complicate otherwise and would also create more discussions from people who have created an offer and cannot use it anymore.
Beside the filter by inactivity there will be a possibility to vote for removing an asset once the DAO is live.
One open question is how we support re-activation of an asset.
One option would be that a BSQ fee has to be paid to give the asset 120 days warmup phase again.
Assets removed by DAO voting cannot be re-activated anymore.
Here are the list of coins which would remain if we use minNumTrades=3 and minTotalTradeAmount=0.01 BTC and apply it to the last 120 days:
Sufficiently traded assets:
Bitcoin Cash (BCH): Trade amount: 7.2513 BTC, number of trades: 21
Bitcoin Clashic (BCHC): Trade amount: 0.01 BTC, number of trades: 1
Byte (GBYTE): Trade amount: 0.03 BTC, number of trades: 1
Dash (DASH): Trade amount: 0.403 BTC, number of trades: 3
Decred (DCR): Trade amount: 0.20 BTC, number of trades: 1
Ether (ETH): Trade amount: 7.38 BTC, number of trades: 17
Ether Classic (ETC): Trade amount: 0.045 BTC, number of trades: 2
Gridcoin (GRC): Trade amount: 0.0141 BTC, number of trades: 2
Litecoin (LTC): Trade amount: 0.4397 BTC, number of trades: 6
Monero (XMR): Trade amount: 706.2912 BTC, number of trades: 932
Namecoin (NMC): Trade amount: 0.11 BTC, number of trades: 3
PIVX (PIVX): Trade amount: 0.10 BTC, number of trades: 1
Siacoin (SC): Trade amount: 0.0609 BTC, number of trades: 2
Siafund (SF): Trade amount: 1.09 BTC, number of trades: 1
Spectrecoin (XSPEC): Trade amount: 0.642 BTC, number of trades: 7
Unobtanium (UNO): Trade amount: 0.049 BTC, number of trades: 3
Zcash (ZEC): Trade amount: 0.20 BTC, number of trades: 1
ZenCash (ZEN): Trade amount: 0.2224 BTC, number of trades: 4
Insufficiently traded assets (would be removed):
Burstcoin (BURST): Trade amount: 0.0081 BTC, number of trades: 2
Obsidian (ODN): Trade amount: 0.0012 BTC, number of trades: 1
Not traded assets:
10grans (GRANS)
AchieveCoin (ACH)
Angelcoin (ALC)
Arto (RTO)
Better Betting (BETR)
BitDaric (DARX)
BitZeny (ZNY)
Bitcoin Gold (BTG)
Bitcore (BTX)
Cagecoin (CAGE)
Cassubian Detk (CDT)
Conceal (CCX)
Counterparty (XCP)
Creativecoin (CREA)
Cryptonite (XCN)
DSTRA (DST)
Dai Stablecoin (DAI)
DarkNet (DNET)
Decent (DCT)
DeepOnion (ONION)
Devcoin (DVC)
Diamond (DMD)
DigiMoney (DGM)
Dinero (DIN)
Dogecoin (DOGE)
DynamicCoin (DMC)
Ellaism (ELLA)
Espers (ESP)
Exceed (EXC)
GeoCoin (GEO)
Infinity Economics (XIN)
Instacash (ICH)
Internet of People (IOP)
Internext (INXT)
Koto (KOTO)
Kumacoin (KUMA)
LBRY Credits (LBC)
Lisk (LSK)
LitecoinExtreme (LCE)
MFCoin (MFC)
Madbyte (MBYT)
Madcoin (MDC)
MaidSafeCoin (MAID)
Mazacoin (MAZA)
Mycelium Token (MT)
NEETCOIN (NEET)
Nav Coin (NAV)
Nilu (NILU)
NuBits (NBT)
Nxt (NXT)
Octocoin (888)
Particl (PART)
Pascal Coin (PASC)
Pepe Cash (PEPECASH)
Phore (PHR)
Pied Piper Coin (PPI)
PostCoin (POST)
Pranacoin (PNC)
Qwark (QWARK)
ROIcoin (ROI)
ReddCoin (RDD)
RefToken (REF)
Ringo (RIN)
SOS Coin (SOS)
STEEM (STEEM)
Safe FileSystem Coin (SFSC)
Semux (SEM)
Sibcoin (SIB)
SpeedCash (SCS)
Stellite (STL)
Strayacoin (NAH)
Tamadcoin (TMC)
Terracoin (TRC)
The Movement (MVT)
Ubiq (UBQ)
Verify (CRED)
WACoins (WAC)
WILD Token (WILD)
WorldMobileCoin (WMCC)
Wownero (WOW)
Xuez (XUEZ)
Yenten (YTN)
Zcoin (XZC)
vDinar (VDN)
To not mix it up with issue #41 (which is likely to find easier consensus) I will start here a proposal for possible options for fees for Asset listing on Bisq.
There have been also broader discussion in #35 but that has been rejected after longer considerations.
We get too many Asset listing requests and that adds some costs for Bisq contributors to review and merge those assets. Beside that assets which are not traded do not add any value to Bisq, in the opposite they cause bad reputation and usability costs (the user has to scroll through many assets to find the relevant ones, though that is a weak argument ;-)).
There are also some legal aspects we should consider: Many assets are ICO tokens and most of them are at risk to be considered as illegal securities. The SEC has expressed the opinion that exchanges which enable trading of those are violating regulatory rules. We are not lawyers and I think there is no 100% clear opinion about that but it is a fact that adding an ICO token to Bisq adds some legal risks.
Bisq's mission for censorship resistance includes that we don't want to make the decision if an asset is "good enough" or considered legal (in which jurisdiction?) to get listed or not. The DAO voting process will have a feature for removing assets from Bisq so that the stakeholders can make a collective decision here if there is broad consensus.
We also don't want to introduce an "economic censorship" by requiring high listing fees as it is the case on many centralized exchanges (> 100 000 USD in some cases).
We don't want to get spammed by too many assets. Today creating a new asset has close to zero costs and efforts. On CounterParty or Colu there are 100 000s of assets - most have zero relevance. We don't want to get spammed by those.
There have very low costs for asset issuer for adding an asset to Bisq. The requirement to make the PR (address validation) is quite low. So that alone does not work well as spam filter mechanism.
It has to be clear also that listing an asset does not mean for the asset community that the asset becomes liquid. We see how hard it is to bootstrap markets even in the main currencies. The "coincident of wants" problem is very real. There might be other models which are better suited for the needs of niche assets like Bancor where the asset issuer need to provide some market liquidity programmatically.
Don't change anything and delegate the issue to later and see if it becomes a bigger problem.
Right now the required effort for review and merge is not that extreme that it require a fast solution. So to defer that to the future is a valid option.
One issue with that is that we are in the finalization of the DAO and some features might be hard to add later if it is part of the DAO consensus protocol. If we want to use BSQ fees in future it would be good to implement that at least as prototype now.
Adding other non-financial requirements which acts a "spam filter" and demonstrates that the asset has an interested community which might be using Bisq in future once it is listed. I think that is an interesting option but maybe hard to find a good solution which does not lead to getting spammed by marketing from the assets trying to gain more traction and support. Voting for asset listing as it is done on some exchanges is such a way but comes with many problems.
The above mentioned problems with voting could be delegated to the DAO which provides benefits over a simple webpage based voting: Manipulating the votes by bots and PR as it would be an issue for traditional webpage based user voting cannot be done with the DAO. Voting requires to hold BSQ, that causes some costs.
The downside is it will create incentive for asset issues to try to convince the Bisq stakeholders that their asset is the "better Bitcoin". It could be maybe mitigated to make it very clear that unwanted PR on official Bisq channels is considered as spam and BSQ stakeholders should decline such assets in voting. As voting is meritocratic based the BSQ stakeholders who have earned BSQ by work will have the majority voting power, so it will be very hard for asset issues to over-power them by simply buying BSQ on the market.
Such voting based approach could be automated in the way that any asset which got merged is deactivated by default and only if accepted by voting it will become accessible to the users.
One downside is that if we get a lot of requests we have many proposals for those assets and the more relevant proposals get a bit lost. We have about 20 new listings in some month. It also adds data which are stored forever. The DAO voting is not designed for the use case of 100s of proposals.
I want to discuss here one fee model which combines a few different aspects.
What if we determine the "warmup" phase where we don't check for trade activity by the fee the asset issues (or anyone who pays the fee) has paid. E.g. per 1 BSQ fee he gets 1 day of additional warmup time. We can have a default min. warmup period of e.g. 30 days which does not require a fee. After that time if there is no fee paid the asset need to have been traded sufficiently as defined in #41.If a fee was paid it will extend that period by the amount of the fee.
Alternatively and to make the implementation easier we could require a low min. fee of say 30 BSQ so the first 30 days are covered by that. Any asset issuer is able to pay 30 USD (assuming here a BSQ/USD rate of 1 BSQ = 1 USD).
The fee can be changed by DAO voting so we can adopt to BSQ price volatility. By delegating the amount of the fee to the BSQ stakeholders we remove as well burden on developers to find a fair value.
One minor problem is that a asset issuer can get his PR merged but then never pay the fee, so the asset will get deactivated immediately. So it does not prevent that Bisq contributors spend time on review and merge. But I assume that will happen rarely and can be ignored.
Basic idea is to have a special tx with an opReturn output where the hash of the tickerSymbol is in the data (20 bytes). So we can look up when the tx happened and check the hash. Anyone can do the fee payment.
That scheme could be more generally used for proof of burn. One can keep a pre-image of the hash and proof that he was the one who did the burning (e.g. used for reputation). With signing a nonce from the input for that tx he can additionally proof that he is was the originator of the tx once the pre-image was released publicly.
We could use for the initial list the voting and then to extend the "warmup phase" we can use fees.
I think a tool to get a deactivated asset re-activated again is important. Repeated voting might be one way but I think fees are easier and better here.
Bisq is dependent on tor for stable operations. This showed clearly during an attack on the tor network in December. Bisq was affected quite negatively with failed message deliveries causing quite a bit of trouble and extra work for arbitrators. This was exacerbated by the high and volatile Bitcoin fees at the time, but that's a different issue.
I propose to add the role of tor relay operator to support the tor network, to be compensated through the DAO. This might not stop troubles during attacks but it will add to the resilience of the tor network making it harder to attack in general.
Requirements on this role to be decided, but some considerations would be to require at least a certain uptime and bandwidth and to keep the software updated. In general keeping with the guidelines from the tor community should be expected. As an example I've been running a node for a few weeks, stats can be seen at https://metrics.torproject.org/rs.html#details/D4FBE51BC35C3921F31B6E561FD8C07BC56F9D71
It has been mentioned that this could encourage current tor operators to become Bisq tor operators to gain the BSQ reward. This could be seen as a problem in that it would add no benefit to the tor network but BSQ would be paid out. It would on the other hand bring in such operators to Bisq which could help with knowhow and more people within the project. I don't think it's likely to happen for now though, but should be kept in mind.
This is a "proof of concept proposal" that assembles a number of "in progress" modules into a modified application stack architecture. All modules work in a Regtest environment.
https://github.com/citkane/bisq-business
Slack: #business-logic
This presently has basic logic and methods to set up a bisq user, create offers and fulfill trade through to completion. It already works with bisq-engine to provide logic for REST endpoints, and awaits minor refactoring to some gui packages to become a drop-in provider there also.
https://github.com/citkane/bisq-engine
Slack: #engine
Business logic and further functionality drops into the shell by modular packing. Theoretically, it is possible to build any distribute-able, run-able jar purely from the POM and by providing correct REST interface classpaths to drop-in sub-modules.
https://github.com/citkane/bisq-front
Slack: #front
At the moment this is providing a web GUI to drive basic Bisq trading. This is just one usage, and the GUI needs to be factored out into a package of it's own.
it will further provide the security model for access control to the data stream and will be also be able to direct communication on localhost between Bisq and other third party logic, such as automated trading bots, automated payment API's or network reporting tools.
Given that, once the encrypted websocket is established, data transfer over TOR becomes use-ably fast as the connection is held open and TOR does not seek new routes until the connection is closed. This can be used to transmit both events and data.
With this in mind, and a bit of work to for bisq-engine to provide event broadcasting, the javaFX gui can be plausibly refactored to work as is as a remote thin client, or remain as an integrated desktop interface under ONE architecture and codebase. The road is now also open for mobile apps and web front-ends.
Related to a not yet published proposal (#52) for a bigger change of the arbitration system we might have the situation that there are no arbitrators anymore and therefor no receivers of the BTC trade fee. Once the DAO is launched there will still be trade fee payments in BTC as those who want to buy BSQ for the first time need to be able to do it in Bisq without the requirement of having already BSQ. Beside that we don't want to force users into buying BSQ for trading.
So if this new dispute resolution system will be implemented we will have the "happy problem" what we should do with the BTC trade fees (which goes to the arbitrators also after the DAO is launched).
Of course there would be many possibilities but one which migth fit very well to the spirit of the DAO would be that we donate those BTC to a receiving organisation which got selected by voting.
Lets assume someone suggests the Tor community as receiver. He makes a compensation request with the official BTC address of the Tor project and some explaination why he thinks that Tor would be a good candidate for receiving those funds. If it gets voted ok then this address will be used for receiving the BTC trade fee (the BSQ trade fee is burned and therefor distributed to all stakeholders).
Every month another receiver can be elected or if not the latest will remain.
I think that can build up nice synergies with projects where the Bisq community shares values and could be a first step in direction of a network of DAOs.
What do yout think?
This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.
Bisq users with an open trade need to keep Bisq running on their computer, but might be afk.
This Bisq proposal aims at providing a iOS and Android App that can receive notifications from the Bisq desktop app. The mobile Apps are not designed to ever evolve into a full Bisq node, but should rather serve as a remote control to the user's one Bisq node, which runs on his own computer.
moved here
This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.
ATTN @bisq-network/contributors: this is on short notice, but I'm requesting that everyone who plans to submit a compensation request review this proposal prior to our upcoming May voting round a couple days from now. See my more detailed comments about this at bottom. Thanks.
In this proposal, I want to draw a distinction between work that is IN PROGRESS and work that has been DELIVERED, and to make the case that contributors should submit compensation requests only for work that has been DELIVERED and that stakeholders should always vote to reject compensation requests for work that is still IN PROGRESS.
It means that the work in question has been made available to users. It means that users have the work in their hands (or can have the work in their hands at will) and can realize for themselves immediately the value that the work brings.
This is the same meaning of the word 'delivered' as it applies to a shipment from Amazon. If you order a pair of shoes from Amazon, you cannot realize the value of those shoes until they have been DELIVERED at your doorstep. Before the moment of delivery, you have realized NO VALUE, and after the moment of delivery, you are able to realize at will all the value those shoes can provide.
The same holds true for a bug fix or new feature in a given Bisq software component. Until there is a release of, say, Bisq Desktop available that includes that work, users cannot realize its value.
Furthermore, a user cannot realize the value of a given unit of work if they do not know how to use it or do not know it exists in the first place. This means that for work to be delivered, it must also be discoverable. In most cases, this means that the work must be documented and announced and/or promoted in some appropriate way, e.g. via release notes, Twitter, Reddit, YouTube, etc.
So, delivered work is work that:
NOTE: there are exceptions to the above, and I'll cover them in sections below.
Work is in progress up until the moment it is delivered. Discussions about the work, writing code to implement the work, submitting pull requests for and reviewing the work are all equivalent to that work being "in progress" from the user's perspective.
Even when a pull request has been merged to master, the work is still "in progress" from the user's perspective. Nothing matters to (the vast majority of) users until there is a release available to download and run.
(So yes, this means that I am proposing that no one gets compensated for their work until that work is actually released. Getting a PR merged is not sufficient. I'll talk more about this below.)
As we have discussed elsewhere, the amount of BSQ requested for a unit of work in a compensation request represents that contributor's best estimate of what their work is worth to Bisq and its users, i.e. it is an estimation of how much value that work adds to the network. It is NOT an estimation of how much effort that contributor put into the work. (Note that the latter can be a useful reference point, i.e. a way to come up with an initial estimate, but ultimately the amount of BSQ requested must be aligned with value it adds to users).
With this in mind, I present the following logic:
And from there it naturally follows that compensation requests for anything other than delivered work should be rejected by voting stakeholders.
At the risk of belaboring these points, I want to drive home why we need to do things this way.
First, with regard to requesting BSQ based on the value work provides to users instead of basing it on the time and effort the worker expended, just think about it from a Bisq user's perspective. As a user, you know that the BSQ you spend on trading fees essentially creates a transfer of value from you to the contributors who perform work that makes Bisq more useful and valuable to you. You do not want to pay for someone's time and effort, because that's not what is useful to you. You want to pay for utility! In many cases, the amount of BSQ requested in a given compensation request may be fairly close to what it would have been if it was calculated as a function of the contributor's hourly rate, but it's important to users' confidence in BSQ that we don't model it that way, and that we model it instead on the utility / value that work delivers. This way, users really feel that they're paying for the value they get, and not paying for a bunch of different people's arbitrary hourly rates. People's hourly rates can vary a lot with different geographic locations and other factors, whereas Bisq's fees do not vary between users at all. When we all work together in the compensation request and voting process to reach consensus on what work is worth to users, we eliminate the variability of individual contributors' skill levels, geolocation, etc. It greatly simplifies things, and makes it possible for us to build a meaningful, increasingly objective shared mental model of how much various kinds of work are worth to users over time.
Second, with regard to compensating only work that has been delivered, I argue we must do so, because if we compensate work that is in progress, i.e. not yet delivered, we are literally incentivizing contributors NOT to deliver. This is hugely important as we continue to grow. The bar must be set HIGH for compensation. What you're working on must be shipped, delivered software, sitting in users' hands, actively delivering value in order for you to get compensated for doing it. If we do anything less, than we will begin compensating untold numbers of projects that will wander off into the woods, never ship, and never add value. This too will quickly erode user confidence in BSQ and will put all our efforts at risk.
We must incentivize what we want, and dis-incentivize what we don't.
What we want is software shipped early and shipped often, such that it benefits from lots of feedback and continuously delivers new value into users' hands.
What we don't want is long, meandering efforts that never ship or ship only after a long time, without the crucial benefits of early feedback and validation.
The proposal above to compensate only work that's been delivered and to reject compensation requests for work that's still in progress puts the incentives right where they should be to realize these goals.
I should mention here that in large part we've already been operating this way, i.e. that many if not most compensation requests have been requests to compensate delivered work, and where they haven't been, that's OK. We're figuring things out as we go, and assuming we have consensus on and enact this proposal going forward, there is no problem with the fact that we've been compensating some in-progress efforts up until this point. What matters is that we correct course as soon as we see that we need to. That's what this proposal is about.
There are two main examples of compensating in-progress work that I want to call out here:
@mrosseel's HTTP API work. This is now getting close to an initial release, but for all the reasons above, until it is released, in users' hands, and accepted into the @bisq-network GitHub org, we should hold off on any further compensation.
@ManfredKarrer's BSQ / DAO implementation. I imagine everyone will agree with me when I say that this is the most important work we have underway, but until its initial production release, it is adding no value to users and we should therefore hold off on any further compensation.
By contrast, the work that @blabno and co have been doing on bisq-mobile has not yet been released, has not yet added any value to users, and no one on the team has requested any compensation for that work yet. This is a good example of how it should be. I am a bit concerned at just how much work is being done there without early feedback, and I would have preferred to see a more minimal v0.1.0 that could get validated by users, but I trust that @blabno and co understand the risks they are taking by investing this much time and effort prior to an initial release, and they are free to manage their efforts in any way they see fit.
It's worth mentioning here that contributors may sometimes want to hold off on an initial compensation request for their work even after they have released it, in order to gather initial feedback, build up an initial user base, and to clearly demonstrate the value of the work they've done. If for example, a contributor builds a brand new Bisq component, ships a v0.1.0 release of it, and immediately requests compensation for that work, it may not be obvious to voting stakeholders what the value of that new component actually is to users, because users haven't had any time to use it yet. If instead the contributor ships v0.1.0, gets initial feedback, folds that feedback into a subsequent release or two, and collects various metrics along the way to demonstrate that the component is in fact being adopted, is in fact of value to users, it will be that much easier and that much more objective for the contributor to request a given (possibly higher) BSQ amount for that work.
So while this proposal sets delivery as the standard for when work becomes eligible for compensation, it remains at the contributor's discretion when after that point they choose to submit a compensation request. Generally speaking, the bigger, more ambitious and more uncertain a unit of work is, the more the contributor will benefit from introducing a gap between the initial release of that work and their initial compensation request for that work. The contributor is putting their time and effort at risk by doing this, but they increase the chances of that risk resulting in a significant payoff because they allow themselves time to incorporate feedback and to find a product/market fit for their work.
Contributors who are more risk averse and wish to be compensated more promptly for their efforts should in general shy away from bigger and more ambitious efforts, and should focus on delivering smaller units of work that have a higher degree of certainty as to their value. For example, bugs that everyone already agrees are important to fix, or other minor, non-controversial improvements to existing components.
So far, I have focused on development contributions. This has been intentional, because in the end, the most important kind of contributions to Bisq are software-related, but the proposal that we should compensate only delivered work applies equally to all kinds of contribution under the Bisq DAO.
If for example, you are a forum moderator/administrator, you are delivering value to the network every time you respond to a user post, every time you create a backup, etc.
If you are a YouTube Administrator, you are delivering value every time you upload and categorize a video, etc.
And so forth for all the many different non-development roles under the DAO.
I wrote above that "delivered work is work that has been released, documented and announced/promoted". Those terms are strongly connoted with development work, but they map onto non-development work just fine.
When you perform some valuable function, like answering questions on the forum, that is the moment of "delivery". Your work has, so to speak, been "released" when you click the submit button. It is "documented" and "discoverable" in the sense that your answer is there for everyone to see in future search results, and it is "announced" or "promoted" in the sense that an email notification has been sent to the user you were responding to. I realize that it's a bit contrived to map these things in this way, but I think the exercise is worth it. The point is that we should always be evaluating work on the basis of whether it has really been delivered to the intended user(s) in such a way that they can actually realize its value. If you stay true to that principle, I think it's pretty easy to determine whether a given compensation request represents delivered work or work that's still in progress.
Not everything needs to be documented in the sense of updating a manual. If you fix a bug, you don't need to update the documentation, because the definition of a bug is that some component is behaving contrary to its documented / advertised behavior. In the case of bugs, the bug report and the commits that fix it are the documentation. Bug fixes of a certain magnitude should still be announced via release notes, however.
"As a contributor, I control my work up until the point that it gets merged by a maintainer. If I can't submit a compensation request for that work until the a maintainer ships a new release, then I might wait a really long time to get paid! This is unfair, and that's why I think we should consider a merged PR to be a delivered PR."
This was how I thought about things until recently as well. I think I'm even on record in a live stream saying something very similar to the above. I've changed my mind, though, and again it has to do with aligning incentives.
The premise of the concern above is that maintainers might take a long time to ship the next release of whatever Bisq component it is that you've contributed to. This of course may happen for any number of reasons, but what we should be striving for as an organization is to release new versions of Bisq components regularly and often. We often say that our goal with Bisq Desktop is to ship roughly once a month. We don't want to ship much more frequently than that, because it can become burdensome and irritating for users to deal with frequent upgrades, and we want to avoid the situation where they get desensitized and start ignoring or indefinitely deferring upgrades. We also don't want to wait too much longer than one month, because that's just a very long time to wait to deliver important new functionality and bug fixes to people. In any given month, there is almost always some fix or feature implemented that is really worth getting into people's hands. And a monthly release cadence is furthermore ideal because we submit and vote on compensation requests once per month, too. So when we hit this release cadence, we eliminate the situation where contributors are left with an "unfair" gap between getting their work merged and getting compensated for that work.
But let's assume for a moment that, for whatever reason, we're NOT hitting that release cadence. That Bisq Desktop releases are sporadic, that sometimes months are going by without a release, and that in turn, contributors are getting frustrated and restless about it. This is a GOOD thing, because it puts direct peer pressure on maintainers to get their shit together and start shipping more regularly once again.
Users want regular releases because they want regular delivery of ever more useful software into their hands. Contributors want regular releases because they want regular compensation for their work. Maintainers want regular releases because they too want regular compensation for their work, but also because they want to avoid unhappy contributors and unhappy users. This is what I mean by aligned incentives.
Of course there can always be extenuating circumstances that throw release schedules off course, but over time, these should be the exception, and everyone should be prepared to deal with those problems as a team, to pitch in to get things back on track, and to do whatever it takes to keep the machine running smoothly.
We DON'T want a culture where contributors get their work merged, get paid straight away, and then have no further incentive to see their work get into users' hands.
We DO want a culture where everyone has skin in the game, and no one gets paid until users get value.
Getting this stuff right as early as possible means building the strongest foundation possible for BSQ leading up to its production release. I think it will matter a lot to users to know that we've gone through these kinds of deliberations and that we've established high standards for what gets compensated. I think it will be powerful for people to know that every BSQ earned is equal to value being created and that every BSQ burned is equal to value being consumed.
I had intended to write this proposal immediately following our Apr 4th–6th voting round in order to give plenty of time for consideration and discussion, but as it turns out, I am submitting it now, just a couple days prior to our scheduled May 1st–3rd voting round.
I'd appreciate it if everyone could take the time to review this before submitting their compensation requests, such that we can be aligned on this topic as soon as possible. If we have a clear consensus among the 6-8 contributors who have been regularly submitting compensation requests over the last months, then everything is easy and we can just move ahead with this proposal. If it's not so quick and clear, that's fine too; I don't want to rush anything. In that case, we can move ahead with compensation requests and voting as per the status quo in this next round, and we can let this proposal mature over the next two weeks as per the usual process.
Thanks, everyone.
For the last few months, myself and now several other contributors including @ripcurlx, @alexej996 and @mrosseel have been writing monthly report comments on our respective role issues.
Here are some examples:
I am proposing here that every primary role owner write a monthly report comment on the role(s) that they own (see #12 regarding the distinction between primary and secondary role owner).
The reasons for this are several:
These reports are a great way to share information with other contributors and with the Bisq community at large about the things you're responsible for. Anyone can click the "Subscribe" button on any role issue (or indeed can Watch the entire bisq-network/roles repository), and get regular updates about whichever roles they care about. This is a fundamentally scalable approach to information sharing.
These reports serve as a basic kind of "heartbeat" message from role owners, letting the network (of other contributors) know that they are in fact on top of their duties, or at least that they are not obviously derelict in their duties. If there is nothing to report on a given month, just say "Nothing to report". The important thing there is that you are reporting in the first place, and in doing so, letting folks know "all is well with this role" (and that you should indeed be compensated for performing the duties of that role).
Doing reports this way makes compensation requests easier to write and easier to evaluate. Where roles are involved, compensation requests should consist of nothing more than a set of links to monthly role updates. For an example of how this looks in practice, see my own compensation requests, e.g. bisq-network/roles#57 and bisq-network/roles#40. This way, you can say as much or as little about your roles as you like in the monthly reports for each, and then simply link to that report comment from your compensation request. This makes it easier for stakeholders to evaluate compensation requests during voting as well, because they know that compensation requests are mostly "thin" documents consisting of links to more substantive reports that follow a common format. This way we don't have to parse every contributors different, idiomatic approach to writing compensation requests.
So, to re-iterate: I propose that every primary role owner start writing monthly report comments starting with the next round of compensation requests that we will vote on from May 1–3rd.
If we have a rough consensus on this proposal by that time, I will vote 0 for any proposal that does not include monthly report comments in May, and I will vote -1 for any proposal that does not include them in June and beyond.
Also, I propose we continue with the format that has emerged for these comments, which is as follows:
## 2018.03 report
[primary role owner's notes, observations, data as they see fit]
/cc bisq-network/compensation#42
Where the date obviously changes with each month, and the linked compensation issue is that role owner's current (draft) compensation request for the month. You can see the effect that this kind of round-trip referencing has between roles and compensation requests by looking at my request for this month at bisq-network/compensation#57.
I wanted to get this proposal together now, just as our May voting is finishing up, so everybody has plenty of time to consider it prior to the next voting round. Thanks, all.
(See also this month's Roles Maintainer role update, where I first suggested that we institutionalize this process of writing monthly updates: bisq-network/roles#28 (comment))
The current fee model seems to be hard to understand for many users.
See current fee model formula: https://bisq.network/faq/#6
We could omit the minFee and the market distance factor. This was intended to get a mechanism for protecting against too many far distance offers but in reality we don't have that problem now. We can change the fee model later once we would run into such problems. There is some flexibility built in and changing the fee model does not break the trade even if both users have different versions.
So I suggest to use only a fixed percentage based fee. E.g. 0.2% of the trade amount. That is easy to understand for everyone and the other alternative to have a flat fix-price fee would have the disadvantage that it is too expensive for those who want to do a small-value test trade and those would get a negative impression of Bisq.
I am not 100% sure if that is a good idea and it would require a bit more of thought to be sure that updating the fee model does not have compatibility issues, but as we did that already in the past it should not be a big issue. Worst case we need to wait a few version updates until the deployed model gets activated and old versions might get failed trades - a sign that its time to update then...
Another reason why I am considering that change is because the current fee model uses a fixed BTC value and that does cause problems when BTC price is very volatile. % based fee will go with the BTC price so we don't have the need to adjust the fee over time.
That will make it also easier to support it in the DAO parameters (fee can be changed by voting).
Please share your though about that if it would make sense to change the fee model.
I'm opening the conversation about the tagline of Bisq here on GitHub.
Carrying it over from Slack it’ll allow for time to review and reflect as well as to bring other people into the conversation.
The issue will be the place for brainstorming and proposals.
Current Bisq tagline: "The P2P Exchange Network"
We use BitcoinAverage for Fiat market prices and Poloniex and CoinMarketCap for altcoin market prices. The price data are requested by the price-nodes from those services and Bisq nodes are requesting via http over Tor the price data from our price-nodes.
We have an open vulnerability for single point of failure in case BitcoinAverage would fail (happens once in the past) as most Bisq offers are using percentage based prices and therefore are dependent on price data.
To a lower extent that is the same for altcoin prices but as we have 2 service providers (Poloniex and CoinMarketCap) it has already a bit more resilience.
Furthermore it comes with a security risk as in case the price provider would deliver wrong data, price based Bisq offers would be taken with that wrong price.
We would like to have more resilience for those price feeds, so in case one of the services fail or deliver incorrect data the Bisq users are not affected.
It is not intended to offer that service outside of the context of Bisq.
We should implement basically our own lightweight version of BitcoinAverage. Collect price data from the top 5 exchanges and apply a similar weighting algorithm as used in BitcoinAverage on each of the sources to get an average price.
Use national currency exchange rates to convert it to other currencies.
We should try to get in that way a similar result to what BitcoinAverage delivers and then we could mix both services to get the price for Bisq users. If one of the sources deliver very different prices it should be filtered out and the maintainers should get alerted to investigate the issue.
For altcoins we could do something similar or find 1 or 2 other price providers so we get more resilience.
The service could be added to the price-nodes or run as separate service and the price-nodes consumes that service (could be on the same host machine).
It does not require special Bisq or P2P network knowledge so it should be easier to find a developer who can work on that.
When the Phase Zero doc was originally written, I laid out a requirement that each role—or at least each bonded role—must have a role specification similar to the one I put together for the Twitter Admin role at https://github.com/bisq-network/roles/blob/master/twitter-admin.adoc. And you can see how that specification is linked from the Twitter Admin role issue description at bisq-network/roles#21.
Here's the thing though: no one else has written any role specifications since then, and I haven't made it a priority to enforce this rule. After 6 months of operating the Bisq DAO under Phase Zero, I think it's safe to say that we're getting by just fine without these specifications for now, and I am therefore proposing that we remove this rule from the Phase Zero doc, and remove the TODOs in each role issue description.
At least for now. As things progress, and as we exit Phase Zero, especially as BSQ becomes real and bonding means that role owners have real skin in the game, it will probably makes sense to have Git-controlled role specifications like I originally laid out. In the meantime, though, I propose that (a) keeping role issue descriptions up to date and (b) doing monthly role owner report comments as described in #13 is enough.
If you agree, please give this a 👍 below, and (assuming consensus) I'll do the following:
specification column from the roles repository READMEThis is a Bisq Network proposal. Please familiarize yourself with the submission and review process.
This proposal writing was suggested by @ManfredKarrer after a short exchange on slack.
Listing fee policy is imo important for Bisq.
Up to now, free listing has been the rule, see https://docs.bisq.network/exchange/howto/list-asset.html
Bisq has more than 130 altcoins listed (https://bisq.network/faq/#altcoins), which costs Bisq BSQ, dev time, promotion time (and reputation).
(Actually, Bisq does promotion for altcoins ... while altcoins do quite few promotion for Bisq).
If we look at the statistics on several months (see https://docs.google.com/spreadsheets/d/1o-I5fAx7DJRVqYjW8fPbo0ztlGIhIZ1EM2iLc5aEHnA/edit#gid=1000435171) there are less than 10 altcoins having effective trades.
And ~80 altcoins having day after day simply absolutely no offers at all.
Not only does this lead nowhere, but it doesn't help conveying the image of a dynamic market place.
(For a (too) big part of the listing, it looks more like a kind of an altcoin cemetery. Imo it has a negative reputation effect.)
Considering this situation, this proposal has as object to change the current listing fee policy.
The proposal as a whole, if we accept the proposed directions, will need to go into technical details.
However, I don't want to mix general direction with technical details and numbers, so I proceed here with a first simple an general proposal.
If there is no consensus for the general direction, no need to propose technical details.
So here are the first suggestions :
1/ I suggest that Bisq continues to apply a "no politics" rule for listing altcoins.
Listing/unlisting should be only a matter of numbers.
This means also that the same rule should apply for all altcoins.
2/ End free listing :
By asking nothing in order to be listed, we encourage numerous altcoins communities to just do the listing job ... and absolutely nothing after this point.
Listing process ended, there is no incitative for the altcoin promoter to do anything on Bisq.
By asking some fees, maybe even very small, we could stop this "list me and see me never again" attitude.
Asking some fees should help the concerned altcoin community to think about doing something on Bisq in order to help to generate trades.
And this will be positive for everybody.
Listing may still continue to be free for a limited time, under certain conditions.
But free listing forever policy will end.
If there is consensus about those simple general lines, I can deepen things in a next proposal.
The goal being however to have a proposal having in mind to do things as smoothly as possible and avoid also massive and/or brutal unlisting.
This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.
I can help with Hungarian (Magyar) translation
This follows a discussion we had in #dev last couple of days, especially with cbeams.
The idea is to finally provide some sort of mobile application for Bisq, starting super easy
with an app that does nothing more than communicate with the user’s full Bisq node running on the desktop and give them status updates about their offers.
TODO (Android, IOS, JS, whatever):
How to achieve that: using Kotlin multiplatform support
Where we have all the common logic in a common module and then each platform would have its own implementations.
Anyway, we are looking for feedbacks, suggestions, tips.
If there is anyone willing to collaborate, don't hesitate and jump in.
Situation so far:
I started by trying to implementing/experimenting Tor on the desktop JVM, using the netlayer library, but since I got some problems with native dependencies I cloned it and implemented Gradle. That worked, but I found other further issues.
Also, I think to set 21 as minimum android-sdk version
In a discussion with the same friend who set the seed for the account age witness idea we came up with a new idea how to protect Bisq users against stolen bank account chargeback scammers.
We want to add additional protection to the existing protection from the account age witness to mitigate the risk for cases where a stolen bank account scammer has relative low amounts on the stolen account he wants to cash out as the account age witness method does not provide protection for those cases (e.g. amounts below 0.0625 BTC or about 400 USD with current exchange rate). The limits in the account age witness are also harder to change, so in case of a fast BTC price increase the limit in the fiat currency is getting rather high as well and with that it is lowering the protection provided from the account age witness feature.
Our suggested feature for a "certification for ownership of a bank account" is optional and provides additional security if a user chooses to select an offer of such a "certified" Bisq trader or that he decides at his own offers to only accepts BTC buyers as taker who have been certified. The feature is only relevant as protection for the BTC seller as the scammer would be in the role of the BTC buyer.
##Assumption:
A scammer who is in possession of a stolen bank account has only the online banking access but he does not has the physical ATM card nor can he go to the bank branch to withdraw money from the stolen account as at the bank counter he would need to show his ID for verification.
We could use both methods to get a proof that a user is the valid owner of the bank account by requesting the user to withdraw a specific amount to himself using one of those 2 methods.
##Description
We add 2 methods how Bisq users can verify the ownership of their bank account. The user can choose any of the 2 methods, whatever is easier and more convenient to him.
The user goes to a local bank branch and withdraws a predefined fractional amount (e.g. 23.45 USD). He keeps the paper receipt and as soon the withdrawal is visible in his online banking statement he requests from the arbitrator a verification (inside Bisq via a new UI feature). The verification will be done via PageSigner. If PageSigner would not work with the users banking webpage other verification methods are used (e.g. video screen sharing). A scan from the paper receipt can be requested from the arbitrator as well.
The user goes to a ATM and withdraws a specific amount (multiple of 10 in a range of 20 -100 USD) and takes the ATM paper receipt.
As soon he sees that transaction in his online bank statement he requests a verification from the arbitrator as described above.
The amounts are derived from the bank ID (IBAN/BIC,...). The result gets mapped to either a fractional value between 20 and 100 USD (e.g. the national currency the account is based on) or a multiple of 10 between 20 and 100 USD. That specific value generates a kind of fingerprint which makes it very unlikely that a scammer by chance could get such an amount displayed in the transaction history from the victim doing a bank withdrawal by themselves.
The amount for the ATM amount need to be a multiple of 10 as most ATMs do not support smaller amounts. The min. amount will be 20 EUR as most ATMs have that as minimum (need a bit more research if that is correct). The max. amount is 100 EUR (could maybe also be lower like 50 EUR).
There will be a button at the bank account payment method where the user can request a verification. The first step is that he gets the requested amounts for bank branch version and ATM version. He also gets instructions what he need to do.
After withdrawal and as soon he sees the statement in his online banking transactions history he goes back to the bank account payment method and clicks another button to contact the arbitrator for requesting a verification. That will open a support ticket similar like a dispute case. There he will provide a PageSiger document to verify the transaction or in case that PageSiger is not working an alternative method decided by the arbitrator will be used. In case the arbitrator does not get convinced he can reject the request.
Once the arbitrator has done the verification a signed certificate from the arbitrator will be published to the P2P network and gets matched to his payment account in a similar way we do it for the account age witness.
Any maker of a sell BTC offer can decide to accept only BTC buyers as taker who are certified. For a buy BTC offer it does not make sense to add that option. The restriction option is stored in the preferences and will be remembered and auto-set to the latest selected value when creating another offer.
At the offer book a special icon (with tooltip info) will indicate such offers which require a certified BTC buyer. Not certified users cannot take that offer and will get it displayed greyed-out with an popup when clicking on it which displays context information.
When a certified user is creating an offer his offer will carry a flag to indicate that he is certified (using an entry in extraDataMap in OfferPayload). The validation will be done as part of the trade protocol (see blow).
At the offer book a special icon will indicate such offers where the offer maker is certified.
Even the certification is only relevant in case the maker is the BTC buyer we can show it in both cases to avoid confusion to users who don't fully understand the concept.
There is no restriction that a maker requiring certified BTC buyers need to be certified by himself.
The arbitrator will get the requested amounts displayed in the request ticket in a new UI screen similar to the existing disputes list. The request carries the users payment account data so the arbitrators application can calculate and verify the requested amounts and display it to the arbitrator.
After verifying with the provided PageSigner doc (or alternative methods) that the withdrawal was done the arbitrator confirms and with that he signs a certificate that the payment account with the specific data has been verified with the withdrawal of the requested amount. The application is publishing that certificate data to the P2P network. The user will see in his payment account that it is now certified.
The arbitrator publishes his signed certificate to the P2P network using the hash of the bank ID as key and the arbitrators EC signature of that hash together with the arbitrators index in the pubKey list as value stored in a hashmap.
hash = RIPEMD160(Sha256(identifying bank data, e.g. IBAN+BIC)) -> 20 bytes
signature = sig(hash, EC key) -> 71-73 bytes
index = Index of public Key in hard coded list of arbitrators keys. Index is represented as a single byte.
Hashmap:
Key: hash
Value: index concatenated with signature
The data size of the hashmap for 100 000 certificates would result in 9.2-9.4 MB. As that data is stored at all nodes and all users can have multiple certificates we have to be careful to keep the data footprint low.
A solution to avoid persisting the signature at all is that the signature check is done at storage time and only valid signatures lead to persisting the hash in a persisted list. That would require only 20 bytes per payment account certificate and also avoids repeated signature checks.
With that model we have a data size of 2 MB for 100 000 certificates which seems a pretty low footprint.
So the published data from the arbitrator contains both hash and signature but the persisted list only gets filled up with hashes after the signature of the data item has been verified.
All Bisq users will receive those certificate data items and they can see if a specific payment account has its hash already in that list.
With that model we can support also the cases when an arbitrator has left as the hard coded list of arbitrator pubKeys will not change.
Similar as with the account age witness the taker cannot verify a makers certificate before actually taking the offer as only in the trade protocol the peers account data are exchanged. But that is not a problem as a maker who used a fake certificate in his offer would get rejected in the take offer process and loses his maker fee as the offer got taken but has failed.
The arbitrator will play an additional critical role by collecting all the bank account data of the certified Bisq users.
The implementation will auto-delete those data after the certification is published but once the arbitration system is fully decentralized we should consider to decouple that role from the arbitrator and leave it to very few operators with high reputation who are trusted to not violate that promise to delete the data (not modified the software).
But ultimately that is a critical problem where not good solution is known.
It would make sense to separate the role from the arbitrator even if the persons doing it are carrying out both roles. That topic is subject for discussion and will require a bit more analysis to estimate the effort for separating the roles.
We should find a good term for the feature. Certification or verification might lead to confusion with KYC style verification.
Content wise the best description IMO is that it is a "proof of bank account ownership".
Any suggestion for a clear in-ambigious term is highly welcome!
Basically by proofing account ownership we would use the verification data also as anchor to a real life identity of the user. E.g. in case of a scam committed by that user the payment account data could be used to identify the user and use that for legal steps against him.
But that model would have several problems:
For those reasons it is not intended to extend the suggested feature to such a broader model.
UPDATE:
From the discussions below we found a more privacy protecting model:
The account verifier (arbitrator) will only receive the bank name and hash. He will use a screensharing session instead of PageSigner as most banking webpages reveal bank ID and/or name on the transaction history page. In the screensharing session the user is instructed to only reveal the transaction which shows the withdrawal with the requested amount. Furthermore the bank name (address bar) must be visible.
The hash will be created from the bank ID + a persisted salt to avoid that the bank could find the hashes of their clients.
The verification will be done by the trade peer in the trade protocol where he checks if the hash is correctly derived from the bank ID.
Probably we use additional 2 or 3 relevant digits of the bank ID to reduce the chance that a scammer could trick the system in case he has a own bank account at the same bank as his stolen account.
So that data would be added in the verification process. We will specify that in more details once the basic idea of the proposal gets accepted.
With that modified version the verifier will not learn any identifying data of Bisq users.
The only open issue is that the amount (in case of bank counter withdrawal) is kind of a finger print and banks could theoretically spot such clients as potential Bisq users. Though that has a big risk for false positives for them. If they would get the verification data from the verifier they could identify a client to a Bisq user with it's onion address and it's verification hash. Though a Bisq user can change his onion address when starting a new data directory (as well there is an open issue to support that in the UI).
The Phase Zero plan in its current form prohibits the sale of BSQ as a strategic measure to mitigate what the plan refers to as valuation risk and control risk, defined as follows:
From https://github.com/bisq-network/docs/blob/master/dao/phase-zero.adoc#how-phase-zero-mitigates-risk:
To address valuation risk, we eliminate the possibility of trading BSQ during Phase Zero. A fair market value for the token must still be established in order to compensate contributors, but this value can be estimated initially and then adjusted throughout Phase Zero. On completion of Phase Zero, the value of BSQ will become entirely subject to market forces, but the fact that many contributors worked throughout Phase Zero at a given fair market value should provide a stronger price foundation for BSQ than would be present if we were to simply enable trading from day one.
To address control risk, we ensure that only those who have contributed value to the project are able to vote during Phase Zero. This, too, is a result of prohibiting BSQ trading: because the only way to acquire BSQ during Phase Zero is to earn it, it becomes impossible to simply purchase voting power. Furthermore, it gives us time during Phase Zero to design and implement a longer-term solution for control risk in which we introduce a reputation factor into the BSQ-based voting process.
Not written in the document explicitly, but also true, is that by prohibiting the sale of BSQ, we also helped avoid a form of censorship risk. With no token available to the public, there is no way we could be seen as engaging in securities fraud, and therefore could not become the target of any related enforcement agency.
The prohibition on sale also helped distinguish very clearly that what we are doing with BSQ and the Bisq DAO is not an ICO.
So there are many good reasons why we put the prohibition in place. And it's with this in mind I propose we introduce the ability for individual contributors to privately sell the BSQ they have earned during Phase Zero thus far.
We're now entering our 6th month of Bisq DAO operations under the Phase Zero plan. Phase Zero has no estimated end date, it only has exit criteria. We did state in the document, however, that Phase Zero would last at least 6 months. Given that we're at the 6-month mark, and we're still at least a few months away from hitting Phase Zero exit criteria, now is a good time to review this matter.
During the last 6 months, a number of Bisq contributors have worked steadily on Bisq, and have been compensated in BSQ for those efforts, but have otherwise had no liquid form of compensation. For most contributors, such a situation can only go on so long—at some point, savings run low and one needs to pay bills.
It is excellent that contributors have worked in an equity-only fashion during these 6 months. It is a demonstration that Bisq and the Bisq DAO are something that contributors believe in and are willing to take considerable risk for to realize in the world. It is one thing to say these things; it is another thing entirely to work for months without (spendable) pay for them.
Another factor contributing to the creation of this proposal is that we are in fact getting requests from serious buyers about BSQ. A number of contributors have reported being approached by people they know who, given the opportunity, would buy their BSQ. I have also personally seen an uptick in these inquiries over the last weeks. So it is reasonable to predict contributors will actually have buyers to sell to.
The obvious benefit is that individual contributors will now be able to manage how much BSQ they hold vs how much they liquidate according to their own needs, risk tolerance and time preference.
Another significant benefit is that through the process of individual contributors privately selling their BSQ to other individuals, we will be able to engage in a slow and controlled process of price discovery for BSQ. Our current working valuation for BSQ is 1 BSQ == 1 USD, and while this figure was the result of quite a lot of deliberation, there is no way to know a priori whether the market will agree with it. As we approach exiting Phase Zero, it will be very good indeed to have actual data informing us about what the market value of BSQ may be.
I've addressed valuation risk immediately above. Prohibiting BSQ trading at the start helped us mitigate valuation risk while BSQ was utterly untested and the Bisq DAO was brand new. Permitting trading now can help further mitigate valuation risk by helping discover what the market price actually is. After 6 months of road testing BSQ and the Bisq DAO with contributors, I believe this is a reasonably prudent thing to do.
On control risk, the question is whether buyers of contributors' BSQ will be able to vote with it during the remainder of Phase Zero. I am of two minds about this. On the first, I think these buyers should not be allowed to vote, in the name of keeping the Bisq DAO fully meritocratic throughout the remainder of Phase Zero at least. On the other hand, the nature of the way in which we are proposing to make this change (see below) is such that the only buyers will likely be those people who understand Bisq very well, know contributors personally, and are willing to deal with very significant risk around BSQ. If buyers do in fact fit anything like this profile, I would have no issue with them voting. Indeed, because they are engaging so early in the process, and providing a valuable early price discovery service to the DAO, I would go so far as to say that these new BSQ stakeholders are Bisq DAO contributors, and therefore should have voting rights by definition.
On balance, I am for allowing buyers to use their BSQ to vote, with the proviso that we may change this decision at any time, such that anyone who already has voting rights will keep them, but new buyers after a certain date cannot use their BSQ to vote. I mention this just as a contingency.
Thus far I've talked only about contributors active during Phase Zero being able to spend the BSQ they've earned during Phase Zero, and that's been intentional. I propose that we limit sellable BSQ only to that BSQ which has been earned during Phase Zero, at least initially. This conservative approach will let us see how it goes with a small number of clearly dedicated contributors before opening things up more widely to many dozens more past contributors. Indeed we may not open it up further at all before exiting Phase Zero.
This conservative approach helps mitigate control risk, because only a relatively small number of BSQ can be sold (currently ~300K out of a total 2800K supply), and it also helps mitigate the above-mentioned regulatory / censorship risks, because with such a small amount being on offer from such a small number of contributors only and ever engaging in private transactions, it would be more difficult to cast this behavior as a 'public offering'.
I propose we do the simplest thing that could possibly work:
Also, we should put together a short list of risks that contributors should make very clear to buyers before any transaction. Buyers must understand the nature of BSQ, the nature of the Bisq DAO and must understand how early in this process we still are. There is a high degree of risk here, and absolutely no guarantees. Any transaction is 100% between contributors and their buyers. Beyond the verification mentioned in (2) above, there will be no duties performed by any Bisq DAO bonded contributor related to these sales. There may be other things of this nature that we want to add to a list of caveats. Please think about this and add to the list as you see fit.
If there is a clear consensus among active contributors, there is no need to put this to a formal BSQ vote. Please give a thumbs up or thumbs down to this issue description and add comments as you see fit. Afterward (assuming consensus), I will go ahead with the changes to the Phase Zero doc described above, and starting next month, individual contributors may add new lines to the bottom of the stake and voting spreadsheet as described above.
/cc @bisq-network/contributors
@HysMagus commented on Fri Mar 16 2018
Subject: Creating A Specific Bug Bounty Program With Clear Terms to assist in a clear and easy process for the payment of bounties
Summary: Having a bug bounty program with clear guidelines, easy to report process, and set limits of rewards.
Reasoning: Bisq is an amazing exchange network, and building a clear responsible disclosure system with set budgets for the report of specific types of vulnerabilities will make situations such as #1457 less likely to occur as there is not only a clear budget which the disclosure will be limited under but the system can require that the bug be disclosed prior to rating to ensure that you aren't paying 10 BTC for a minor situation.
Options:
For my own businesses, I use sites such as Hacker One and inbuilt custom forms using sites such as Form.IO (they are on github).
It is my understanding that since Bisq is a P2P exchange network, there might be a preference to have this system a little more decentralized. So a possible solution is to create a pseudo ticket system, similar to the current arbitrator UI that exists currently) on the platform with clear reward ranges. In this scenario the people notified would be the people who are notified in any situation.
What differentiates this from just having an email address, is existing price ranges depending on the severity of the bug and clear methods with specified locations to submit this information.
What do you guys think?
Note: This is my first time making a issue on Bisq and I would just like to say that everyone in this community is Awesome!
The topic message of #bitsquare has now been saying for a few months that we will move to #bisq, and a fair number of people have done so already.
Now is the time to do the actual move.
Goal: activate redirection of #bitsquare to #bisq at the end of this month: 30/04/2018
Necessary actions:
https://epir.at/2016/06/26/redirecting-freenode-channels/
Issue:
Only the channel creator can perform these commands, so I will need the help of @ManfredKarrer
Proposal:
I propose that Manfred agrees to this transition + its date by commenting on this issue, and I will ping him at the end of the month to actually perform the redirection.
In the meantime the topic of #bitsquare should mention the actual redirect date.
As discussed in #45 I will propose here the periods for the DAO phases. Additionally I would use that for suggesting BSQ fees for proposal and voting.
Phase duration is initially hard coded but can be changed via DAO voting. I would prefer though to use that option only if really required and to get it right from the beginning. We collected some experience with the manual process over the last year so we can assume that a months cycle is reasonable.
Note that 1 day is roughly 150 blocks (real average time is about 9.35 min). We cannot sync with calendar dates but if we use even numbers and start the genesis block on a even number (if we get it mined, but with high fees that should be doable) we stay in a grid with migth be easier to remember.
The breaks are required to avoid problems with re-orgs and should be at least 10 blocks. I think the longest re-org in Bitcoin was 4 blocks. The BREAK1 might be longer as it can serve as a review/discussion buffer for voters (proposal cannot be changed anymore.
PHASE_PROPOSAL:
Here proposals can be submitted and removed. Editing is not supported but removing and re-sumbitting has the same effect.
Suggested duration: 3600 blocks (about 24 day)
PHASE_BREAK1:
As said that break can be longer to add some buffer for discussions/reviews.
Suggested duration: 150 blocks (about 1 day)
PHASE_BLIND_VOTE:
As said that break can be longer to add some buffer for discussions/reviews.
Suggested duration: 450 blocks (about 3 days)
PHASE_BREAK2:
For reorg protection.
Suggested duration: 10 blocks (about 100 min)
PHASE_VOTE_REVEAL:
Here the voter need to be online so that his app can publish the reveal transactions which reveals the secret key for the previously published encrypted votes.
Suggested duration: 450 blocks (about 3 days)
PHASE_BREAK3:
For reorg protection.
Suggested duration: 10 blocks (about 100 min)
PHASE_RESULT:
This triggers the result calculation. We don't need more then 1 block as it is just a trigger but to stick with even number I suggest 10 blocks. There are no re-org issues here as no new transactions have been created.
Suggested duration: 10 blocks (about 100 min)
The total cycle would be then 4680 blocks which would be about 9.36 min/block if we use the minutes of a average year (525 949 minutes / 12 month = 43829 minutes -> 43829/4680=9,365 min/block which fits nicely to the rough average). But as said above we should not intend to stick with calendar months otherwise we will end up to be always slightly off which is probably worse than having our independent cycle.
Proposal fee:
To avoid spam we use a fee for submitting a proposal. If a proposal is removed the fee is lost and by re-sumbitting it it need to be paid again. The fee can be changed by DAO voting.
As the fee is defined in BSQ it is subject to BSQ volatility and might require adjustment over time.
As we want to incentivize also small contributions we try to keep the fee low.
Suggested fee: 2 BSQ
Vote fee:
Again as spam protection and to have a regulatory elemente to make voting more expensive if we get too many voters who are not well informed but see voting as "fun" we use a fee here as well. As it can be expected that we will not have both of the mentioned problems we can start also with a rather low fee.
Suggested fee: 2 BSQ
Note: In case of changes by voting there will be a max. ration for the allowed change. It is not defined yet but might be max 4 times in both directions. E.g. a 4 BSQ fee can be changed in one cycle only to max. 1 BSQ or 16 BSQ. But it can be repeated so next cycle it could be 0.25 BSQ or 64 BSQ.
Related to #46 I want to put here further proposed DAO parameter default values for discussion.
DAO parameters have an initial default value and can be changed by voting to a new value. The new value will become active in the next DAO cycle, starting with the next proposal phase.
There will be validations and rules how which parameters can be changed to make sure that parameters cannot be changed to invalid values (e.g. negative values) and to avoid too radical changes. This validation is work in progress and not fully implemented.
Any developer who wants to help here is welcome. That is a very isolated part of the DAO which is easy to work on for any experienced Java developer.
You can find the actual values in the Param class.
An extract of the parameters I want to discuss is here (updated 19.3.2019):
// Fee in BTC for a 1 BTC trade. 0.001 is 0.1%. @5000 USD/BTC price 0.1% fee is 5 USD.
DEFAULT_MAKER_FEE_BTC("0.001", ParamType.BTC, 5, 5),
DEFAULT_TAKER_FEE_BTC("0.003", ParamType.BTC, 5, 5), // 0.2% of trade amount
MIN_MAKER_FEE_BTC("0.00005", ParamType.BTC, 5, 5), // 0.005% of trade amount
MIN_TAKER_FEE_BTC("0.00005", ParamType.BTC, 5, 5),
// Fee in BSQ satoshi for a 1 BTC trade. 100 Satoshi = 1 BSQ
// If 1 BTS is 1 USD the fee @5000 USD/BTC is 0.5 USD which is 10% of the BTC fee of 5 USD.
// Might need adjustment if BSQ/BTC rate changes.
DEFAULT_MAKER_FEE_BSQ("0.50", ParamType.BSQ, 5, 5), // ~ 0.01% of trade amount
DEFAULT_TAKER_FEE_BSQ("1.5", ParamType.BSQ, 5, 5),
// 0.03 BSQ (3 satoshi) for a 1 BTC trade. 0.05 USD if 1 BSQ = 1 USD, 10 % of the BTC fee
MIN_MAKER_FEE_BSQ("0.03", ParamType.BSQ, 5, 5), // 0.0003%.
MIN_TAKER_FEE_BSQ("0.03", ParamType.BSQ, 5, 5),
// Fees proposal/voting. Atm we don't use diff. fees for diff. proposal types
// See: https://github.com/bisq-network/proposals/issues/46
PROPOSAL_FEE("2", ParamType.BSQ, 5, 5), // 2 BSQ
BLIND_VOTE_FEE("2", ParamType.BSQ, 5, 5), // 2 BSQ
// As BSQ based validation values can change over time if BSQ value rise we need to support that in the Params as well
COMPENSATION_REQUEST_MIN_AMOUNT("10", ParamType.BSQ, 4, 2),
COMPENSATION_REQUEST_MAX_AMOUNT("100000", ParamType.BSQ, 4, 2),
REIMBURSEMENT_MIN_AMOUNT("10", ParamType.BSQ, 4, 2),
REIMBURSEMENT_MAX_AMOUNT("10000", ParamType.BSQ, 4, 2),
// Quorum required for voting result to be valid.
// Quorum is the min. amount of total BSQ (earned+stake) which was used for voting on a request.
// E.g. If only 2000 BSQ was used on a vote but 10 000 is required the result is invalid even if the voters voted
// 100% for acceptance. This should prevent that changes can be done with low stakeholder participation.
QUORUM_COMP_REQUEST("20000", ParamType.BSQ, 2, 2),
QUORUM_REIMBURSEMENT("20000", ParamType.BSQ, 2, 2),
QUORUM_CHANGE_PARAM("100000", ParamType.BSQ, 2, 2),
QUORUM_ROLE("50000", ParamType.BSQ, 2, 2),
QUORUM_CONFISCATION("200000", ParamType.BSQ, 2, 2),
QUORUM_GENERIC("5000", ParamType.BSQ, 2, 2),
QUORUM_REMOVE_ASSET("10000", ParamType.BSQ, 2, 2),
// Threshold for voting in % with precision of 2 (e.g. 5000 -> 50.00%)
// This is the required amount of weighted vote result needed for acceptance of the result.
// E.g. If the result ends up in 65% weighted vote for acceptance and threshold was 50% it is accepted.
// The result must be larger than the threshold. A 50% vote result for a threshold with 50% is not sufficient,
// it requires min. 50.01%.
// The maxDecrease value is only relevant if the decreased value will not result in a value below 50.01%.
THRESHOLD_COMP_REQUEST("50.01", ParamType.PERCENT, 1.2, 1.2),
THRESHOLD_REIMBURSEMENT("50.01", ParamType.PERCENT, 1.2, 1.2),
THRESHOLD_CHANGE_PARAM("75.01", ParamType.PERCENT, 1.2, 1.2), // That might change the THRESHOLD_CHANGE_PARAM and QUORUM_CHANGE_PARAM as well. So we have to be careful here!
THRESHOLD_ROLE("50.01", ParamType.PERCENT, 1.2, 1.2),
THRESHOLD_CONFISCATION("85.01", ParamType.PERCENT, 1.2, 1.2), // Confiscation is considered an exceptional case and need very high consensus among the stakeholders.
THRESHOLD_GENERIC("50.01", ParamType.PERCENT, 1.2, 1.2),
THRESHOLD_REMOVE_ASSET("50.01", ParamType.PERCENT, 1.2, 1.2),
// BTC address as recipient for BTC trade fee once the arbitration system is replaced as well as destination for
// the time locked payout tx in case the traders do not cooperate. Will be likely a donation address (Bisq, Tor,...)
// but can be also a burner address if we prefer to burn the BTC
RECIPIENT_BTC_ADDRESS(BisqEnvironment.getBaseCurrencyNetwork().isMainnet() ? "1BVxNn3T12veSK6DgqwU4Hdn7QHcDDRag7" : // mainnet
BisqEnvironment.getBaseCurrencyNetwork().isDaoBetaNet() ? "1BVxNn3T12veSK6DgqwU4Hdn7QHcDDRag7" : // mainnet
BisqEnvironment.getBaseCurrencyNetwork().isTestnet() ? "2N4mVTpUZAnhm9phnxB7VrHB4aBhnWrcUrV" : // testnet
"mquz1zFmhs7iy8qJTkhY7C9bhJ5S3g8Xim", // regtest or DAO testnet (regtest)
ParamType.ADDRESS),
// Fee for activating an asset or re-listing after deactivation due lack of trade activity. Fee per day of trial period without activity checks.
ASSET_LISTING_FEE_PER_DAY("1", ParamType.BSQ, 10, 10),
// Min required trade volume to not get de-listed. Check starts after trial period and use trial period afterwards to look back for trade activity.
ASSET_MIN_VOLUME("0.01", ParamType.BTC, 10, 10),
LOCK_TIME_TRADE_PAYOUT("4320", ParamType.BLOCK), // 30 days, can be disabled by setting to 0
ARBITRATOR_FEE("0", ParamType.PERCENT), // % of trade. For new trade protocol. Arbitration will become optional and we can apply a fee to it. Initially we start with no fee.
MAX_TRADE_LIMIT("2", ParamType.BTC, 2, 2), // max trade limit for lowest risk payment method. Others will get derived from that.
As repeatedly requested by the Monero community that Bisq add XMR support as base currnecy and to reflect the fact that Monero is by far the most traded currency (> 90% of volume) I would suggest as first step the integration of a Monero wallet via RPC to monerod.
The user need to run monerod and Bisq would connect vai RPC to the deamon. A basic Monero wallet UI for satisfying the needs for a Bisq Monero trade should be added as well.
Maybe even better would be to automate a trade by triggering the Monero wallet transfer in case of a XMR seller or check if XMR was received in case of the XMR buyer.
Additional to the proposal for the Notification mobile app we need a concept and UI design for setting the notifications inside Bisq.
This draft should give only the very basic idea and overview in the hope that any contributor can work on that to work on a more detailed proposal.
There should be at least those types of notifications:
Nice to have:
For the one-time setup (key and mobile token exchange from mobile app to Bisq app by scanning a QR code) we need a screen as well. That can be added to the Account menu as additional sub item.
It would contain only a button for scanning the QR code with the computers camera, a input text field for those who have no camera (key and mobile token is sent by email to computer) and a display field for the key and token.
We only support one mobile app to be linked to one Bisq app.
For setting up and editing the notifications we need a new screen with sufficient space and several submenues. It should be extendable to add new notification types in future.
We are limited with the available space at the top menu (a BSQ icon will be added as well once the BSQ-DAO is complete). So we should try to get it into an existing menu item or think of ways to combine existing ones (without creating tom much dev effort). Maybe the notifications don't need a standard icon but some different styled small icon?
We could also integrate a icon button to all relevant screens (e.g. open offers, offer book,...) to link to the notification screen to make it easier to users to find it. The main menu could be then inside of settings (new tab). When we launch the new feature we can add a one-time popup with pointing the user to the new feature.
So what is mainly needed is a good concept where and how to place and link the notifications screen as well as to make rough layouts for the different setup/edit notifications screens. That can be wire frame layouts. For that task no development skills are required.
Design-wise we would stick with the current UI style atm (will be reskinned with rest of app soon).
Bisq nodes are long-running. Lightning nodes are too. Why not have Bisq nodes become the simplest form of Lightning node now, as a first step toward deeper kinds of integration later?
To claim this bounty, write a proposal about how to integrate @ACINQ's Scala LN implementation into Bisq such that Bisq nodes automatically participate not only in the Bisq Network for the purpose of buying and selling bitcoin, but also participate in the Lightning Network for the purpose of routing payments.
Bisq users could benefit from even the most basic LN integration immediately because their already-running Bisq nodes would begin to earn fees for routing LN payments. These fees may be very small, but Bisq users were going to be running their nodes anyway; it's all profit from their point of view. And besides, most Bisq users would likely be happy to get involved with and help support Lightning however they can. How better to do that than with the app they're already running?
Later, deeper integrations could allow Bisq users to send and receive LN payments of their own, and eventually turn Bisq into a full-fledged Lightning wallet; yet further work could go on to integrate Lightning directly into Bisq's trading protocol.
The proposal being called for here is about devising the best way to get started while keeping these larger ambitions in mind. The proposal itself is the bounty: come up with a cogent plan that gets rough consensus from existing Bisq DAO stakeholders and the reward is yours. Work alone or with others—anyone and everyone can submit a compensation request for the proposal, according to the value they contributed to it.
The work to implement the proposal would be managed as separate issues and separate bounties. The goal is to break work up such that small but meaningful chunks of LN integration can be shipped with each Bisq release.
This work is something we've been thinking about doing for a while, but the existing group of @bisq-network/contributors is busy with other priorities. Ideally, we're looking for new contributors to get involved with Bisq for this effort, and to work as autonomously as possible to propose and then implement this functionality.
If you're interested in and able to do this work, please say so in the comments and add your ideas. Ideally a small team would form to take this on. The proposal process need not be too formal. It can start as a discussion here, and eventually a BIP-style doc can be submitted to this repository as a pull request. Or, if the plan is already clear enough, it can be mapped out into a series of issues in the bisq-network/exchange repository.
Discussion on slack is at #p2p-network
Websockets are long living network data stream connections. (RFC 6455)
It has been established that it is technically possible to connect a websocket connection to a TOR onion service. (bisq-front).
Initial response from the TOR onion community is that this is an accepted methodology that has been approved into the TOR spec.
The questions are:
It is proposed that a simple test be written in isolation, the logic of which will be:
I am not going to get to this any time soon, so I am putting it out here in the hope that someone can pick up on it before me.
The onion service config (torrc file) will look something like this:
HiddenServiceDir /home/michaeladmin/.tor/bob
HiddenServicePort 80 127.0.0.1:3110
HiddenServicePort 3111 127.0.0.1:3111
where HiddenServicePort 80 is the http server and HiddenServicePort 3111 is the websocket http server
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.