|
|
|
|
dexX7
Legendary
 Offline
Activity: 1106
Merit: 1024
|
 |
March 08, 2014, 03:24:44 PM |
|
|
|
|
|
|
grazcoin
|
|
March 08, 2014, 05:48:28 PM |
|
If you select before TMSC (on the left on large browsers or bottom on mobile), you will get the currency you chose. Anyway, I rolled back to previous version as the migration from my test setup to the production had some issues. I will try again in 1-2h. |
|
|
|
dexX7
Legendary
Offline
Activity: 1106
Merit: 1024
|
|
March 08, 2014, 07:58:29 PM |
|
If you select before TMSC (on the left on large browsers or bottom on mobile), you will get the currency you chose.
On all other pages yes, but not on sellaccept.html. |
|
|
|
|
|
|
grazcoin
|
|
March 09, 2014, 11:33:29 AM |
|
If you select before TMSC (on the left on large browsers or bottom on mobile), you will get the currency you chose. Anyway, I rolled back to previous version as the migration from my test setup to the production had some issues. I will try again in 1-2h. The "multi payment for accept" version (with a minor fix) is again online. |
|
|
|
dexX7
Legendary
Offline
Activity: 1106
Merit: 1024
|
|
March 09, 2014, 02:46:11 PM |
|
Can you give me an example where it doesn't work? That was on a sellaccept page, when clicking on an address link. Tested all pages a few minutes ago, the only one left is btcpayment when clicking on an address. Example: https://masterchain.info/btcpayment.html?tx=aa799134259de13c1249b2c538d32103eec9d0327f1c82195409a75c6a215180¤cy=TMSCTo 1EXoDusjGw...: https://masterchain.info/Address.html?addr=1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4PTo 1HG3s4Ext3...: https://masterchain.info/Address.html?addr=1HG3s4Ext3sTqBTHrgftyUzG3cvx5ZbPCjTo 1LifmeXYHe...: https://masterchain.info/Address.html?addr=1LifmeXYHeUe2qdKWBGVwfbUCMMrwYtoMmThe payment was a BTC payment for TMSC. -- On a different topic: Say, I have four pubkeys, two of them are encoded Mastercoin data packages, one is the known input pubKey and one is random junk. I know which one is the input pubKey, but I don't know the order of the data packages: Encrypted 1: 02 8d7a29f02b6807292449947137181ae63fb60b3b1cd83bb19f0a44a8cb7fd1 68
Encrypted 2: 02 43a6b4397e00daafe0d7a76383e6808afa085577a3b8f1688279e6bea87260 70
Encrypted 3: 02 1cbdde253bea7b5ddee99b269ae74042ed6dd962efcb5ecb70973e14a86870 93 < input pubKey, pubKeyHash: 1HG3s4Ext3sTqBTHrgftyUzG3cvx5ZbPCj
Encrypted 4: 02 989a78ab3a2e8fbaa5f6003825eddaada19103096ffc5a6c01eff61779091e 49
SHA256 round #1 on pubKeyHash:
Hash 1: 999a79ab2e2e8fbaa7f6003825eddaada09103096ffc5a6c00eef61779091e 66
SHA256 round #2 on UpperCase(SHA256(pubKeyHash)):
Hash 2: 41a6b4387d00daafe0d7a76383e6808afa085577a3b8f1688279e6bea87260 a0
I could mix all encrypted with all hashes, but is this the only way and is it unamigious? Hash 1 ^ Encrypted 1: 14e0505b0546889383bf944912f5c0
Hash 1 ^ Encrypted 2: da3ccd92502e55154721a75ba60b5a
Hash 1 ^ Encrypted 3: -- E3 is the known pubKey
Hash 1 ^ Encrypted 4: 010001001400000002000000000000
Hash 2 ^ Encrypted 1: ccdc9dc85668dd86c49e3312b4fe9a
Hash 2 ^ Encrypted 2: 020000010300000000000000000000
Hash 2 ^ Encrypted 3: -- E3 is the known pubKey
Hash 2 ^ Encrypted 4: d93ccc93472e55154521a75ba60b5a
What is the fastest way to determine the order of the packages without mixing them all and testing, if they are valid? Is it possible to allow junk at the same time? |
|
|
|
|
grazcoin
|
|
March 09, 2014, 05:30:39 PM |
|
updated. now all links from btcpayment include the currency variable. |
|
|
|
|
grazcoin
|
|
March 09, 2014, 11:52:55 PM |
|
Deep DEx tesingWe were already touching consensus for a short while, so I decided to challenge the implementations with complicated scenario that covers multiple payments and reserve left overs of running accepts after sell offer update. Let's see if we keep the consensus. This is the description of my test: 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX creates a sell offer for 0.1 TMSC at a price of 0.1 B/TMSC https://masterchain.info/selloffer.html?tx=ccc6c0ed758c42a950b1f54956d74db0a84783908fe41427a540b1221f5887e5¤cy=TMSCThere are 2 accepts that happen in the same block (all from 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL) 0.025 https://masterchain.info/sellaccept.html?tx=8e12e87dc2a04f10115726dfe385b6744b8721bc4ffc08a6e1089c5c22271897¤cy=TMSC0.04 https://masterchain.info/sellaccept.html?tx=263b7c420b2456b3f04eea4d92ddf35b95703859173a321c9fdeb71e6c1f5328¤cy=TMSCFor the first accept (0.25), 3 payments are done: 0.0005 BTC (for 0.005 TMSC) https://masterchain.info/btcpayment.html?tx=42f470a5c00be4e434055fd63515d14d7fdd6d96e0eedea6a494620a5818554b¤cy=TMSC0.001 BTC (for 0.01 TMSC) https://masterchain.info/btcpayment.html?tx=36ef617e944bfad6b5d43f9faccc8ead27c33d54e07f2793fe13f1980846488b¤cy=TMSC0.002 BTC (for 0.01 TMSC - that's all which is left on that accept) https://masterchain.info/btcpayment.html?tx=df3b38afcfc1fe20d065d58e5d02360d9150e0e1d9f5f7691c33d84c07e3acc4¤cy=TMSCTotal bought is the full 0.025 TMSC of that accept. Another accept for 0.05 TMSC - the 3rd one (from the original 0.1 TMSC, 0.025+0.04 are accepted, which leaves 0.035 available). https://masterchain.info/sellaccept.html?tx=9ecd7a40eba06ea554fa42dadca1c4c94dc301040d656484a85c45d68d80963a¤cy=TMSCA payment of 0.03 BTC. Since the first accept is fully paid, the next accept should be associated with this payment, so: Partial payment for the 0.04 accept (only 0.03 out of 0.04 got paid). http://masterchain.info/btcpayment.html?tx=5eea7fcad063871ece3404237fb2b5d66cf79b51e371c2f8aef6e7061aacd197¤cy=TMSC0.03 TMSC bought. Another payment 0f 0.05 BTC: Since the second accept (of 0.04) was not fully paid, this payment goes to that accept https://masterchain.info/btcpayment.html?tx=8c61c5e7903f82908b18cbcc83681834c2b299f1c80cffa39d42e946da6c2a72¤cy=TMSC0.01 TMSC bought (should have been enough for 0.05, but that's all which is left on the second accept, leaving the 3rd accept unpaid). Update sell offer to 0.123 TMSC with a price of 0.123 B/TMSC and payment timeframe of 50 blocks. https://masterchain.info/selloffer.html?tx=840b4fdda8a13efa13555d7f2d5eab03c894f53b138d757111661cbbffde7231¤cy=TMSCAt this point, there is the 3rd 0.05 accept still open (for 100 blocks) which requires reserve of 0.35 TMSC (as only 0.35 of the 0.5 were actually available at the time of the accept), and there is the new sell offer of 0.123 TMSC, so a total reserve of 0.158 should be kept, leaving available balance of 0.477111 TMSC. simple send of 0.500111 TMSC from the seller 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX https://masterchain.info/simplesend.html?tx=d173a8b6ed41b20ed225124d79a5307923f3f703b7e511deefba9bcdf70d59dc¤cy=TMSCThis transaction should be invalidated due to "balance too low".
|
|
|
|
|
zathras
|
|
March 10, 2014, 02:53:56 AM |
|
Graz, not sure if you're around but Bitoy & I are on IRC now if you want to jump in & discuss consensus  |
|
|
|
|
zathras
|
|
March 10, 2014, 03:05:44 AM |
|
Deep DEx tesingWe were already touching consensus for a short while, so I decided to challenge the implementations with complicated scenario that covers multiple payments and reserve left overs of running accepts after sell offer update. Let's see if we keep the consensus. This is the description of my test: 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX creates a sell offer for 0.1 TMSC at a price of 0.1 B/TMSC https://masterchain.info/selloffer.html?tx=ccc6c0ed758c42a950b1f54956d74db0a84783908fe41427a540b1221f5887e5¤cy=TMSCThere are 2 accepts that happen in the same block (all from 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL) 0.025 https://masterchain.info/sellaccept.html?tx=8e12e87dc2a04f10115726dfe385b6744b8721bc4ffc08a6e1089c5c22271897¤cy=TMSC0.04 https://masterchain.info/sellaccept.html?tx=263b7c420b2456b3f04eea4d92ddf35b95703859173a321c9fdeb71e6c1f5328¤cy=TMSCFor the first accept (0.25), 3 payments are done: 0.0005 BTC (for 0.005 TMSC) https://masterchain.info/btcpayment.html?tx=42f470a5c00be4e434055fd63515d14d7fdd6d96e0eedea6a494620a5818554b¤cy=TMSC0.001 BTC (for 0.01 TMSC) https://masterchain.info/btcpayment.html?tx=36ef617e944bfad6b5d43f9faccc8ead27c33d54e07f2793fe13f1980846488b¤cy=TMSC0.002 BTC (for 0.01 TMSC - that's all which is left on that accept) https://masterchain.info/btcpayment.html?tx=df3b38afcfc1fe20d065d58e5d02360d9150e0e1d9f5f7691c33d84c07e3acc4¤cy=TMSCTotal bought is the full 0.025 TMSC of that accept. Another accept for 0.05 TMSC - the 3rd one (from the original 0.1 TMSC, 0.025+0.04 are accepted, which leaves 0.035 available). https://masterchain.info/sellaccept.html?tx=9ecd7a40eba06ea554fa42dadca1c4c94dc301040d656484a85c45d68d80963a¤cy=TMSCA payment of 0.03 BTC. Since the first accept is fully paid, the next accept should be associated with this payment, so: Partial payment for the 0.04 accept (only 0.03 out of 0.04 got paid). http://masterchain.info/btcpayment.html?tx=5eea7fcad063871ece3404237fb2b5d66cf79b51e371c2f8aef6e7061aacd197¤cy=TMSC0.03 TMSC bought. Another payment 0f 0.05 BTC: Since the second accept (of 0.04) was not fully paid, this payment goes to that accept https://masterchain.info/btcpayment.html?tx=8c61c5e7903f82908b18cbcc83681834c2b299f1c80cffa39d42e946da6c2a72¤cy=TMSC0.01 TMSC bought (should have been enough for 0.05, but that's all which is left on the second accept, leaving the 3rd accept unpaid). Update sell offer to 0.123 TMSC with a price of 0.123 B/TMSC and payment timeframe of 50 blocks. https://masterchain.info/selloffer.html?tx=840b4fdda8a13efa13555d7f2d5eab03c894f53b138d757111661cbbffde7231¤cy=TMSCAt this point, there is the 3rd 0.05 accept still open (for 100 blocks) which requires reserve of 0.35 TMSC (as only 0.35 of the 0.5 were actually available at the time of the accept), and there is the new sell offer of 0.123 TMSC, so a total reserve of 0.158 should be kept, leaving available balance of 0.477111 TMSC. simple send of 0.500111 TMSC from the seller 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX https://masterchain.info/simplesend.html?tx=d173a8b6ed41b20ed225124d79a5307923f3f703b7e511deefba9bcdf70d59dc¤cy=TMSCThis transaction should be invalidated due to "balance too low". Brings up another interesting question that needs to be answered - can a buyer have multiple 'accept offers' to the same seller open at the same time? There (iirc) is nothing in the spec that says you can, or that you can't. I actually haven't coded for that scenario at all, I'll have a look through your test case to see how Masterchest has handled it. At first thought I think it adds unncessesary complexity (allowing multiple accepts from the same buyer at the same time - for example we then need to explicitly define in what order/how bitcoin payments are applied to which accept) - but I haven't looked at it deeply. J.R. - can we get a ruling? Multiple 'accept offers' from the same buyer to the same seller open simultaneously. Yay or nay? FYI: * Graz (assuming from the above) allows multiple accept offers from the same buyer, unsure how applies payments * Bitoy allows multiple accept offers from the same buyer, and applies payment to the first accept until paid, then to the next accept until paid and so on. But only for whole payments, so if the first payment did not fully pay the first accept, the second payment would be applied to the first accept and any remaining would be an overpayment and not applied to the next accept offer. * Masterchest hasn't factored for multiple accept offers one way or the other - will need to evaluate behaviour |
|
|
|
|
grazcoin
|
|
March 10, 2014, 06:40:58 AM |
|
Deep DEx tesingWe were already touching consensus for a short while, so I decided to challenge the implementations with complicated scenario that covers multiple payments and reserve left overs of running accepts after sell offer update. Let's see if we keep the consensus. This is the description of my test: 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX creates a sell offer for 0.1 TMSC at a price of 0.1 B/TMSC https://masterchain.info/selloffer.html?tx=ccc6c0ed758c42a950b1f54956d74db0a84783908fe41427a540b1221f5887e5¤cy=TMSCThere are 2 accepts that happen in the same block (all from 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL) 0.025 https://masterchain.info/sellaccept.html?tx=8e12e87dc2a04f10115726dfe385b6744b8721bc4ffc08a6e1089c5c22271897¤cy=TMSC0.04 https://masterchain.info/sellaccept.html?tx=263b7c420b2456b3f04eea4d92ddf35b95703859173a321c9fdeb71e6c1f5328¤cy=TMSCFor the first accept (0.25), 3 payments are done: 0.0005 BTC (for 0.005 TMSC) https://masterchain.info/btcpayment.html?tx=42f470a5c00be4e434055fd63515d14d7fdd6d96e0eedea6a494620a5818554b¤cy=TMSC0.001 BTC (for 0.01 TMSC) https://masterchain.info/btcpayment.html?tx=36ef617e944bfad6b5d43f9faccc8ead27c33d54e07f2793fe13f1980846488b¤cy=TMSC0.002 BTC (for 0.01 TMSC - that's all which is left on that accept) https://masterchain.info/btcpayment.html?tx=df3b38afcfc1fe20d065d58e5d02360d9150e0e1d9f5f7691c33d84c07e3acc4¤cy=TMSCTotal bought is the full 0.025 TMSC of that accept. Another accept for 0.05 TMSC - the 3rd one (from the original 0.1 TMSC, 0.025+0.04 are accepted, which leaves 0.035 available). https://masterchain.info/sellaccept.html?tx=9ecd7a40eba06ea554fa42dadca1c4c94dc301040d656484a85c45d68d80963a¤cy=TMSCA payment of 0.03 BTC. Since the first accept is fully paid, the next accept should be associated with this payment, so: Partial payment for the 0.04 accept (only 0.03 out of 0.04 got paid). http://masterchain.info/btcpayment.html?tx=5eea7fcad063871ece3404237fb2b5d66cf79b51e371c2f8aef6e7061aacd197¤cy=TMSC0.03 TMSC bought. Another payment 0f 0.05 BTC: Since the second accept (of 0.04) was not fully paid, this payment goes to that accept https://masterchain.info/btcpayment.html?tx=8c61c5e7903f82908b18cbcc83681834c2b299f1c80cffa39d42e946da6c2a72¤cy=TMSC0.01 TMSC bought (should have been enough for 0.05, but that's all which is left on the second accept, leaving the 3rd accept unpaid). Update sell offer to 0.123 TMSC with a price of 0.123 B/TMSC and payment timeframe of 50 blocks. https://masterchain.info/selloffer.html?tx=840b4fdda8a13efa13555d7f2d5eab03c894f53b138d757111661cbbffde7231¤cy=TMSCAt this point, there is the 3rd 0.05 accept still open (for 100 blocks) which requires reserve of 0.35 TMSC (as only 0.35 of the 0.5 were actually available at the time of the accept), and there is the new sell offer of 0.123 TMSC, so a total reserve of 0.158 should be kept, leaving available balance of 0.477111 TMSC. simple send of 0.500111 TMSC from the seller 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX https://masterchain.info/simplesend.html?tx=d173a8b6ed41b20ed225124d79a5307923f3f703b7e511deefba9bcdf70d59dc¤cy=TMSCThis transaction should be invalidated due to "balance too low". Brings up another interesting question that needs to be answered - can a buyer have multiple 'accept offers' to the same seller open at the same time? There (iirc) is nothing in the spec that says you can, or that you can't. I actually haven't coded for that scenario at all, I'll have a look through your test case to see how Masterchest has handled it. At first thought I think it adds unncessesary complexity (allowing multiple accepts from the same buyer at the same time - for example we then need to explicitly define in what order/how bitcoin payments are applied to which accept) - but I haven't looked at it deeply. J.R. - can we get a ruling? Multiple 'accept offers' from the same buyer to the same seller open simultaneously. Yay or nay? FYI: * Graz (assuming from the above) allows multiple accept offers from the same buyer, unsure how applies payments * Bitoy allows multiple accept offers from the same buyer, and applies payment to the first accept until paid, then to the next accept until paid and so on. But only for whole payments, so if the first payment did not fully pay the first accept, the second payment would be applied to the first accept and any remaining would be an overpayment and not applied to the next accept offer. * Masterchest hasn't factored for multiple accept offers one way or the other - will need to evaluate behaviour Indeed multiple accepts from the same address is an open question, but I just did it since I currently hold only 2 addresses. I see no reason to restrict multiple accepts (e.g. one could decide that he wants to buy more), but this we can discuss on a different thread. That was not the main focus of my test. The test DOES checks: 1. Behaviour of multiple payments to multiple accepts (which could be done by different addresses). 2. Correct reserved funds calculation after a sell offer update. Lets verify that the implementations agree on that. |
|
|
|
dexX7
Legendary
Offline
Activity: 1106
Merit: 1024
|
|
March 10, 2014, 09:12:46 AM
Last edit: March 10, 2014, 01:39:30 PM by dexX7 |
|
With Masterchain as reference: Masterchest -PASSED-MyMastercoins -PASSED-Masterchest -FAILED- (shows unit price: 0.46 BTC, total price: 0.0115 BTC) MyMastercoins -PASSED-Masterchest -FAILED- (shows unit price: 0.2875 BTC, total price: 0.0115 BTC) MyMastercoins -PASSED-Masterchest -UNAVAILABLE-MyMastercoins -PASSED-Masterchest -UNAVAILABLE-MyMastercoins -PASSED-Masterchest -UNAVAILABLE-MyMastercoins -PASSED-Masterchest -FAILED- (shows unit price: 0.16 BTC, total price: 0.008 BTC) MyMastercoins -PASSED-Masterchest -UNAVAILABLE-MyMastercoins -PASSED-Masterchest -UNAVAILABLE-MyMastercoins -PASSED-Masterchest -PASSED-MyMastercoins -PASSED-At this point, there is the 3rd 0.05 accept still open (for 100 blocks) which requires reserve of 0.35 TMSC (as only 0.35 of the 0.5 were actually available at the time of the accept), and there is the new sell offer of 0.123 TMSC, so a total reserve of 0.158 should be kept, leaving available balance of 0.477111 TMSC. Masterchain -PASSED- (balance: 0.477111 TMSC, reserved: 0.158 TMSC) Masterchest -FAILED- (balance: 0.462111 TMSC, reserved: 0.0 TMSC) MyMastercoins -FAILED- (balance: 0.512111 TMSC, reserved: 0.123 TMSC -- you're mixing MSC and TMSC here somehow, I think) Masterchest -PASSED-MyMastercoins -PASSED-A click on the explorer name forwards to the transaction.  Previous discussion: Brings up another interesting question that needs to be answered - can a buyer have multiple 'accept offers' to the same seller open at the same time? There (iirc) is nothing in the spec that says you can, or that you can't.
I actually haven't coded for that scenario at all, I'll have a look through your test case to see how Masterchest has handled it. At first thought I think it adds unncessesary complexity (allowing multiple accepts from the same buyer at the same time - for example we then need to explicitly define in what order/how bitcoin payments are applied to which accept) - but I haven't looked at it deeply.
J.R. - can we get a ruling? Multiple 'accept offers' from the same buyer to the same seller open simultaneously. Yay or nay?
FYI:
* Graz (assuming from the above) allows multiple accept offers from the same buyer, unsure how applies payments
* Bitoy allows multiple accept offers from the same buyer, and applies payment to the first accept until paid, then to the next accept until paid and so on. But only for whole payments, so if the first payment did not fully pay the first accept, the second payment would be applied to the first accept and any remaining would be an overpayment and not applied to the next accept offer.
* Masterchest hasn't factored for multiple accept offers one way or the other - will need to evaluate behaviour
Indeed multiple accepts from the same address is an open question, but I just did it since I currently hold only 2 addresses. I see no reason to restrict multiple accepts (e.g. one could decide that he wants to buy more), but this we can discuss on a different thread. That was not the main focus of my test. The test DOES checks: 1. Behaviour of multiple payments to multiple accepts (which could be done by different addresses). 2. Correct reserved funds calculation after a sell offer update. Lets verify that the implementations agree on that. |
|
|
|
|
zathras
|
|
March 10, 2014, 09:46:36 AM
Last edit: March 10, 2014, 10:13:37 AM by zathras |
|
With Masterchain as reference: Masterchest -PASSED-MyMastercoins -PASSED-Masterchest -FAILED- (shows unit price: 0.46 BTC, total price: 0.0115 BTC) MyMastercoins -PASSED-Masterchest -FAILED- (shows unit price: 0.2875 BTC, total price: 0.0115 BTC) MyMastercoins -PASSED-Masterchest -UNAVAILABLE-MyMastercoins -PASSED-Masterchest -UNAVAILABLE-MyMastercoins -PASSED-Masterchest -UNAVAILABLE-MyMastercoins -PASSED-Masterchest -FAILED- (shows unit price: 0.16 BTC, total price: 0.008 BTC) MyMastercoins -PASSED-Masterchest -UNAVAILABLE-MyMastercoins -PASSED-Masterchest -UNAVAILABLE-MyMastercoins -PASSED-Masterchest -PASSED-MyMastercoins -PASSED-At this point, there is the 3rd 0.05 accept still open (for 100 blocks) which requires reserve of 0.35 TMSC (as only 0.35 of the 0.5 were actually available at the time of the accept), and there is the new sell offer of 0.123 TMSC, so a total reserve of 0.158 should be kept, leaving available balance of 0.477111 TMSC. Masterchain -PASSED- (balance: 0.477111 TMSC, reserved: 0.158 TMSC) Masterchest -FAILED- (balance: 0.462111 TMSC, reserved: 0.0 TMSC) MyMastercoins -FAILED- (balance: 0.512111 TMSC, reserved: 0.123 TMSC -- you're mixing MSC and TMSC here somehow, I think) Masterchest -PASSED-MyMastercoins -PASSED-A click on the explorer name forwards to the transaction. Previous discussion: Brings up another interesting question that needs to be answered - can a buyer have multiple 'accept offers' to the same seller open at the same time? There (iirc) is nothing in the spec that says you can, or that you can't.
I actually haven't coded for that scenario at all, I'll have a look through your test case to see how Masterchest has handled it. At first thought I think it adds unncessesary complexity (allowing multiple accepts from the same buyer at the same time - for example we then need to explicitly define in what order/how bitcoin payments are applied to which accept) - but I haven't looked at it deeply.
J.R. - can we get a ruling? Multiple 'accept offers' from the same buyer to the same seller open simultaneously. Yay or nay?
FYI:
* Graz (assuming from the above) allows multiple accept offers from the same buyer, unsure how applies payments
* Bitoy allows multiple accept offers from the same buyer, and applies payment to the first accept until paid, then to the next accept until paid and so on. But only for whole payments, so if the first payment did not fully pay the first accept, the second payment would be applied to the first accept and any remaining would be an overpayment and not applied to the next accept offer.
* Masterchest hasn't factored for multiple accept offers one way or the other - will need to evaluate behaviour
Indeed multiple accepts from the same address is an open question, but I just did it since I currently hold only 2 addresses. I see no reason to restrict multiple accepts (e.g. one could decide that he wants to buy more), but this we can discuss on a different thread. That was not the main focus of my test. The test DOES checks: 1. Behaviour of multiple payments to multiple accepts (which could be done by different addresses). 2. Correct reserved funds calculation after a sell offer update. Lets verify that the implementations agree on that. Thanks guys, but this test is confused by the fact the multiple accepts were done from the same address. Masterchest is not coded to handle this (in fact the logic of allowing multiple accepts from the same buyer would be quite a shift in approach to the way I currently do things). Also FYI I've pushed an update out to Masterchest.info tonight that should take into account some of the recent discussion about how we calculate unit price etc. Thanks Zathras |
|
|
|
|
grazcoin
|
|
March 10, 2014, 11:33:06 AM |
|
At this point, there is the 3rd 0.05 accept still open (for 100 blocks) which requires reserve of 0.35 TMSC (as only 0.35 of the 0.5 were actually available at the time of the accept), and there is the new sell offer of 0.123 TMSC, so a total reserve of 0.158 should be kept, leaving available balance of 0.477111 TMSC. Masterchain -PASSED- (balance: 0.477111 TMSC, reserved: 0.158 TMSC) Masterchest -FAILED- (balance: 0.462111 TMSC, reserved: 0.0 TMSC) MyMastercoins -FAILED- (balance: 0.512111 TMSC, reserved: 0.123 TMSC -- you're mixing MSC and TMSC here somehow, I think) I think mymastercoins just didn't reserve funds for the running accept from the older sell offer - only reserved the 0.123 of the new offer. But it is fixed now, isn't it (or the accept simply expired?) |
|
|
|
|
Bitoy
|
|
March 10, 2014, 11:44:05 AM |
|
At this point, there is the 3rd 0.05 accept still open (for 100 blocks) which requires reserve of 0.35 TMSC (as only 0.35 of the 0.5 were actually available at the time of the accept), and there is the new sell offer of 0.123 TMSC, so a total reserve of 0.158 should be kept, leaving available balance of 0.477111 TMSC. Masterchain -PASSED- (balance: 0.477111 TMSC, reserved: 0.158 TMSC) Masterchest -FAILED- (balance: 0.462111 TMSC, reserved: 0.0 TMSC) MyMastercoins -FAILED- (balance: 0.512111 TMSC, reserved: 0.123 TMSC -- you're mixing MSC and TMSC here somehow, I think) I think mymastercoins just didn't reserve funds for the running accept from the older sell offer - only reserved the 0.123 of the new offer. But it is fixed now, isn't it (or the accept simply expired?) Yes MM didn't reserve the funds for the .5 tmsc reserve. I've fixed this in the test server. Will update it within the day. |
|
|
|
|
|
Bitoy
|
|
March 10, 2014, 11:52:58 AM |
|
65b106 2/25/2014 9:38:36 PM 287806 Valid Update Offer to Sell: 0.05 TMSC for 0.0006 btc
8e12e8 3/9/2014 8:17:42 PM 289750 Valid Purchase Offer: 0.025 TMSC
263b7c 3/9/2014 8:17:42 PM 289750 Valid Purchase Offer: 0.04 TMSC
42f470 3/9/2014 8:43:46 PM 289755 Valid Payment: 0.0005 btc for 0.005 TMSC
36ef61 3/9/2014 8:43:46 PM 289755 Valid Payment: 0.001 btc for 0.01 TMSC
df3b38 3/9/2014 8:43:46 PM 289755 Valid Payment: 0.002 btc for 0.01 TMSC
9ecd7a 3/9/2014 8:43:46 PM 289755 Valid Purchase Offer: 0.05 TMSC
5eea7f 3/9/2014 9:04:14 PM 289757 Valid Payment: 0.003 btc for 0.03 TMSC
8c61c5 3/9/2014 9:11:50 PM 289761 Valid Payment: 0.005 btc for 0.01 TMSC
8c61c5 is an overpayment of purchase 263b7c
( reserved: 0.173 ( 0.123 + 0.05 ) TMSC available)
|
|
|
|
|
dexX7
Legendary
Offline
Activity: 1106
Merit: 1024
|
|
March 10, 2014, 04:37:11 PM |
|
What happens in the case that I chain multiple transactions from type standard send, e.g.:
1. Addr X sends 0.1 MSC to Addr A, uses whatever available output, change goes back to Addr X
2. Addr X sends 0.1 MSC to Addr B, uses change output of (1), change goes back to Addr X
3. Addr X sends 0.1 MSC to Addr C, uses change output of (2), change goes back to Addr X
4. Addr X sends 0.1 MSC to Addr D, uses change output of (3), change goes back to Addr X
5. Addr X sends 0.1 MSC to Addr E, uses change output of (4), change goes back to Addr X
6. Addr X sends 0.1 MSC to Addr F, uses change output of (5), change goes back to Addr X
7. Addr X sends 0.1 MSC to Addr G, uses change output of (6), change goes back to Addr X
...
And let's further say that Addr A.. G's only source of MSC are those transactions and now they spend some MSC.
The twist: the initial send 1.. 7 may not yet be confirmed, but the send transactions initiated by A.. G may - for whatever reason.
I assume in such a case the sends would be invalid, if the MSC were not available on a blockchain level, because that's all what counts in any case?
|
|
|
|
dacoinminster (OP)
Legendary
Offline
Activity: 1260
Merit: 1031
Rational Exuberance
|
|
March 10, 2014, 05:21:25 PM |
|
Brings up another interesting question that needs to be answered - can a buyer have multiple 'accept offers' to the same seller open at the same time? There (iirc) is nothing in the spec that says you can, or that you can't.
I actually haven't coded for that scenario at all, I'll have a look through your test case to see how Masterchest has handled it. At first thought I think it adds unncessesary complexity (allowing multiple accepts from the same buyer at the same time - for example we then need to explicitly define in what order/how bitcoin payments are applied to which accept) - but I haven't looked at it deeply.
J.R. - can we get a ruling? Multiple 'accept offers' from the same buyer to the same seller open simultaneously. Yay or nay?
FYI:
* Graz (assuming from the above) allows multiple accept offers from the same buyer, unsure how applies payments
* Bitoy allows multiple accept offers from the same buyer, and applies payment to the first accept until paid, then to the next accept until paid and so on. But only for whole payments, so if the first payment did not fully pay the first accept, the second payment would be applied to the first accept and any remaining would be an overpayment and not applied to the next accept offer.
* Masterchest hasn't factored for multiple accept offers one way or the other - will need to evaluate behaviour
Ooooo. Interesting. You're right - I never considered this situation. I think the most intuitive handling of two offers from the same buyer to the same seller is to append them. That is, if the buyer offered to purchase 2 MSC, then 2 more MSC, then their total amount they can buy is actually 4 MSC. I don't think the UI needs to necessarily offer the user the ability to do this, but I don't think it makes sense to prevent it at the protocol level either. Zathras, I hope when you say it would be a big change for you, that you mean it would be a big change to allow this in the UI. I don't think you need to do that as long as Masterchest parses it correctly. We go live with real MSC in 5 days! I think/hope this is the last major issue to iron out? |
|
|
|
|
