From 06adc79571ef1d910a779a30614c60c031b0803f Mon Sep 17 00:00:00 2001 From: Dimitris Apostolou Date: Tue, 8 May 2018 17:19:39 +0300 Subject: [PATCH] Fix typos --- dao/overview.adoc | 2 +- dao/phase-zero.adoc | 4 +-- dao/specification.adoc | 30 +++++++++---------- .../howto/add-alternative-base-currency.adoc | 2 +- exchange/howto/run-price-relay-node.adoc | 8 ++--- exchange/howto/run-seednode.adoc | 4 +-- exchange/whitepaper.adoc | 4 +-- manual-dispute-payout.adoc | 10 +++---- payment-account-age-witness.adoc | 4 +-- proposals.adoc | 2 +- 10 files changed, 35 insertions(+), 35 deletions(-) diff --git a/dao/overview.adoc b/dao/overview.adoc index fbd6d79..96a7232 100644 --- a/dao/overview.adoc +++ b/dao/overview.adoc @@ -203,7 +203,7 @@ The risk of forking provides a strong incentive not to act contrary to the inter It is possible for the main stakeholders to abuse their power in detriment to the interests of minority stakeholders (a.k.a. a majority attack). For example, a majority could vote to add new rules for confiscating or invalidating the tokens of the minority stakeholders. Such decisions constitute a hard fork, i.e. a change to the system that is not backward compatible. -The established network will not accept transactions on the hard fork. This means that a malicious fork would have the difficult task of starting a network of traders from scratch, in particular since they have to compete against the old network. Second, the token value on the new fork would be essentially zero, and the attackers would presumably lose a lot of wealth.The attackers need to get their token value back and this would take decades, given a token yield of a few percent. +The established network will not accept transactions on the hard fork. This means that a malicious fork would have the difficult task of starting a network of traders from scratch, in particular since they have to compete against the old network. Second, the token value on the new fork would be essentially zero, and the attackers would presumably lose a lot of wealth. The attackers need to get their token value back and this would take decades, given a token yield of a few percent. In short, we see no economic incentive for a majority attack on the Bisq DAO. diff --git a/dao/phase-zero.adoc b/dao/phase-zero.adoc index 749a497..6b03c17 100644 --- a/dao/phase-zero.adoc +++ b/dao/phase-zero.adoc @@ -364,7 +364,7 @@ With that said, it's a good idea to consult with stakeholders via the Bisq forum . something that the relevant maintainer(s) would be likely to merge; . something that stakeholders would likely vote to approve as a compensation request; - . subjected to as as much feedback as possible while still an idea and thus cheap to change or abort. + . subjected to as much feedback as possible while still an idea and thus cheap to change or abort. Remember: _every contributor_ is free to work on what they want, including maintainers who may or may not want to review and merge your pull request if they don't have any prior context for it, or reason to believe it's worth spending their time on. @@ -439,7 +439,7 @@ An _operator_ is a bonded contributor responsible for running ("operating") soft === Administrator -An _administrator_ is a bonded contributor responsible for managing ("adminstering") applications and services that support the Bisq project. Examples include GitHub admin, DNS admin, Slack admin, IRC admin and Discourse (forum) admin. +An _administrator_ is a bonded contributor responsible for managing ("administering") applications and services that support the Bisq project. Examples include GitHub admin, DNS admin, Slack admin, IRC admin and Discourse (forum) admin. === Other roles not listed here diff --git a/dao/specification.adoc b/dao/specification.adoc index d0e7d37..f9bf98e 100644 --- a/dao/specification.adoc +++ b/dao/specification.adoc @@ -5,9 +5,9 @@ NOTE: This document is a detailed technical specification for the Bisq DAO and B == BSQ token -BSQ tokens are based on Bitcoin and use the Bitcoin blockchain similar to colored coins. We don't use any existing colored coin implementation because our use case requires some extra features which are not supported by those (e.g. decentralized issuance). Beside that, we did not want to introduce any external dependencies to a company or Altcoin. As Bitcoin is the default base currency in Bisq anyway, and our requirements can be 100% covered by the basic features Bitcoin provides we decided to build our custom colored coin solution on top of the Bitcoin blockchain. We don't have the ambition to provide a general purpose solution but have designed the model according to the concrete requirements of Bisq DAO. +BSQ tokens are based on Bitcoin and use the Bitcoin blockchain similar to colored coins. We don't use any existing colored coin implementation because our use case requires some extra features which are not supported by those (e.g. decentralized issuance). Besides that, we did not want to introduce any external dependencies to a company or Altcoin. As Bitcoin is the default base currency in Bisq anyway, and our requirements can be 100% covered by the basic features Bitcoin provides we decided to build our custom colored coin solution on top of the Bitcoin blockchain. We don't have the ambition to provide a general purpose solution but have designed the model according to the concrete requirements of Bisq DAO. -Technically a BSQ token is the same as Bitcoin but it adds some additional rules. A BSQ token is denominated as 100 Bitcoin Satoshi so it can be divided in 100 subunits, leading to the smallest unit of 0.01 BSQ, which is equivalent to 1 Satoshi. Bitcoin requires that the minimum amount of a transaction output is 2730 Satoshi (dust limit) so for transferring BSQ tokens we inherit that limitation. The smallest possible BSQ amount to transfer is therefore 27.30 BSQ. As BSQ tokens are inherently BTC they will have at least the market value of the Bitcoin Satoshis. So 1 BSQ = 100 Satoshi >= the market value of 0.00000100 BTC, which equals at a market price of 20 000 USD/BTC, about 0.02 USD. The real market value of a BSQ token will be decided by the market once trading has started ans will be the sum of that underlying BTC value with the value traders see in the Bisq project. +Technically a BSQ token is the same as Bitcoin but it adds some additional rules. A BSQ token is denominated as 100 Bitcoin satoshis so it can be divided in 100 subunits, leading to the smallest unit of 0.01 BSQ, which is equivalent to 1 satoshi. Bitcoin requires that the minimum amount of a transaction output is 2730 satoshis (dust limit) so for transferring BSQ tokens we inherit that limitation. The smallest possible BSQ amount to transfer is therefore 27.30 BSQ. As BSQ tokens are inherently BTC they will have at least the market value of the Bitcoin satoshis. So 1 BSQ = 100 satoshis >= the market value of 0.00000100 BTC, which equals at a market price of 20 000 USD/BTC, about 0.02 USD. The real market value of a BSQ token will be decided by the market once trading has started and will be the sum of that underlying BTC value with the value traders see in the Bisq project. ==== Wallet @@ -84,13 +84,13 @@ A contribution is typically one of the following activities: - Advice - Others (we will decide on a case to case basis) -Basically any contributed effort exceeding roughly 4 hours will be considered to be included in the group of receivers for the initial distribution. We will announce that call for requests at the https://bisq.community/[Bisq Forum] and contributors need to send an email with the required information to enable verification if the request is justified. They should give a short description and if possible references to the work (links to Github, Forum, etc,...) and provide the spent time and the period when their contribution happened. We will apply a factor for giving early contributions higher weight as well as a factor to give long term contributions more weight. This should reflect the higher risk at earlier periods as well as the higher value of long term contributions. The Bisq team will verify those requests and if it is justified and the requested amount reasonable we will add the contributor to the list of receivers. The hours will get multiplied by a factor to the type of contribution (orientated on typical market salaries). We will then sum up all the weighted hours of all verified contributors and use the percentage of each contributor related to the overall sum for calculating the amount of BSQ they will receive from the genesis transaction. So if a contributor has worked 100 hours and the sum of all contributors is 10 000 hours he will receive 1% of the 2 500 000.00 BSQ from the genesis transaction, thus 25 000 BSQ. +Basically any contributed effort exceeding roughly 4 hours will be considered to be included in the group of receivers for the initial distribution. We will announce that call for requests at the https://bisq.community/[Bisq Forum] and contributors need to send an email with the required information to enable verification if the request is justified. They should give a short description and if possible references to the work (links to GitHub, Forum, etc,...) and provide the spent time and the period when their contribution happened. We will apply a factor for giving early contributions higher weight as well as a factor to give long term contributions more weight. This should reflect the higher risk at earlier periods as well as the higher value of long term contributions. The Bisq team will verify those requests and if it is justified and the requested amount reasonable we will add the contributor to the list of receivers. The hours will get multiplied by a factor to the type of contribution (orientated on typical market salaries). We will then sum up all the weighted hours of all verified contributors and use the percentage of each contributor related to the overall sum for calculating the amount of BSQ they will receive from the genesis transaction. So if a contributor has worked 100 hours and the sum of all contributors is 10 000 hours he will receive 1% of the 2 500 000.00 BSQ from the genesis transaction, thus 25 000 BSQ. The way how the factors are applied, how the requested amounts get adjusted and the total sum will be kept private in the team to protect privacy of the contributors as well as to avoid pointless discussions. The model for distributing the project's value is a voluntary act of the Bisq team and there is no right for a claim of any contributor as we never gave any guarantee or advertised that as a reward model. We are simply donating back our received donations to those who we think they deserve to get something in return for their support. Also the contributors can request anonymously and it is highly recommended to use GPG. This should protect the privacy of the contributors as far as possible (many will be known due their activity, but at least only the team will know that). For market makers the verification might get a bit more difficult and we will apply a practical approach how to deal with that. They need initially provide only the onion address of their Bisq application and the number of trades they did. If we see a requirement for it there might be an extra software release where the market makers can prove their claims in a way which protects their privacy but gives cryptographic evidence of their request. ==== Trade fee payment -The trade fee can be paid in BSQ (if the user has sufficient BSQ in his wallet) or in BTC. The base fee in BTC will initially be 0.002 BTC. If BSQ is used it will be initially 2 BSQ. If the market price of BSQ is 0.0001 BSQ/BTC the BTC value of the trade fee paid in BSQ would be 0.0002 BTC which is 10% of the fee in BTC so they get a 90% discount. The fee payment is done by making a part of the BSQ invalid and give that part to miners as Satoshis (BTC), thus the BTC value is not lost but used as mining fee. +The trade fee can be paid in BSQ (if the user has sufficient BSQ in his wallet) or in BTC. The base fee in BTC will initially be 0.002 BTC. If BSQ is used it will be initially 2 BSQ. If the market price of BSQ is 0.0001 BSQ/BTC the BTC value of the trade fee paid in BSQ would be 0.0002 BTC which is 10% of the fee in BTC so they get a 90% discount. The fee payment is done by making a part of the BSQ invalid and give that part to miners as satoshis (BTC), thus the BTC value is not lost but used as mining fee. - A 0.50 BSQ fee payment tx could look like that: @@ -100,7 +100,7 @@ The trade fee can be paid in BSQ (if the user has sufficient BSQ in his wallet) * Output 2: 0.09950050 BTC * Mining fee: 0.0005 (0.00049950 BTC + 0.00000050 BTC or 0.50 BSQ) -So in that case we only use 9.50 BSQ of the 10.00 BSQ from the input. As the second output is spending more than the remaining 0.50 BSQ it is invalid as a BSQ output and we consider it as a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reduces the mining fee which is paid from the BTC input (input 2). With that model we can spend fees as small as 0.01 BSQ or 1 Bitcoin Satoshi. +So in that case we only use 9.50 BSQ of the 10.00 BSQ from the input. As the second output is spending more than the remaining 0.50 BSQ it is invalid as a BSQ output and we consider it as a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reduces the mining fee which is paid from the BTC input (input 2). With that model we can spend fees as small as 0.01 BSQ or 1 Bitcoin satoshi. The trade fee will be calculated based on the trade amount and the distance from the market price (if available). We use the same model for BTC and BSQ fees. A 1 BTC trade with 1% distance from the market price will use the default fee. If the trade amount is lower or higher we apply a linear adjustment. 0.1 BTC trade has 10% of the trade fee as long as we don't reach the minimum value for the trade fee. For the distance to the market price we use the square root of the percent value, so 9% would result in a factor of 3. A 16% distance to the market price would cause a 4 times increase of the trade fee. @@ -168,9 +168,9 @@ The full cycle will last 4380 blocks which is about an average month if one bloc ==== Compensation request -Contributors can create a compensation request for the work they contributed to the project. This can be anything what has added value to the project. The contributors has no guarantee that their request gets accepted. So when they start working they need to be aware that there is no guarantee for a reward. +Contributors can create a compensation request for the work they contributed to the project. This can be anything what has added value to the project. The contributors have no guarantee that their request gets accepted. So when they start working they need to be aware that there is no guarantee for a reward. -If not sure about the value of their work for the community, they should make small work packages and discuss at the usual communication channels (Slack, Github, Forum,..) to see if the work they are proposing sparks some interest and support. To use upfront payment with escrow would make the process much more complicated (who controls the escrow,...). It also reflects the situation of normal freelance work where work is paid usually after the work is completed and the reputation of the company provides sufficient base for a trust relationship in most cases. +If not sure about the value of their work for the community, they should make small work packages and discuss at the usual communication channels (Slack, GitHub, Forum,..) to see if the work they are proposing sparks some interest and support. To use upfront payment with escrow would make the process much more complicated (who controls the escrow,...). It also reflects the situation of normal freelance work where work is paid usually after the work is completed and the reputation of the company provides sufficient base for a trust relationship in most cases. To avoid spam the contributor needs to pay a fee of 1 BSQ. There will be a user interface in the application where the contributor fills in a form with the required data. @@ -185,7 +185,7 @@ The range for allowed amounts for a compensation request payout will be 50 BSQ t * Title (must not conflict with existing requests) * Creation date * Description (short paragraph) - * Link to either Github issues or Bisq Forum for detailed description and deliveries + * Link to either GitHub issues or Bisq Forum for detailed description and deliveries * Requested amount in BSQ * BSQ Address * Tx ID @@ -234,7 +234,7 @@ In the vote period a stakeholder cannot transfer his BSQ tokens which they used All valid compensation requests from the current cycle are considered for voting. The stakeholder can choose to accept, decline or ignore a request. For acceptance or decline a simple majority is sufficient (> 50%). -Initially the voting is mainly for the compensation requests but there will be some flexible (yet to defined) option for voting on any topic. Over time we might add more specific vote items like amount of trading fee. To avoid that some stakeholder take benefit of voter apathy and are able to make changes with a very low stake we require a quorum for each vote item. Those quorum values will be defined for each vote item. If the vote item does not reach that limit it will be discarded. +Initially the voting is mainly for the compensation requests but there will be some flexible (yet to defined) option for voting on any topic. Over time we might add more specific vote items like amount of trading fee. To avoid that some stakeholders take benefit of voter apathy and are able to make changes with a very low stake we require a quorum for each vote item. Those quorum values will be defined for each vote item. If the vote item does not reach that limit it will be discarded. We use blind voting to avoid influence of the current state of the votes to voters who have not yet voted. Without blind voting there would be an incentive to wait for the last moment with voting to have more information. @@ -364,13 +364,13 @@ In case a mediator or arbitrator fails (fraud or severe failure in fulfilling th A partial confiscation is also possible. The confiscation will be rolled out as a new release where the confiscated transaction is hardcoded and renders the locked up BSQ invalid. -By using a software update we add another safety factor to avoid abuse (if users don't agree they can simply ignore the update), so users are voting to support the decision for confiscation by updating the software. If there is not a super majority it would lead to a network fork. This hard requirements should make sure that only non-contentious cases can be considered for confiscation. +By using a software update we add another safety factor to avoid abuse (if users don't agree they can simply ignore the update), so users are voting to support the decision for confiscation by updating the software. If there is not a super majority it would lead to a network fork. These hard requirements should make sure that only non-contentious cases can be considered for confiscation. ==== Revocation -For revoking a registration it requires some lead time, because the arbitrator or mediator can be used in trades or disputes which require some time to get completed. The lead time will be 2 weeks (2000 blocks). +Revoking a registration requires some lead time, because the arbitrator or mediator can be used in trades or disputes which require some time to get completed. The lead time will be 2 weeks (2000 blocks). -Offers which will get taken after his revocation can only be taken if other arbitrators are selected in the offer as well. In the worst case an offer which has only selected a revoked arbitrator becomes invalid which will get communicated to the user so he can remove the offer. That should be a very rare case if multiple arbitrator are available. +Offers which will get taken after his revocation can only be taken if other arbitrators are selected in the offer as well. In the worst case an offer which has only selected a revoked arbitrator becomes invalid which will get communicated to the user so he can remove the offer. That should be a very rare case if multiple arbitrators are available. The number of mediators and arbitrators can be influenced by voting by setting the requirements and payments higher or lower. A change of the requirements will not be applied to past registrations. The requirement at registration time will stick the lifetime of a mediator or arbitrator. @@ -401,7 +401,7 @@ To get the privilege to control a private key for one of those messages it requi ===== Accounts - - Github account + - GitHub account - Bisq domain - Bisq Trademark - Social media accounts (Twitter, Reddit, Slack, IRC, Facebook, Telegram, Mailing List, Newsletter) @@ -458,7 +458,7 @@ To avoid later discussions about "code is law" we define with that policy clearl == Definitions -Some terms are used in different context. The following should make more clear the distinction of their meaning. +Some terms are used in different context. The following should make the distinction of their meaning clearer. ===== Compensation request @@ -466,7 +466,7 @@ We refer to that term as the request from the user perspective in a conceptual s ===== Compensation request transaction -This is the Bitcoin transaction which will turn into new issuance transaction once the compensation request got accepted in voting. +This is the Bitcoin transaction which will turn into new issuance transaction once the compensation request got accepted in voting. ===== Compensation request data diff --git a/exchange/howto/add-alternative-base-currency.adoc b/exchange/howto/add-alternative-base-currency.adoc index 09de419..46465a1 100644 --- a/exchange/howto/add-alternative-base-currency.adoc +++ b/exchange/howto/add-alternative-base-currency.adoc @@ -77,6 +77,6 @@ If the PR gets merged the seed node operators and arbitrators will be assigned a - At each new release we will check if already supported base currencies have been traded in the past 4 months. If this requirement is not met the base currency will be removed. The Bisq trade statistics are taken as reference. Removal of a not-traded base currency will not be announced beside in the release notes of the new release. - Adding the base currency again requires a statement about the changed circumstances (e.g. link to discussions where demand for the base currency is documented,...). -=== Getting an new base currency into production might take a bit +=== Getting a new base currency into production might take a bit Adding a new base currency will be part of the normal release cycle. diff --git a/exchange/howto/run-price-relay-node.adoc b/exchange/howto/run-price-relay-node.adoc index 014703b..cc2a0d5 100644 --- a/exchange/howto/run-price-relay-node.adoc +++ b/exchange/howto/run-price-relay-node.adoc @@ -15,7 +15,7 @@ The mining fee estimation is delivered by: . link:https://bitcoinfees.21.co/[21.co] -_Please note that the fee estimation function might get separated in future into it's own node._ +_Please note that the fee estimation function might get separated in the future into its own node._ === Background: @@ -28,7 +28,7 @@ There are several reasons why the Bisq application does not connect directly to For those 2 reasons we changed in earlier updates to the model of operating a price relay node running as Tor hidden service which connects to the service providers in clear net mode and contains the API key for Bitcoin Average. -The price relay carry an important security aspect: + +The price relay carries an important security aspect: + If the trader is using a percentage based price in the offer the actual trade price will be calculated using the current market price taken from the market price providers. If a node would deliver wrong data it could lead to a wrong trade price. Both traders check the calculated price by themselves but if both are connected to the same malicious provider it would result in a wrong trade price. Connection is made randomly to one of the providers in the list. We have as well a check for the age of the price and if the price is older than 30 min. the market price will be ignored. If no price is available percentage based offers cannot be taken. A monitor service checking all price relay nodes and comparing their values for outliers is an important feature we need to add soon. The price relay is a simple http server and has to be set up to be accessible as Tor hidden service. Additionally if the operator wants he can open it to clear net (at least one clear net node is useful for supporting the regtest-without-tor dev setup for receiving market prices). We don't recommend to advertise the node address to not get traffic from non-Bisq users. There is no authentication scheme for Bisq users which make the service vulnerable for abuse of DDoS attacks. An authentication scheme for a P2P/open source environment is a challenge on its own but considered important to get explored further. @@ -36,12 +36,12 @@ The price relay is a simple http server and has to be set up to be accessible as The user connects to one of the nodes randomly and if a node fails it tries the next in random node in the list. If the first node is not available it decreases usability for the user because price display at startup takes longer. -But more critical is that if both nodes are offline percentage based offers cannot be used. Similar if a price node has connection issues with the providers the prices are outdated and likely invalid for other peers when the user engage in a trade. +But more critical is that if both nodes are offline percentage based offers cannot be used. Similar if a price node has connection issues with the providers the prices are outdated and likely invalid for other peers when the user engages in a trade. == Price relay node operators -The price relay node addresses (onion address) are hard coded in the application but can be overruled if the user adds a price relay node address as program argument. Any user can run therefor their own price relay node and connect to it. Though they require an API key for Bitcoin Average (cost are 12.- or 35.- USD/month depending on plan). +The price relay node addresses (onion address) are hard coded in the application but can be overruled if the user adds a price relay node address as program argument. Any user can run therefor their own price relay node and connect to it. Though they require an API key for Bitcoin Average (cost is 12.- or 35.- USD/month depending on plan). Some contributors of Bisq are running the default price relay nodes which are hard coded in the application. It requires a to set up a bond in BSQ to get the privilege to run a default price relay node and it requires that a certain quality of service is met. The operator also need to acquire an API key for Bitcoin Average. Currently we trust that all operators do their best to provide a reliable service without defining exactly the metrics for the quality of service. diff --git a/exchange/howto/run-seednode.adoc b/exchange/howto/run-seednode.adoc index 96bfb65..4e3e976 100644 --- a/exchange/howto/run-seednode.adoc +++ b/exchange/howto/run-seednode.adoc @@ -32,7 +32,7 @@ _Side note: The seed nodes on Linux get a out of memory error after running a fe === Duties of the seed node operator The operator of a seed node need to be responsive in case of seed node software updates as well to OS updates. If there are connectivity issues he need to investigate and if required upgrade his server (RAM, CPU). We recommend 2-4 GB of RAM for one seed node to allow 30 connections. He should check the error logs and the node log file (in the data directory) occasionally. He has to have a professional level of operational security to operate the node. -Operators need to subscribe to the Bisq Slack channel 'seednode' and act if their node reports errors. +Operators need to subscribe to the Bisq Slack channel 'seednode' and act if their node reports errors. == System requirements for hosting machine @@ -101,7 +101,7 @@ Seed nodes are monitored in the Bisq Slack channel 'monitoring' and errors are s == Bond -We define a Bond of 2000 BSQ for the privilege to run a seed node. In case of severe failures of service (malicious or carelessness) the bond would be confiscated (burned). +We define a Bond of 2000 BSQ for the privilege to run a seed node. In case of severe failures of service (malicious or carelessness) the bond would be confiscated (burned). == Payment diff --git a/exchange/whitepaper.adoc b/exchange/whitepaper.adoc index 4bc7ccb..8597b5c 100644 --- a/exchange/whitepaper.adoc +++ b/exchange/whitepaper.adoc @@ -200,7 +200,7 @@ Bisq does not use a reputation system, as such systems can easily be manipulated === Standard exchange process - 1. Trader selects the arbitrators he want to accept in case of disputes or stick with the default selection of all matching arbitrators. + 1. Trader selects the arbitrators he wants to accept in case of disputes or stick with the default selection of all matching arbitrators. 2. Trader sets up a payment method account. 3. Buyer deposits bitcoins from external wallet (for security deposit, create-offer fee and mining fee) 4. Buyer publishes the offer. Create-offer-fee gets paid to one of his selected arbitrators. The security deposit will be locked in his local Bisq trading wallet in case someone takes the offer. @@ -214,7 +214,7 @@ Bisq does not use a reputation system, as such systems can easily be manipulated === Resolving a dispute 1. The traders started a trade but for whatever reason it got stalled. - 2. After the max. allowed trade period (depends on the payment method: e.g. OKPay: 1 day, SEPA: 8 days) the software displays an "Open dispute" button, which is otherwise not visible. Any trader can requests arbitration by pressing that button. + 2. After the max. allowed trade period (depends on the payment method: e.g. OKPay: 1 day, SEPA: 8 days) the software displays an "Open dispute" button, which is otherwise not visible. Any trader can request arbitration by pressing that button. 3. Bisq provides a chat like communication system for disputes (and support tickets in case of software bugs) only between the trader and the arbitrator. The initiating trader will see his first (system) message he has sent to the arbitrator requesting a dispute. 4. The arbitrator receives the dispute request and the software send a dispute message to the other trader, informing him that his peer has started a dispute. The two traders cannot communicate directly with each other and cannot see the communication of the other trader with the arbitrator. 5. Traders and arbitrator communicate in real time, end-to-end encrypted. diff --git a/manual-dispute-payout.adoc b/manual-dispute-payout.adoc index 4481120..5566121 100644 --- a/manual-dispute-payout.adoc +++ b/manual-dispute-payout.adoc @@ -10,7 +10,7 @@ In rare cases, it can become necessary for an arbitrator to work with a trader t The instructions that follow assume that a trade dispute has already been opened, arbitrated and closed, but that for some reason the payout transaction has not occurred as expected. -One reason that a payout transaction may not go through is because the "winner" of the dispute (i.e. the trader who is being awarded the trading amount) has not come online since the ticket has been closed. It is necessary for the winner's Bisq client to come online in order to actually sign their part of of the 2-of-3 multi-sig transaction. If you believe this is the problem, you should *not* jump straight to a manual payout. You should first: +One reason that a payout transaction may not go through is because the "winner" of the dispute (i.e. the trader who is being awarded the trading amount) has not come online since the ticket has been closed. It is necessary for the winner's Bisq client to come online in order to actually sign their part of the 2-of-3 multi-sig transaction. If you believe this is the problem, you should *not* jump straight to a manual payout. You should first: 1. Re-open both buyer and seller tickets for this trade using `cmd-U` 2. Re-close the ticket of the "losing" (i.e. the trader who is *not* receiving the trade amount, this time checking the "Use loser as publisher" checkbox. @@ -44,7 +44,7 @@ P2SHMultiSigOutputScript: === Step 1. Review dispute details -In `Support > Aribtrator's support tickets`, find the trade dispute in question, select it, and *review the closing chat message to determine who was the "winner" of the dispute*, i.e. who was supposed to have recieved the trading amount payout. For example, the closing comments on the dispute below make it clear that it was the seller who won the dispute: +In `Support > Aribtrator's support tickets`, find the trade dispute in question, select it, and *review the closing chat message to determine who was the "winner" of the dispute*, i.e. who was supposed to have received the trading amount payout. For example, the closing comments on the dispute below make it clear that it was the seller who won the dispute: image:images/determine-winner.png[determining who was the winner] @@ -66,7 +66,7 @@ Also *take note of the `txFee` value in the contract JSON*, e.g.: "txFee": 36000, -This is the value of the bitcoin transaction fee denominated in Satoshis. Later, *you will need the same transaction fee value denominated in BTC*, which can be found by dividing the Satoshi value by 100,000,000, e.g.: +This is the value of the Bitcoin transaction fee denominated in satoshis. Later, *you will need the same transaction fee value denominated in BTC*, which can be found by dividing the satoshi value by 100,000,000, e.g.: 36000/100000000 = 0.00036000 BTC @@ -112,7 +112,7 @@ When you have the trader's private key, move on to the next step. [[issue-payout]] === Step 4. Issue the manual dispute payout -Now that you have all the necessary information, you can *open the Emergency multi-sig payout tool* by clicking `alt-g` in the dispute view: +Now that you have all the necessary information, you can *open the Emergency multisig payout tool* by clicking `alt-g` in the dispute view: image:images/multisig-payout-tool.png[Emergency multi-sig payout tool] @@ -124,7 +124,7 @@ sellerPayoutAmount:: The amount in BTC the seller should be paid out, e.g. `0.06 arbitratorPayoutAmount:: This value should always be `0`, as we no longer issue payouts to arbitrators -Tx fee:: The value of the `txFee` taken from the JSON contract details above, after converting from Satoshis to BTC, e.g. `36000` Satoshis => `0.00036` BTC +Tx fee:: The value of the `txFee` taken from the JSON contract details above, after converting from satoshis to BTC, e.g. `36000` satoshis => `0.00036` BTC buyerAddressString:: The buyer's bitcoin address diff --git a/payment-account-age-witness.adoc b/payment-account-age-witness.adoc index aa5d124..6acc45e 100644 --- a/payment-account-age-witness.adoc +++ b/payment-account-age-witness.adoc @@ -5,7 +5,7 @@ Manfred Karrer 2017-09-14 [abstract] -This proposal describes a protection mechanism against a fraud scheme in which a criminal has obtained illegal access of a bank account and tries to buy bitcoin with the stolen funds. The victim of the stolen bank account will likely contact his bank once he discovers the fraud and initiate a bank chargeback. The bitcoin seller would in such a case be at risk to lose the received payment in Fiat currency. We *assume* that the criminal who has access to the bank account intends to take out the funds of that account as quickly as possible as well as that he intends to do that in a few large transactions because with each transaction the risk increases that the fraud gets discovered and the account gets frozen. With the *trade amount limits* in Bisq we have already a protection against that fraud scheme but we would like to increase the security by adding a verification scheme for the *age of the bank account*. To protect users privacy we use a hashing scheme and only the other trading peer - who will receive anyway the payment details during the trade process - is able to verify that the provided hash in the offer matches the real account data. +This proposal describes a protection mechanism against a fraud scheme in which a criminal has obtained illegal access of a bank account and tries to buy bitcoin with the stolen funds. The victim of the stolen bank account will likely contact his bank once he discovers the fraud and initiate a bank chargeback. The bitcoin seller would in such a case be at risk to lose the received payment in Fiat currency. We *assume* that the criminal who has access to the bank account intends to take out the funds of that account as quickly as possible as well as that he intends to do that in a few large transactions because with each transaction the risk increases that the fraud gets discovered and the account gets frozen. With the *trade amount limits* in Bisq we have already a protection against that fraud scheme but we would like to increase the security by adding a verification scheme for the *age of the bank account*. To protect user privacy we use a hashing scheme and only the other trading peer - who will receive anyway the payment details during the trade process - is able to verify that the provided hash in the offer matches the real account data. NOTE: This proposal was implemented in Bisq v0.6.0 @@ -136,7 +136,7 @@ We need to be sure that the date of the trade in the AccountAgeWitness object ca A more advanced fraud approach would be an attempt of hijacking someone else's AccountAgeWitness and payment account to gain the benefit of an already aged account. -A malicious trader could make a trade with someone who has already an old account and takes the account data of that trader to use it for an own account. That fake account can only be used for buying BTC because for selling he would not receive the Fiat money but the user from where he has "stolen" the data. Because he has traded with the peer he has received all the relevant data for the verification like the salt and the pubKey. To protect against such an hijacking attempt we use the peers signature to verify ownership of the AccountAgeWitness data. Without the private key the fraudster cannot create a correct signature matching the pubKey and input data. The public key is used for the hash in the AccountAgeWitness so he cannot alter that. The signed data is defined by the other peer and different for each trade so he has no chance to use data where he knows already the signature. +A malicious trader could make a trade with someone who has already an old account and takes the account data of that trader to use it for an own account. That fake account can only be used for buying BTC because for selling he would not receive the Fiat money but the user from where he has "stolen" the data. Because he has traded with the peer he has received all the relevant data for the verification like the salt and the pubKey. To protect against such a hijacking attempt we use the peers signature to verify ownership of the AccountAgeWitness data. Without the private key the fraudster cannot create a correct signature matching the pubKey and input data. The public key is used for the hash in the AccountAgeWitness so he cannot alter that. The signed data is defined by the other peer and different for each trade so he has no chance to use data where he knows already the signature. === Changing a foreign AccountAgeWitness diff --git a/proposals.adoc b/proposals.adoc index 9f0592c..97da938 100644 --- a/proposals.adoc +++ b/proposals.adoc @@ -85,7 +85,7 @@ TIP: Remember that the proposal review process is all about reaching a _rough co === Step 3. Evaluate -After the two-week review period is over, a maintainer will evaluate reactions to and discussions about the proposal and will close the issue with a comment explaining that it is approved or rejected based on whether a rough consensus was acheived. +After the two-week review period is over, a maintainer will evaluate reactions to and discussions about the proposal and will close the issue with a comment explaining that it is approved or rejected based on whether a rough consensus was achieved. Approved proposals will be labeled with `was:approved`. Rejected proposals will be labeled with `was:rejected`.