Bitoy
|
|
December 19, 2013, 02:27:54 AM |
|
UserA has a balance of 50 tmsc UserA sends a offer to sell 30 tmsc UserB sends a purchase offer 10 tmsc (not yet paid) UserA changes sell offer to 5 tmsc
What is the maximum tmsc can UserA simple send to UserC?
35 = 50 - 10 - 5 40 = 50 - 10
|
|
|
|
|
|
|
|
|
Bitcoin mining is now a specialized and very risky industry, just like gold mining. Amateur miners are unlikely to make much money, and may even lose money. Bitcoin is much more than just mining, though!
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
Super T
|
|
December 19, 2013, 08:37:07 AM |
|
UserA has a balance of 50 tmsc UserA sends a offer to sell 30 tmsc UserB sends a purchase offer 10 tmsc (not yet paid) UserA changes sell offer to 5 tmsc
What is the maximum tmsc can UserA simple send to UserC?
35 = 50 - 10 - 5 40 = 50 - 10
Thinking about this from a users perspective - the answer has to be 40, the protocol needs to ensure that an attempt to reduce liability cannot result in increasing it. Following on - the protocol would need to ensure that the adjusted offer is recognised reserved based on the initial purchase offer, and as fulfilled once the initial purchase offer is fulfilled.
|
|
|
|
StarenseN
Legendary
Offline
Activity: 2478
Merit: 1362
|
|
December 19, 2013, 05:47:20 PM |
|
Perhaps it's time to summon the magical being known as J.R. and let him make a decision on whether to p&r transactions that have unequal output amounts.
<aTriz beats on his drums!>.... LoL this become creepy... Come on J.R. you can do it.
|
|
|
|
dacoinminster (OP)
Legendary
Offline
Activity: 1260
Merit: 1031
Rational Exuberance
|
|
December 19, 2013, 06:09:42 PM |
|
Good point, I've been focusing too much on the section below that (where p&d is described). JR (I assume) changed the wording when merging the appendix and made it: Ideally, all outputs should be the same (except the change). The term 'ideally' implies that it's not enforced. My appendix as submitted didn't have the word 'ideally' in it so I thought I'd forgotten something somewhere and JR had added the term to show that it wasn't an enforceable requirement. It's all starting to blur together have we had a conversation already about allowing/disallowing based on whether output amounts are the same? Thanks! Perhaps it's time to summon the magical being known as J.R. and let him make a decision on whether to p&r transactions that have unequal output amounts.
<begins chanting>...
<aTriz beats on his drums!>....
LoL this become creepy... Come on J.R. you can do it.
You guys are funny. Sorry, I got way behind on email. Yeah, I added the word "ideally". I was thinking that if the user is trying to do a Mastercoin transaction, and we can easily decode their intent, we should try to honor what they were trying to do. HOWEVER, Class B transactions are only ever generated by Mastercoin clients, so it should be no problem to enforce stricter rules for them. In summary, I think we should allow different amounts for class A, but not class B (or class C). We may need a change to the spec to clarify this. Now, on to a much more important point: my periods of unavailability should not slow down this project. In the future, I'd like you guys to look to Tachikoma to make the final decision on points of interpretation of the spec (after giving everyone an opportunity to weigh in). If he says "let's ask J.R.", just remind him that J.R. put him in charge. I will definitely weigh in on big/controversial changes, but this is not one, in my opinion, and we can't have you guys waiting on me! For instance, I will be on vacation and (mostly) offline 12/21 through 1/5, and therefore even LESS responsive than usual (plus it will probably take me a long time to catch up on email even once I am back). For instance, if Tachikoma disagrees with my opinion above about class A/B/C, you can just go with what he says. The most important thing is that the implementations match, and that you don't have to wait for me. Lastly, if you do need my attention for something, a direct email tends to get read and processed a lot quicker than forum post email notifications do. My email is: jr (dot) willett (at) gmail (dot) com Thanks guys. Sorry for the long delay.
|
|
|
|
DGulari
Legendary
Offline
Activity: 1386
Merit: 1000
KawBet.com - Anonymous Bitcoin Casino & Sportsbook
|
|
December 19, 2013, 09:27:19 PM |
|
and therefore even LESS responsive than usual... sorry, not possible. jk Pretty funny solution: "Don't wait for me, Tachi calls it". This is good because it favors progress. If the decision is horrible, it can probably be retracted in the future, but 'waiting around' is the worse possible plan. So, after a bit of debate - just pick 'A', or 'B' and move on - all the while JR is in the carribbean smoking a fat blunt on his new found wealth. I wouldn't want to be bother either if I was sitting on 258 billion dollars - "get back to work Tachikoma!!!"
|
|
|
|
Tachikoma
|
|
December 19, 2013, 09:46:58 PM |
|
UserA has a balance of 50 tmsc
A: Balance 50 UserA sends a offer to sell 30 tmsc
A: Balance 20 - Reserved 30 UserB sends a purchase offer 10 tmsc (not yet paid)
A: Balance 20 - Reserved 20 - Reserved for Purchase Offer 10 UserA changes sell offer to 5 tmsc
A: Balance 35 - Reserved 5 - Reserved for Purchase Offer 10 What is the maximum tmsc can UserA simple send to UserC?
The maximal amount user A can send is 20 tMSC. Once the Purchase Offer expires the amount will be changed to 30. A lot of stuff J.R. said.
Thanks for the endorsement J.R. I had a very long and intensive day, which is on-going, so I will see what should be decided on the p&d stuff tomorrow
|
|
|
|
DGulari
Legendary
Offline
Activity: 1386
Merit: 1000
KawBet.com - Anonymous Bitcoin Casino & Sportsbook
|
|
December 19, 2013, 09:54:45 PM |
|
Thanks for the endorsement J.R. I had a very long and intensive day, which is on-going, so I will see what should be decided on the p&d stuff tomorrow Hey buddy, I'll send hookers, pizza and cocaine if it will help. Just get your head right and get back in the fight.
|
|
|
|
Tachikoma
|
|
December 20, 2013, 12:55:01 PM |
|
Ok so I think we should allow p&d for unequal outputs.
I think it's better to support as much Class A transactions as possible and that the risks of perhaps misinterpreting, which might not ever happen, outweighs the amount of transactions that can be valid through p&d.
I will write up a pull request over the weekend that covers all bases to support this so we can have a final ook at it but I think it should be fine.
|
|
|
|
aTriz
|
|
December 22, 2013, 04:12:49 AM |
|
Can't wait to do some more windows testing, keep up the great work Tachikoma, zathras, and Bitoy!
Free bump D:
|
|
|
|
Bitoy
|
|
December 22, 2013, 08:08:26 AM |
|
UserA has a balance of 50 tmsc
A: Balance 50 UserA sends a offer to sell 30 tmsc
A: Balance 20 - Reserved 30 UserB sends a purchase offer 10 tmsc (not yet paid)
A: Balance 20 - Reserved 20 - Reserved for Purchase Offer 10 UserA changes sell offer to 5 tmsc
A: Balance 35 - Reserved 5 - Reserved for Purchase Offer 10 What is the maximum tmsc can UserA simple send to UserC?
The maximal amount user A can send is 20 tMSC. Once the Purchase Offer expires the amount will be changed to 30. The maximum amount userA can send is 35 (since 5 and 10 are withheld from the 50 balance). When the purchase offer expires it max is 45.
|
|
|
|
Super T
|
|
December 22, 2013, 08:55:14 AM Last edit: December 22, 2013, 09:06:44 AM by Super T |
|
UserA has a balance of 50 tmsc
A: Balance 50 UserA sends a offer to sell 30 tmsc
A: Balance 20 - Reserved 30 UserB sends a purchase offer 10 tmsc (not yet paid)
A: Balance 20 - Reserved 20 - Reserved for Purchase Offer 10 UserA changes sell offer to 5 tmsc
A: Balance 35 - Reserved 5 - Reserved for Purchase Offer 10 What is the maximum tmsc can UserA simple send to UserC?
The maximal amount user A can send is 20 tMSC. Once the Purchase Offer expires the amount will be changed to 30. The maximum amount userA can send is 35 (since 5 and 10 are withheld from the 50 balance). When the purchase offer expires it max is 45. Bitoy - this doesn't seem right to me, it seems like this approach could end up harming users. To frame this example using slightly different values: 1. UserA has 50 MSC (Balance 50) 2. UserA lists 30 MSC for sale (Balance 20 available, 30 reserved) 3. UserB sends purchase offer for all 30 MSC (Balance 20 available, 30 reserved for purchase offer) 4. UserA changes offer to 20 MSC for sale (Balance TBC1 available, TBC2 reserved, 30 reserved for purchase offer) 5. UserC sends purchase offer for 20 MSC (Balance TBC3 available, TBC4 reserved, TBC5 reserved for purchase offer) So UserA has attempted to reduce the size of a listed offer, this can't be allowed to result in a scenario in which the revised offer is treated as new and unreserved (and could result in all 50 of UserA's coins being sold). The amount remaining available to UserA should be: Unsold balance - the greater of (all reserved purchases OR the revised offer amount). So in the example above: 1. UserA has 50 MSC (Balance 50) 2. UserA lists 30 MSC for sale (Balance 20 available, 30 reserved) 3. UserB sends purchase offer for all 30 MSC (Balance 20 available, 30 reserved for purchase offer) 4. UserA changes offer to 20 MSC for sale (Balance 20 available, 30 reserved, 30 reserved for purchase offer) 5. UserC sends purchase offer for 20 MSC (Balance 20 available, 30 reserved, 30 reserved for purchase offer) Now - what if UserA was actually trying to sell the other 20 MSC? I would expect them to increase the sell offer to 50 (although we still need to be sure this interpreted as an adjustment and not another 50, which is quite possible the same problem in reverse!). Does this make any sense? Cheers
|
|
|
|
Tachikoma
|
|
December 22, 2013, 10:40:13 AM |
|
UserA has a balance of 50 tmsc
A: Balance 50 UserA sends a offer to sell 30 tmsc
A: Balance 20 - Reserved 30 UserB sends a purchase offer 10 tmsc (not yet paid)
A: Balance 20 - Reserved 20 - Reserved for Purchase Offer 10 UserA changes sell offer to 5 tmsc
A: Balance 35 - Reserved 5 - Reserved for Purchase Offer 10 What is the maximum tmsc can UserA simple send to UserC?
The maximal amount user A can send is 20 tMSC. Once the Purchase Offer expires the amount will be changed to 30. The maximum amount userA can send is 35 (since 5 and 10 are withheld from the 50 balance). When the purchase offer expires it max is 45. Yes you are right, I made a mistake there UserA has a balance of 50 tmsc
A: Balance 50 UserA sends a offer to sell 30 tmsc
A: Balance 20 - Reserved 30 UserB sends a purchase offer 10 tmsc (not yet paid)
A: Balance 20 - Reserved 20 - Reserved for Purchase Offer 10 UserA changes sell offer to 5 tmsc
A: Balance 35 - Reserved 5 - Reserved for Purchase Offer 10 What is the maximum tmsc can UserA simple send to UserC?
The maximal amount user A can send is 20 tMSC. Once the Purchase Offer expires the amount will be changed to 30. The maximum amount userA can send is 35 (since 5 and 10 are withheld from the 50 balance). When the purchase offer expires it max is 45. Bitoy - this doesn't seem right to me, it seems like this approach could end up harming users. To frame this example using slightly different values: 1. UserA has 50 MSC (Balance 50) 2. UserA lists 30 MSC for sale (Balance 20 available, 30 reserved) 3. UserB sends purchase offer for all 30 MSC (Balance 20 available, 30 reserved for purchase offer) 4. UserA changes offer to 20 MSC for sale (Balance TBC1 available, TBC2 reserved, 30 reserved for purchase offer) 5. UserC sends purchase offer for 20 MSC (Balance TBC3 available, TBC4 reserved, TBC5 reserved for purchase offer) So UserA has attempted to reduce the size of a listed offer, this can't be allowed to result in a scenario in which the revised offer is treated as new and unreserved (and could result in all 50 of UserA's coins being sold). The amount remaining available to UserA should be: Unsold balance - the greater of (all reserved purchases OR the revised offer amount). So in the example above: 1. UserA has 50 MSC (Balance 50) 2. UserA lists 30 MSC for sale (Balance 20 available, 30 reserved) 3. UserB sends purchase offer for all 30 MSC (Balance 20 available, 30 reserved for purchase offer) 4. UserA changes offer to 20 MSC for sale (Balance 20 available, 30 reserved, 30 reserved for purchase offer) 5. UserC sends purchase offer for 20 MSC (Balance 20 available, 30 reserved, 30 reserved for purchase offer) Now - what if UserA was actually trying to sell the other 20 MSC? I would expect them to increase the sell offer to 50 (although we still need to be sure this interpreted as an adjustment and not another 50, which is quite possible the same problem in reverse!). Does this make any sense? Cheers Just like with Bitcoin all sales are final. If you broadcast a Selling Offer for 50 MSC by error while you only wanted to sell 20 MSC you should just broadcast a new offer as soon as possible hoping that you are added to the block first. That is if I understood you correctly
|
|
|
|
Tachikoma
|
|
December 22, 2013, 10:49:59 AM |
|
Developers, I just made a pull request to change some things that should make way for always falling back on p&d. The changes are minimal so please see if I caught everything. The pull is here.
|
|
|
|
|
Bitoy
|
|
December 23, 2013, 12:57:11 PM |
|
The transaction has the following output. 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P - (Unspent) 0.0000543 BTC 18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji - (Unspent) 0.0000543 BTC 18292miT6bBoZ4d5PAkjuwyMxktDep3h7h - (Unspent) 0.0000543 BTC 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL - (Unspent) 0.0000543 BTC Removing the exodus and sender address, only 2 address is left. 18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji 18292miT6bBoZ4d5PAkjuwyMxktDep3h7h Using peek and decode, one address is the data (simple send). The remaining address is the recipient.
|
|
|
|
Bitoy
|
|
December 23, 2013, 01:03:56 PM |
|
Bitoy - this doesn't seem right to me, it seems like this approach could end up harming users.
To frame this example using slightly different values:
1. UserA has 50 MSC (Balance 50)
2. UserA lists 30 MSC for sale (Balance 20 available, 30 reserved)
3. UserB sends purchase offer for all 30 MSC (Balance 20 available, 30 reserved for purchase offer)
4. UserA changes offer to 20 MSC for sale (Balance TBC1 available, TBC2 reserved, 30 reserved for purchase offer)
5. UserC sends purchase offer for 20 MSC (Balance TBC3 available, TBC4 reserved, TBC5 reserved for purchase offer)
So UserA has attempted to reduce the size of a listed offer, this can't be allowed to result in a scenario in which the revised offer is treated as new and unreserved (and could result in all 50 of UserA's coins being sold).
The amount remaining available to UserA should be: Unsold balance - the greater of (all reserved purchases OR the revised offer amount).
So in the example above:
1. UserA has 50 MSC (Balance 50)
2. UserA lists 30 MSC for sale (Balance 20 available, 30 reserved)
3. UserB sends purchase offer for all 30 MSC (Balance 20 available, 30 reserved for purchase offer)
4. UserA changes offer to 20 MSC for sale (Balance 20 available, 30 reserved, 30 reserved for purchase offer)
5. UserC sends purchase offer for 20 MSC (Balance 20 available, 30 reserved, 30 reserved for purchase offer)
Now - what if UserA was actually trying to sell the other 20 MSC? I would expect them to increase the sell offer to 50 (although we still need to be sure this interpreted as an adjustment and not another 50, which is quite possible the same problem in reverse!).
Does this make any sense? Cheers
You have a point Super T. What if the seller accidentally entered 50 for sale but only wanted 20. But by design a seller can only have one sell offer. He has to immediately send a sale offer of 20 in order to cancel his 50 (as Tachikoma pointed out) and hopes it gets confirmed first before any purchase offers.
|
|
|
|
nmak
Newbie
Offline
Activity: 30
Merit: 0
|
|
December 23, 2013, 03:54:09 PM |
|
Thanks for the endorsement J.R. I had a very long and intensive day, which is on-going, so I will see what should be decided on the p&d stuff tomorrow Hey buddy, I'll send hookers, pizza and cocaine if it will help. Just get your head right and get back in the fight. lol I like this guy. Ha ha. Go for it tach, honestly wish I had done programming instead of system support.
|
|
|
|
grazcoin
|
|
December 23, 2013, 04:38:04 PM |
|
The transaction has the following output. 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P - (Unspent) 0.0000543 BTC 18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji - (Unspent) 0.0000543 BTC 18292miT6bBoZ4d5PAkjuwyMxktDep3h7h - (Unspent) 0.0000543 BTC 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL - (Unspent) 0.0000543 BTC Removing the exodus and sender address, only 2 address is left. 18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji 18292miT6bBoZ4d5PAkjuwyMxktDep3h7h Using peek and decode, one address is the data (simple send). The remaining address is the recipient. Why are you removing the sender address from the outputs? There is nothing mentioning removal of such an address from the outputs of a basic simple send in the spec. Normally there isn't any sender address among the outputs of basic simple send , e.g. (some other basic simple send): https://blockchain.info/tx/feb9c1c2f1b274391275a2e92a6007397e087ba5d29ea896098c21d7400cd026and if there is - it is either the recipient or the change. Checking the sequence numbers of the outputs: 18292miT6bBoZ4d5PAkjuwyMxktDep3h7h [77] 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL [77] 18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji [78] so there is ambiguity in the sequence numbers, and we have to peek. peek and decode shows that 18292miT6bBoZ4d5PAkjuwyMxktDep3h7h is the data. But my parsing still says the recipient is 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL EDIT: masterchest invalidates this transaction, which is also an option. You can see that it is not part of the list: https://masterchest.info/lookupadd.aspx?address=182osbPxCo88oaSX4ReJwUr9uAcchmJVaL
|
|
|
|
Bitoy
|
|
December 24, 2013, 10:41:16 AM |
|
Why are you removing the sender address from the outputs? There is nothing mentioning removal of such an address from the outputs of a basic simple send in the spec. Normally there isn't any sender address among the outputs of basic simple send , e.g. (some other basic simple send): https://blockchain.info/tx/feb9c1c2f1b274391275a2e92a6007397e087ba5d29ea896098c21d7400cd026and if there is - it is either the recipient or the change. Checking the sequence numbers of the outputs: 18292miT6bBoZ4d5PAkjuwyMxktDep3h7h [77] 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL [77] 18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji [78] so there is ambiguity in the sequence numbers, and we have to peek. peek and decode shows that 18292miT6bBoZ4d5PAkjuwyMxktDep3h7h is the data. But my parsing still says the recipient is 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL EDIT: masterchest invalidates this transaction, which is also an option. You can see that it is not part of the list: https://masterchest.info/lookupadd.aspx?address=182osbPxCo88oaSX4ReJwUr9uAcchmJVaLI removed the sender's address from the output because its not logical for a sender to send msc to himself. (If he did then the transaction will be invalid because there will be no recipient address.). However your implementation looks correct also because the sequence number of the data is 77 and the so the recipient address should have a sequence of 78. Which is the sender's address. I think we need to clarify this with Tachikoma.
|
|
|
|
grazcoin
|
|
December 24, 2013, 11:16:22 AM |
|
Why are you removing the sender address from the outputs? There is nothing mentioning removal of such an address from the outputs of a basic simple send in the spec. Normally there isn't any sender address among the outputs of basic simple send , e.g. (some other basic simple send): https://blockchain.info/tx/feb9c1c2f1b274391275a2e92a6007397e087ba5d29ea896098c21d7400cd026and if there is - it is either the recipient or the change. Checking the sequence numbers of the outputs: 18292miT6bBoZ4d5PAkjuwyMxktDep3h7h [77] 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL [77] 18ArFG8cPDT5P8NVdjFuSGjkybRTW8VBji [78] so there is ambiguity in the sequence numbers, and we have to peek. peek and decode shows that 18292miT6bBoZ4d5PAkjuwyMxktDep3h7h is the data. But my parsing still says the recipient is 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL EDIT: masterchest invalidates this transaction, which is also an option. You can see that it is not part of the list: https://masterchest.info/lookupadd.aspx?address=182osbPxCo88oaSX4ReJwUr9uAcchmJVaLI removed the sender's address from the output because its not logical for a sender to send msc to himself. (If he did then the transaction will be invalid because there will be no recipient address.). However your implementation looks correct also because the sequence number of the data is 77 and the so the recipient address should have a sequence of 78. Which is the sender's address. I think we need to clarify this with Tachikoma. I see absolutely no problem with sending coins to oneself. A restriction on such a send is no where in the spec (and in my opinion - shouldn't be). Also in bitcoins, one can send to himself. Even our protocol uses bitcoin's feature of sending to one self (change).
|
|
|
|
|