[Approved, sort of] Liability for price fluctuations (BTC)

[Gladiator]

Some good discussion here: Require A Minimum Sat Fee but I wanted to raise a different issue. Something I was curious about and discussed with video a week ago

Spoiler

and something @beyond blue also brought brought up in his report here: https://www.sythe.org/posts/50156595/

This 'rule' isn't in place yet, but given the recent volatility and price fluctuations of BTC, I think it's very important to discuss. I don't think it's fair that a customer who has been waiting for week(s), who was never informed of what fees will be used for their payment, should have to eat up a loss of $100+ such as the report here: problem with grant after sold 7b in osrs

If buyers are not going to disclose fees and transactions take more than x amount of time(24 hours-3 days), I think they should be held responsible for price fluctuations. The buyer should pay the difference for 1.) Not disclosing/agreeing to fees before hand 2.) For the delays caused.

If fees are discussed before hand, then there's no issues (however long it takes to confirm).

If fees are not discussed before hand, the burden of proof to show whether they were reasonable or not, should fall on the buyers; a simple screenshot from blockchain shows whether the transaction was sent with regular fees or below: https://i.imgur.com/68U229T.png at the time. If they were sent with regular fees then again we can rule that they must continue to wait.

However, if the above proof is missing, and the payment was sent with below blockchain regular fee, and that transaction takes longer than x amount of time(1-3 days imo) to finally confirm, then the buyer should cover the fall in price. If the transaction never confirms because it was sent with very low fees, and it returns back to the buyer, they should resend the same btc with priority fees even if the same amount of btc is worth significantly higher (the scenario I discussed with video in the spoiler above).

 

If fees are not discussed before hand, the burden of proof to show whether they were reasonable or not, should fall on the seller; a simple screenshot from blockchain shows whether the transaction was sent with regular fees or below: https://i.imgur.com/68U229T.png at the time. If they were sent with regular fees then again we can rule that they must continue to wait.

However, if the above proof is missing, and the payment was sent with below blockchain regular fee, and that transaction takes longer than x amount of time(1-3 days imo) to finally confirm, then the seller should cover the fall in price. If the transaction never confirms because it was sent with very low fees, and it returns back to the seller, they should resend the same btc with priority fees even if the same amount of btc is worth significantly higher (the scenario I discussed with video in the spoiler above).

Do you mean the buyer? Since its the buyer of the gold that sends the BTC. The seller of the gold is the one receiving the BTC?

 

[President]

Some good discussion here: Require A Minimum Sat Fee but I wanted to raise a different issue. Something I was curious about and discussed with video a week ago

Spoiler

and something @beyond blue also brought brought up in his report here: https://www.sythe.org/posts/50156595/

This 'rule' isn't in place yet, but given the recent volatility and price fluctuations of BTC, I think it's very important to discuss. I don't think it's fair that a customer who has been waiting for week(s), who was never informed of what fees will be used for their payment, should have to eat up a loss of $100+ such as the report here: problem with grant after sold 7b in osrs

If sellers are not going to disclose fees and transactions take more than x amount of time(24 hours-3 days), I think they should be held responsible for price fluctuations. The seller should pay the difference for 1.) Not disclosing/agreeing to fees before hand 2.) For the delays caused.

If fees are discussed before hand, then there's no issues (however long it takes to confirm).

If fees are not discussed before hand, the burden of proof to show whether they were reasonable or not, should fall on the seller; a simple screenshot from blockchain shows whether the transaction was sent with regular fees or below: https://i.imgur.com/68U229T.png at the time. If they were sent with regular fees then again we can rule that they must continue to wait.

However, if the above proof is missing, and the payment was sent with below blockchain regular fee, and that transaction takes longer than x amount of time(1-3 days imo) to finally confirm, then the seller should cover the fall in price. If the transaction never confirms because it was sent with very low fees, and it returns back to the seller, they should resend the same btc with priority fees even if the same amount of btc is worth significantly higher (the scenario I discussed with video in the spoiler above).

Taking into consideration how extremely volatile BTC is, Two questions:

1. At what exact moment do you determine what is actually due? Take a look at the following hypothetical timeframe of events @Gladiator

1. Say gold seller X pays buyer Y at moment A. In return buyer Y sends BTC to seller X.
2. At moment B the BTC still didn't arrive seller X. BTC rate is now at an all-time low (given the relative period A-D)
3. After B comes moment C where BTC rate is at an all-time high (given the relative period A-D)
4. BTC finally arrives at moment D. The BTC rate at moment D is anywhere in between that of moment B and C

(my scenario visualized: image)

2. Do you want this rule to be applied capless? So for any type of change, no matter how small?

 

[Gladiator]

Do you mean the buyer? Since its the buyer of the gold that sends the BTC. The seller of the gold is the one receiving the BTC?

Buyer of the OSRS, yes (Grant in the report above) - my mistake/typo

 

Taking into consideration how extremely volatile BTC is, Two questions:

1. At what exact moment do you determine what is actually due? Take a look at the following hypothetical timeframe @Gladiator
-Say gold seller X pays buyer Y at moment A. In return buyer Y sends BTC to seller X.
-At moment B the BTC still didn't arrive seller X. BTC rate is now at an all-time low (given the relative period A-D)
-After B comes moment C where BTC rate is at an all-time high (given the relative period A-D)
-BTC finally arrives at moment D. The BTC rate at moment D is anywhere in between that of moment B and C

(my scenario: image)

2. Do you want this rule to be applied capless? So for any type of change, no matter how small?

Pretty sure its just whenever the btc arrives/doesnt arrive.

E.g. if it confirms after 7 days and the btc price is lower so amount received was less - difference is due
if arrives after 7 days, and btc price is higher - the guy who had to wait receives more money, nothing is due - his benefit

If the btc disappears
- if the btc price is higher, amount of btc RESENT is the same BTC amount as was originally sent - so the guy who had to wait does not lose out
- if btc price FALLS and btc needs to be resent, USD value is used again so the guy who had to wait doesnt lose out.

 

[Gladiator]

Pretty sure its just whenever the btc arrives/doesnt arrive.

E.g. if it confirms after 7 days and the btc price is lower so amount received was less - difference is due
if arrives after 7 days, and btc price is higher - the guy who had to wait receives more money, nothing is due - his benefit

If the btc disappears
- if the btc price is higher, amount of btc RESENT is the same BTC amount as was originally sent - so the guy who had to wait does not lose out
- if btc price FALLS and btc needs to be resent, USD value is used again so the guy who had to wait doesnt lose out.

Exactly this, whenever it confirms/is received, we can default to 1 confirmation if we need to be ultra specific

2. Do you want this rule to be applied capless? So for any type of change, no matter how small?

Ideally there would be a cap, it seems petty to report others over a +- $1-10 change

 

[President]

Exactly this, whenever it confirms/is received, we can default to 1 confirmation if we need to be ultra specific




Ideally there would be a cap, it seems petty to report others over a +- $1-10 change

That seems fair. Interested to see what you think of my first question.

Bottom line: I agree with the sentiment. if due to withholding/skewing certain info a receiver is duped, it's pretty straight-forward to hold the sender liable. For me, the relevant question is, for how much exactly?

 

Support

 

Well I support that there should be forced communication, these sellers that make $10-30 per bill arent wanting to pay the $11+ fees on the payments...

The problem is everyones flipping for like .01-.05 margins so on almost any payout they are actually losing money unless they are buying 200m+ at a time with .05+ margins.

People just need to aim for bigger margins and stop lowering the sat fee to almost 0 so they can make an extra $10....

This month alone I've paid over $300+ in fees just paying out workers when its time.

So yeah no excuse, if you cant manage to make profits with btc as it is maybe its time you let the ones who can take over and stop trying to screw people who are selling you gold.

Yellow Hat

 

[Gladiator]

That seems fair. Interested to see what you think of my first question.

A = amount agreed upon
B = amount received
C (A-B) = amount owed

I'm going to use this report: problem with grant after sold 7b in osrs as an example to try answer your hypothetical graph/situation

A = $3150, the amount that was sent on blockchain at the time / amount both parties agreed upon

At what exact moment do you determine what is actually due?

B = amount received was $3000 at the time when the transaction finally confirmed / was received by the 'victim' in this report (it's easy to check the usd value on blockchain for when it confirms and this would be the moment we determine what is due)

C = A - B, so $150 is owed

This is how it would work in practise and it's how we should work out how much is owed.

 

A = amount agreed upon
B = amount received
C (A-B) = amount owed

I'm going to use this report: problem with grant after sold 7b in osrs as an example to try answer your hypothetical graph/situation

A = $3150, the amount that was sent on blockchain at the time / amount both parties agreed upon

B = amount received was $3000 at the time when the transaction finally confirmed / was received by the 'victim' in this report (it's easy to check the usd value on blockchain for when it confirms and this would be the moment we determine what is due)

C = A - B, so $150 is owed

This is how it would work in practise and it's how we should work out how much is owed.

As an accountant I have a fairly good understanding of the difference between FOB shipping and FOB destination.
Of course this isn't exactly the same but the concept is similar. We are determining who owns the BTC at which point in time and therefore, who holds the liability of any "damages" (in this case price drops) until the BTC has reached its destination.

From what I gather we are trying to say that the seller (person receiving the BTC) will own the BTC once the transaction has confirmed at least once. (Therefore this would be FOB Destination)

I support, but it also leaves a strange argument here. What if BTC acts the other way? Is this only in the case where people lose money due to the BTC drop over the time it takes to confirm? What if BTC were to gain price? Would the seller then owe the difference back? (I'd assume not)
If this does become a rule it may be a good idea to indicate that this is only in the event of a price drop, not a price gain.

 

[Gladiator]

As an accountant I have a fairly good understanding of the difference between FOB shipping and FOB destination.
Of course this isn't exactly the same but the concept is similar. We are determining who owns the BTC at which point in time and therefore, who holds the liability of any "damages" (in this case price drops) until the BTC has reached its destination.

From what I gather we are trying to say that the seller (person receiving the BTC) will own the BTC once the transaction has confirmed at least once. (Therefore this would be FOB Destination)

I support, but it also leaves a strange argument here. What if BTC acts the other way? Is this only in the case where people lose money due to the BTC drop over the time it takes to confirm? What if BTC were to gain price? Would the seller then owe the difference back? (I'd assume not)
If this does become a rule it may be a good idea to indicate that this is only in the event of a price drop, not a price gain.

if BTC increases in price (where the person receiving it hasn't lost anything, other than time) nothing happens as you've correctly said. However, if the transaction itself fails because the fees were low to begin with, which can happen if it never confirms (btc is sent back to the sender), then the sender of the btc is expected to resend the same btc amount, even if it has increased in price (a loss for the sender). The victim in this case doesn't lose out whether btc has dropped, or whether the transaction itself has failed and the btc needs to be resent. My conversation with video describes that scenario (hopefully it makes more sense):

Spoiler

 

I think the above suggestion is fair on the basis that you've sent BELOW the recommended fee at the time of sending without getting consent to use a lower fee, e.g. due to the quantity they're selling not being worth a large fee & they're happy to wait.

I think the above should be disregarded for any situations where:
1. The receiver of the BTC is happy for a low fee to be used, and happy to just receive the agreed amount of bitcoin whenever it confirms - this is normal for alot of people who simply hold bitcoin long term, and as long as it doesnt get reversed are happy to wait for it.
2. The bitcoin was sent from a wallet that by standard use a good fee, but for unforeseen circumstances the blockchain got quickly congested and fees rose - for example COINBASE go through phases of not actually initiating the send for bitcoin for 1-3+ hours, or exchanges taking a certain amount of time to send the bitcoin - should bitcoin move adversely in that time, is it fair on the sender?
3. People are being petty about the time it takes to confirm - e.g. even with recommended fees sometimes it can take up to an hour to get a confirm even if the fee is good - if bitcoin plummets in this time and a good fee was used i think its unfair to the sender of the bitcoin to have to cover the difference.

Because there are alot of limitations / possibilities above - i think a better rule would be along the lines of the other thread, for them to simply use a good fee or at the VERY LEAST, consult their customer that a low fee is being used so they can choose a different vendor if they wish. Then in the event they didnt mention a low fee was used, and it can be proved that it was below the recommended - then they owe the difference as explained by @Gladiator above.

Think a case by case common sense approach is probably better than a WHO OWES WHAT situation on any bitcoin confirmation that takes more than say 6 hours to confirm

 

[Russian_killer1337]

Full support.

 

[FORUMS MANIC]

A = amount agreed upon
B = amount received
C (A-B) = amount owed

I'm going to use this report: problem with grant after sold 7b in osrs as an example to try answer your hypothetical graph/situation

A = $3150, the amount that was sent on blockchain at the time / amount both parties agreed upon

B = amount received was $3000 at the time when the transaction finally confirmed / was received by the 'victim' in this report (it's easy to check the usd value on blockchain for when it confirms and this would be the moment we determine what is due)

C = A - B, so $150 is owed

This is how it would work in practise and it's how we should work out how much is owed.

I don't agree, let me explain

Ryan sells 1b OSRS GP to Chuck for $500.00 (USD) Which is 0.000478394 (BTC) Which is by no means the correct amount in BTC its just an example.
So at that point and time the $500.00 (USD) is Worth/Valued at 0.000478394 (BTC) Chuck sends payment at the time he clicks send the value is still the same as agreed on.
So if the seller does not instantly receive the BTC and it takes time and then once he does receive payment its lower (USD) but the still the same amount of (BTC) ?

This is just an unfortunate part of crypto currency.
So why should chuck have to send more (BTC) to Ryan just because price falls during the transaction procedure.

In this case it should be a 2 sided knife.
If it was the opposite and the price shoots up from the time Chuck Sends it and Ryan receives it then Ryan should be sending Chuck a refund.

All Sales should be based on a (BTC) Amount And not based on USD, AUD, GBP, EURO... Ect
Example..
So at the time Ryan is selling Chuck OSRS GP for 0.000478394 (BTC) which is Currently $500.00 (USD) so the Amount agreed on is 0.000478394 (BTC) And NOT $500.00 (USD)

But i do believe that is has to be at the moment Price and payment would have to be Sent (Not Received) But actually sent at the time that the 0.000478394 (BTC) is valued at $500.00 (USD)
So basically Chuck cant wake up the next morning after agreeing with Ryan the previous night on 0.000478394 (BTC) - $500.00 (USD) And the price of (BTC) dropped over night with 0.000478394 (BTC) now being valued at $474.87 (USD) At the time Chuck sends 0.000478394 (BTC) to Ryan

 

[Shin]

If two users decide to use cryptocurrency as the medium of exchange, then they both accept any risks related to it. While volatility is the most notable risk, users are generally more concerned with speed of a transaction. I don't believe Sythe should define minimums, but allow a user to request a higher fee to be used if a transaction is taking "too long." To avoid any issues, however, it would probably be best for the user receiving cryptocurrency to state what fee should be used and be the one responsible to pay it.

 

[Emperor Nero]

I think its notable to mention that this should be if the fees are lower than average at the time of the transaction. If the buyer is trying to cheap out it should really be on them to cover the difference.

 

But wasnt grant transaction delayed because btc spiked for around 10% shortly after transaction was sent and not because it was sent with low fees ?

And i will actualy go with no support unless this would work both ways otherwise only one side will be constantly eating loses either by btc going up losing money cus customer woudnt need to refund difference or btc going down where 07 gp buyer would have to cover difference.


But i would support that gp buyer would have to notify seller at what fee crypto will be sent [in this case btc cus thats prob only slow crypto rn]

 

[Gladiator]

I don't agree, let me explain

I agree with you, that we shouldn't get involved/adjudicate normal trades, my premise for this suggestion is ONLY if the buyer does not disclose that they're going to use LOW FEES. How would you feel, if I sent you a $500 payment but didn't disclose that I used a 5 sat/b fee (worth a few cents at the time), which would take two weeks to confirm? In two weeks time, that $500 I sent you, might be worth $400 - you would rightfully be quite upset because at no point did I disclose fees - that is all I'm arguing for

I think its notable to mention that this should be if the fees are lower than average at the time of the transaction. If the buyer is trying to cheap out it should really be on them to cover the difference.

Exactly. This would ONLY apply if the buyer decided to 'cheap out' and send extremely low fees WITHOUT informing the other party

But wasnt grant transaction delayed because btc spiked for around 10% shortly after transaction was sent and not because it was sent with low fees ?

And i will actualy go with no support unless this would work both ways otherwise only one side will be constantly eating loses either by btc going up losing money cus customer woudnt need to refund difference or btc going down where 07 gp buyer would have to cover difference.


But i would support that gp buyer would have to notify seller at what fee crypto will be sent [in this case btc cus thats prob only slow crypto rn]

Correct (now that he sent proof of the fees used), during the report this was unknown / the assumption was it was with minimal fees as it took 11 days to confirm. If hypothetically speaking Grant sent with low fees, then I am suggesting he should be liable because he never disclosed fees to the customer at any point during the trade

 

I agree with you, that we shouldn't get involved/adjudicate normal trades, my premise for this suggestion is ONLY if the buyer does not disclose that they're going to use LOW FEES. How would you feel, if I sent you a $500 payment but didn't disclose that I used a 5 sat/b fee (worth a few cents at the time), which would take two weeks to confirm? In two weeks time, that $500 I sent you, might be worth $400 - you would rightfully be quite upset because at no point did I disclose fees - that is all I'm arguing for



Exactly. This would ONLY apply if the buyer decided to 'cheap out' and send extremely low fees WITHOUT informing the other party




Correct (now that he sent proof of the fees used), during the report this was unknown / the assumption was it was with minimal fees as it took 11 days to confirm. If hypothetically speaking Grant sent with low fees, then I am suggesting he should be liable because he never disclosed fees to the customer at any point during the trade

The point glad is making here is that...

#1 If a Buyer sends a low sat fee its 0% risk for them when sending the gold and the only person at risk is the seller since the buyer is attempting to reduce their "cost and increase profit margins" it shouldnt be a matter of it going "both ways" in terms of the profits if the BTC goes up since it was the choice of the seller to send a low SAT fee.

#2 This isnt about "what if and maybe it goes up shouldnt the buyer get profits off the increased BTC" no... This is to fix the current issues where buyers are purposely lowering sat fees to save money / profit higher margins at the cost of the sellers "time, BTC risk, and profits for themselves." .

#3 If you are going to send low sat fees / make a seller wait an extremely extended period so you can save $10 then you should be held liable or made to tell the seller that you are going to rape them ...


#4 These "Buyers" that are flipping gold , what if someone bought gold from you and sent a low sat fee that took 2 weeks to arrive to you and the price of the BTC dropped would you still give them the amount of gold they paid for at that current buy rate?? NO you would tell them they have to "wait until the BTC arrives, then proceed to give them the current buy rate + whatever BTC landed", so please stop acting like this is some crazy suggestion that forces you into a fair trade..


This is really simple stuff I dont see why its a back and forth period.

IF I give you a jug of milk for $5 and dont tell you its going to take 2 weeks to arrive then it spoils wouldnt you want a refund for the spoiled milk???

....

Yellow Hat