Pages:
Author

Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 7. (Read 129207 times)

sr. member
Activity: 266
Merit: 250

Graz,

Don't want to undo any work you've done mate, but multiple payments != multiple accepts from the same buyer.

I'm not saying we should invalidate multiple payments, just multiple accepts from the same buyer simultaneously.  A buyer could accept 100 MSC and send 5 bitcoin payments to cover the buy - that's still OK.  A buyer could not accept 100 MSC and then accept another 100 MSC in a second offer (possibly at a different price), then make a bunch of payments.  Not without something in the spec that defines (explicitly) how bitcoin payments would be applied to these accepts (in what order, whether overpayments are rolled to another accept offer and so on).

Hope that makes more sense Smiley

Thanks
Zathras


Zathras,

Multiple accepts were allowed on my code base since ever. For me multiple accept are way more reasonable (and required) than multiple payments, and since it is so clear, I didn't even think it should be mentioned in the spec.
A user can accept an offer and then decides that he wants to buy more, so he accepts another portion.
I don't see a reason for a user to accept an offer and then make a partial payment, and right after, within the allowed timeframe, to make another partial payment.

I have 2 reasonably tested code states:
1. Without multiple payments.
2. With multiple payments.

On the second there was (is) already consensus between masterchain and mymastercoins.

A version of multiple payment with a limit of a single accept per address could be implemented, but this requires a very detailed check if it break something in some wierd scenario, it requires again full testing on my dev setup, and then deployment on the production.
There can be many reasons to lose the current consensus as part of this change, and hit bugs which I don't currently expect.

The approach taken with multiple payment (and again - I am ready to drop that), was to associate the payments with the first accept until it is at least 100% paid, and on the next payment to associate with the next accept.
We all do not expect such behaviour to be often used, but we have to close those corners in the implementation.

It can't be so difficult for you to modify the code and enable the user to do something that basic, is it?

Appreciate that but actually yeah it is quite difficult to modify the code to support multiple accepts - I understand from your PoV it should be straight forward, but you treat bitcoin payments as the transactions that bought the TMSC, where as I treat the accept offer as the transaction that bought the TMSC - it's a different way of coming at it.

I'd like to be very clear on what it is I'd need to implement before I look at gap analysis, from talking to Bitoy he said he implements payments as follows:

1) User A accepts 50 MSC at 0.01 each (accept 1)
2) User A accepts 50 MSC at 0.01 each (accept 2)
3) User A sends a payment 0.2BTC (20MSC) - this is applied to accept 1
4) User A sends another payment 0.6BTC (60 MSC) - this is applied to accept 1.  The first 0.3BTC pays accept 1 fully (the remaining 30 MSC).  The remaining 0.3BTC is an overpayment and ignored.
5) User A sends another payment 0.2BTC (20 MSC) - this is applied to accept 2 as accept 1 is now fully paid.

So in this scenario the buyer has sent 1BTC for 100 MSC but actually only receives 70 MSC and the seller gets an overpayment.  This is how Bitoy has described it to me - if you guys have consensus are you doing the same thing then?

Thanks
Zathras
sr. member
Activity: 284
Merit: 250

Graz,

Don't want to undo any work you've done mate, but multiple payments != multiple accepts from the same buyer.

I'm not saying we should invalidate multiple payments, just multiple accepts from the same buyer simultaneously.  A buyer could accept 100 MSC and send 5 bitcoin payments to cover the buy - that's still OK.  A buyer could not accept 100 MSC and then accept another 100 MSC in a second offer (possibly at a different price), then make a bunch of payments.  Not without something in the spec that defines (explicitly) how bitcoin payments would be applied to these accepts (in what order, whether overpayments are rolled to another accept offer and so on).

Hope that makes more sense Smiley

Thanks
Zathras


Zathras,

Multiple accepts were allowed on my code base since ever. For me multiple accept are way more reasonable (and required) than multiple payments, and since it is so clear, I didn't even think it should be mentioned in the spec.
A user can accept an offer and then decides that he wants to buy more, so he accepts another portion.
I don't see a reason for a user to accept an offer and then make a partial payment, and right after, within the allowed timeframe, to make another partial payment.

I have 2 reasonably tested code states:
1. Without multiple payments.
2. With multiple payments.

On the second there was (is) already consensus between masterchain and mymastercoins.

A version of multiple payment with a limit of a single accept per address could be implemented, but this requires a very detailed check if it break something in some wierd scenario, it requires again full testing on my dev setup, and then deployment on the production.
There can be many reasons to lose the current consensus as part of this change, and hit bugs which I don't currently expect.

The approach taken with multiple payment (and again - I am ready to drop that), was to associate the payments with the first accept until it is at least 100% paid, and on the next payment to associate with the next accept.
We all do not expect such behaviour to be often used, but we have to close those corners in the implementation.

It can't be so difficult for you to modify the code and enable the user to do something that basic, is it?

sr. member
Activity: 266
Merit: 250
Here is one more thing to discuss, I think.

1. Flawed public key compression:

There are a few transactions which use an uncompressed public key as input and then compress the key, but use a prefix of "02" where "03" would be used. Those transaction outputs are not spendabe by the user nor do they represent the initial address in any way, if base58 encoded.

Example:

Code:
Input: uncompressed public key
04e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee3419a40b939c24ac813c692a323ca5207a6fb387ffe28e48f706c95dbf46648f

Base58 encoded:
13NRX88EZbS5q81x6XFrTECzrciPREo821

Output: compressed with "02" instead of "03":
1JzhWo3tuReu8rsbhVPrBLxxGTcve6aaD

18 transactions (+ 3 invalid) are affected:

Code:
Transaction id                                                   Original input address
5885b1aa8938f234da483a5190084c3c425ab03363810e68b0214d358a8144c6 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8 INVALID
5fe5e0a2c7a4c9ae92708631b0559c32ebad33aa65d12d9d13b23869a1a68cbf 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8 INVALID
4842af86dac35a2c294f56511c7d08362330e82bd5fcae32c07119844e019b0a 14hm8rTdknVCDpqXGY5nFqVWruU9UBeuHd (mine)
ba63aa51cbf233a63db56b2dfb731c4f609b728125d1154fbc5453ec841c07cc 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb
3b08b5219e9dc8474b54d9d22fcdc7ccc03e916de313d306a5135ff607480cb6 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb INVALID
bc12d67c9403128a7effd9ff1da30dbcb3a47bc82207b2e93ea62de7ae91a4c9 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
e36099be9139bfe6a3a0a3f2b29a83b4cfe0c56d4fe58fd4e672a4bc9d4adae4 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
f6bb04e866fcf7a267f1af5659a7350a87b2c132ee1253757846c5be0b455a42 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb
8a8c2e7fe253fe8635d34ecc71510955d3a344546410db6961b35cd51809d3ea 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
f91f80606f96c0b0e5e30f2929e04a099b92c2dd26971180165d45d9b06a363e 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb
eef12413271bdda3446aac2209f26f01c35add0a18fcffce143cf298225a2375 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
f1897e2fa5b495b3e5dfd29fb30de63725d58e925ea7e6ef250066b5abde1bb8 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
5058febb5a048e021114534728a1aff7907b504ac47406067de81cd8384d8a07 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
e412453bde7abb42b3610beff5fad0fc3db3c4317a503914ab1e452e5fc326a5 13NRX88EZbS5q81x6XFrTECzrciPREo821
f8f166210911b28ef1cd720b57a94b43cd551203116c3abed84490d14200e191 13NRX88EZbS5q81x6XFrTECzrciPREo821
a3e4b7728835008b141c5f813e76416bd0876a50197bacafec8b039380ed36f1 13NRX88EZbS5q81x6XFrTECzrciPREo821
a47ddb72ebed729257bf29ca4907381551f6eb772b913f3895e5697673addeeb 13NRX88EZbS5q81x6XFrTECzrciPREo821
f8e53b52fa18e478fca931946bdf388ffcbecd9b053db3672f5289696e552739 13NRX88EZbS5q81x6XFrTECzrciPREo821
78735dfd07c20789a249063ab18b43516c5ac744c1b79612f9e5895773e707c4 13NRX88EZbS5q81x6XFrTECzrciPREo821
708d30405a58e1be0301e9475d0c9a23a9090d85e1fdf52808f90a8fe72f8a49 13NRX88EZbS5q81x6XFrTECzrciPREo821
8b0c75191564a937c4996702c425f9399c8d70742b44e4d9e306016d87bbc708 13NRX88EZbS5q81x6XFrTECzrciPREo821

2. No input reference in the outputs:

There are 10 transactions (+ 3 invalid) with an output with a public key that is not the input and where the output is no data packet:

Code:
Transaction id                                                   Original input address
4805d3fba156e622cfdf47b12e68380b181cc96e9e6ef21076d9bc7e6704e336 14hm8rTdknVCDpqXGY5nFqVWruU9UBeuHd (mine)
55791fff99bbf40b8aeb5d0aac40e15bf0120bc5cce4b06c00c6626329c90fed 1donutMH4L7kdRqh4xvSvesfd3KFu3UNm
98314ebb0d96a98b5b52c891c8aac982e77420429450661b078a795051389d75 1donutMH4L7kdRqh4xvSvesfd3KFu3UNm
6784b73048de3ab36c08ee06897be92ccb20f9b288345f96b0681cbc5b014ad4 1gYs2kC58J7aRBRJ7CYqysBpYoT7b5i8H INVALID according to Masterchain
a7120ed05e1b42f48fec59d0a3b56202d15a0bb8272653f995ac584f16e67c09 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
f4d5e7a5af93b5091a2652719943c3a19f56cf6933d071a87f2bf87cba9a7f0a 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
31620c7e58f31a1833808f52eb240e4c4510994765f4d269bb2740ecfa136f9a 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
2ae17011888e9a2e6c752999774cd6d88feb7c0751abe72a602be89858e44f6a 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
b9e6b1f6f428441d7e91e7715ed4524de942b8d755367828e1d85ca850a9dc43 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
8c9027bfbee656c591ec87d233f0e338e623452519fbf8d76961e1afa480949c 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j INVALID according to Masterchain
38c37aec242e1054a366bbbe79fac2b01c392fe6c9c1732d25f54f0dbcc317dd 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j INVALID according to Masterchain
100e35e3fba087407a67e69ac60436f2b1f097823d083464ad26940d9fa06f6e 1Pa6zyqnhL6LDJtrkCMi9XmEDNHJ23ffEr (mine)
e308a5c9f7f035e3c1ed1abafdda85d9b790dbf8243f90484a9b25d6a7f8c8e7 1Pa6zyqnhL6LDJtrkCMi9XmEDNHJ23ffEr (mine)

The spec says:

- Has a single or the largest input signed by the sending address.
- Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address.

The above mentioned transactions are in conflict with those requirements.

There are multiple transactions with more than one input, but in almost all cases the same input address is used. There are currently 5 simple send transactions with more than one different input addresses. Not a single valid multi sig transaction.

I personally dislike the allowence of different inputs (many with the same pubKey are fine), because such transactions requires to fetch all input transactions to extract the value to determine the highest one which would otherwise be not necessary.

I have no solution how data packages can be safely identified and ordered and no implementation is currently able to parse a transaction with unordered data packages.

But if a given order is strictly required it would make the whole concept of sequence numbers more or less obsolete. I don't want to believe this though.

Here is my take:

1. Class A transactions are seperated and can be treated completey different. It's obsolete anyway, so workarounds or inefficiencies are not an issue.
2. I suggest to disallow multiple inputs with different public keys. This does not invalidate any transaction up until now, it is much more painless and furthermore the identification of the input reference is solely possible via the input itself. Including the input reference as part of a multisig still makes a lot of sense to redeem the output, but that's not mutually exclusive.
3. Fixing the prefix issue of compressed public keys is advised.
4. It would be very, very, very awesome, if there is a) a way to distinguish between data packages and non-data packages and b) if this is also possible, if data packages are not ordered. If this is the case, then including the pubKey as output would not require a special note nor would any malformated or additional pubKey in the outputs raise a conflict.

So the questions:

What do you think about dropping the support for multiple inputs with different pubKeys (= different wallets) for class B transactions?

How should multi sig outputs be treated which are neither a valid input reference (e.g. due to flawed compression, compression or because it's simply junk) nor a valid data package?

Currently all this mostly affects transactions that were issued by devs and those conflicts did not yet lead to notable problems, but once it gets real, there might be no turning back anymore.

That's my biggest "fear". Grin

Hey DexX,

Apologies I don't have time to give your post all the attention it warrants, but a few quick notes:

* Re keys - this is just Masterchest sender key compression & I will be dropping this.  It does this to save transaction space but causes confusion when the key is uncompressed in the wallet but compressed in the multisig.  Both perfectly still redeemable by the same private key but the addresses differ, hence confusion.  Thus sender keys will soon be sent in the same format they are stored in the local bitcoin wallet.  Graz doesn't compress sender keys, and Bitoy does (because he uses my library).  Technically the spec states compressing is correct:
Quote
Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address
However given the amount of confusion over this (the debate went on back in the day) I think it's just easier to say the sender key can be either compressed or uncompressed, such that clients can broadcast it in whatever format it's stored locally (and thus have addresses match).
* There is an amendment to the spec that needs to be made - it's actually not largest input, it's largest input by sum - so the input address is selected from the address that contributed the highest sum input value.
* Sequence numbers are there for packet ordering, though there may be some shortcuts/assumptions in Masterchest code that assume a given packet order in the multisig (but that's not a spec problem, that's just code)

Thanks Smiley
Zathras
sr. member
Activity: 266
Merit: 250
Actually, unfortunately this is not simply a UI issue for me.  It goes to the core of the logic I currently apply.  Let's say there is an accept in block 3 for 50 MSC.  I then search block 3 to block 3+timelimit for payments to the seller.  For example:
1) Accept 50 MSC for 5 BTC in block 3
2) Check blocks 3 to 9 for payment, yep found 5 BTC payment to seller in block 8
3) Accept 50 MSC for 5 BTC in block 6
4) Check blocks 6 to 12 for payment, yep found 5 BTC payment to seller in block 8

Oops, same payment has now been applied to two accepts.  So as we can see logic was written with the design assumption of a single accept per address per sell.

Also we can't simply merge the two accepts, what happens if the seller updated the sell with a different price in between the two accepts?  They have to be handled as seperate entities and thus we have to define an order of precedent for applying payments and so on.

I'll put my thinking hat on and go review my code logic, but there will be some complexities to allowing this.


Ugh. Good point. I'm leaning towards just one accept allowed per unique buyer/seller at a time, because it is more complicated than I at first thought, and I like simplicity whenever I can get it.

Bitoy and Grazcoin, how bad does that sound to you?

We have 5 days before we go live, and originally we wanted 10-14 days of consensus before that. We will not have that, but we really can't wait for the last moment.
Two implementations have consensus on the current code base now, and if we make another change, we may lose that.

I was asking to drop the whole multiple payments saying that it contradicts the basic design of my code, and it hides some complexities that we didn't think of, but you guys insisted.
It was 2 full working days with a lot of testing, and a huge patch.

At the current stage, I prefer either to keep the consensus without limiting user freedom for multiple accepts and ask Zathras to join the consensus, or roll back the whole multiple payments feature.

Graz,

Don't want to undo any work you've done mate, but multiple payments != multiple accepts from the same buyer.

I'm not saying we should invalidate multiple payments, just multiple accepts from the same buyer simultaneously.  A buyer could accept 100 MSC and send 5 bitcoin payments to cover the buy - that's still OK.  A buyer could not accept 100 MSC and then accept another 100 MSC in a second offer (possibly at a different price), then make a bunch of payments.  Not without something in the spec that defines (explicitly) how bitcoin payments would be applied to these accepts (in what order, whether overpayments are rolled to another accept offer and so on).

What payment logic for multiple accepts are you using now if I may ask?

Hope that makes more sense Smiley

Thanks
Zathras
legendary
Activity: 1260
Merit: 1031
Rational Exuberance

We have 5 days before we go live, and originally we wanted 10-14 days of consensus before that. We will not have that, but we really can't wait for the last moment.
Two implementations have consensus on the current code base now, and if we make another change, we may lose that.

I was asking to drop the whole multiple payments saying that it contradicts the basic design of my code, and it hides some complexities that we didn't think of, but you guys insisted.
It was 2 full working days with a lot of testing, and a huge patch.

At the current stage, I prefer either to keep the consensus without limiting user freedom for multiple accepts and ask Zathras to join the consensus, or roll back the whole multiple payments feature.


Ah. I didn't realize you two were in consensus already on that. That does help. I don't particularly like any option here, but we have to take the path of least resistance at this point.

I had hoped that it would be trivial to invalidate additional accept offers after the first. Is that not the case?

Bitoy, I hope you'll weigh in on this too.

Zathras, I know it sucks, but we may need to change yours if it is a large change for the other two implementations to disable multiple accepts.

legendary
Activity: 1106
Merit: 1026
Here is one more thing to discuss, I think.

1. Flawed public key compression:

There are a few transactions which use an uncompressed public key as input and then compress the key, but use a prefix of "02" where "03" would be used. Those transaction outputs are not spendabe by the user nor do they represent the initial address in any way, if base58 encoded.

Example:

Code:
Input: uncompressed public key
04e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee3419a40b939c24ac813c692a323ca5207a6fb387ffe28e48f706c95dbf46648f

Base58 encoded:
13NRX88EZbS5q81x6XFrTECzrciPREo821

Output: compressed with "02" instead of "03":
1JzhWo3tuReu8rsbhVPrBLxxGTcve6aaD

18 transactions (+ 3 invalid) are affected:

Code:
Transaction id                                                   Original input address
5885b1aa8938f234da483a5190084c3c425ab03363810e68b0214d358a8144c6 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8 INVALID
5fe5e0a2c7a4c9ae92708631b0559c32ebad33aa65d12d9d13b23869a1a68cbf 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8 INVALID
4842af86dac35a2c294f56511c7d08362330e82bd5fcae32c07119844e019b0a 14hm8rTdknVCDpqXGY5nFqVWruU9UBeuHd (mine)
ba63aa51cbf233a63db56b2dfb731c4f609b728125d1154fbc5453ec841c07cc 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb
3b08b5219e9dc8474b54d9d22fcdc7ccc03e916de313d306a5135ff607480cb6 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb INVALID
bc12d67c9403128a7effd9ff1da30dbcb3a47bc82207b2e93ea62de7ae91a4c9 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
e36099be9139bfe6a3a0a3f2b29a83b4cfe0c56d4fe58fd4e672a4bc9d4adae4 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
f6bb04e866fcf7a267f1af5659a7350a87b2c132ee1253757846c5be0b455a42 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb
8a8c2e7fe253fe8635d34ecc71510955d3a344546410db6961b35cd51809d3ea 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
f91f80606f96c0b0e5e30f2929e04a099b92c2dd26971180165d45d9b06a363e 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb
eef12413271bdda3446aac2209f26f01c35add0a18fcffce143cf298225a2375 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
f1897e2fa5b495b3e5dfd29fb30de63725d58e925ea7e6ef250066b5abde1bb8 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
5058febb5a048e021114534728a1aff7907b504ac47406067de81cd8384d8a07 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8
e412453bde7abb42b3610beff5fad0fc3db3c4317a503914ab1e452e5fc326a5 13NRX88EZbS5q81x6XFrTECzrciPREo821
f8f166210911b28ef1cd720b57a94b43cd551203116c3abed84490d14200e191 13NRX88EZbS5q81x6XFrTECzrciPREo821
a3e4b7728835008b141c5f813e76416bd0876a50197bacafec8b039380ed36f1 13NRX88EZbS5q81x6XFrTECzrciPREo821
a47ddb72ebed729257bf29ca4907381551f6eb772b913f3895e5697673addeeb 13NRX88EZbS5q81x6XFrTECzrciPREo821
f8e53b52fa18e478fca931946bdf388ffcbecd9b053db3672f5289696e552739 13NRX88EZbS5q81x6XFrTECzrciPREo821
78735dfd07c20789a249063ab18b43516c5ac744c1b79612f9e5895773e707c4 13NRX88EZbS5q81x6XFrTECzrciPREo821
708d30405a58e1be0301e9475d0c9a23a9090d85e1fdf52808f90a8fe72f8a49 13NRX88EZbS5q81x6XFrTECzrciPREo821
8b0c75191564a937c4996702c425f9399c8d70742b44e4d9e306016d87bbc708 13NRX88EZbS5q81x6XFrTECzrciPREo821

2. No input reference in the outputs:

There are 10 transactions (+ 3 invalid) with an output with a public key that is not the input and where the output is no data packet:

Code:
Transaction id                                                   Original input address
4805d3fba156e622cfdf47b12e68380b181cc96e9e6ef21076d9bc7e6704e336 14hm8rTdknVCDpqXGY5nFqVWruU9UBeuHd (mine)
55791fff99bbf40b8aeb5d0aac40e15bf0120bc5cce4b06c00c6626329c90fed 1donutMH4L7kdRqh4xvSvesfd3KFu3UNm
98314ebb0d96a98b5b52c891c8aac982e77420429450661b078a795051389d75 1donutMH4L7kdRqh4xvSvesfd3KFu3UNm
6784b73048de3ab36c08ee06897be92ccb20f9b288345f96b0681cbc5b014ad4 1gYs2kC58J7aRBRJ7CYqysBpYoT7b5i8H INVALID according to Masterchain
a7120ed05e1b42f48fec59d0a3b56202d15a0bb8272653f995ac584f16e67c09 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
f4d5e7a5af93b5091a2652719943c3a19f56cf6933d071a87f2bf87cba9a7f0a 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
31620c7e58f31a1833808f52eb240e4c4510994765f4d269bb2740ecfa136f9a 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
2ae17011888e9a2e6c752999774cd6d88feb7c0751abe72a602be89858e44f6a 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
b9e6b1f6f428441d7e91e7715ed4524de942b8d755367828e1d85ca850a9dc43 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j
8c9027bfbee656c591ec87d233f0e338e623452519fbf8d76961e1afa480949c 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j INVALID according to Masterchain
38c37aec242e1054a366bbbe79fac2b01c392fe6c9c1732d25f54f0dbcc317dd 14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j INVALID according to Masterchain
100e35e3fba087407a67e69ac60436f2b1f097823d083464ad26940d9fa06f6e 1Pa6zyqnhL6LDJtrkCMi9XmEDNHJ23ffEr (mine)
e308a5c9f7f035e3c1ed1abafdda85d9b790dbf8243f90484a9b25d6a7f8c8e7 1Pa6zyqnhL6LDJtrkCMi9XmEDNHJ23ffEr (mine)

The spec says:

- Has a single or the largest input signed by the sending address.
- Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address.

The above mentioned transactions are in conflict with those requirements.

There are multiple transactions with more than one input, but in almost all cases the same input address is used. There are currently 5 simple send transactions with more than one different input addresses. Not a single valid multi sig transaction.

I personally dislike the allowence of different inputs (many with the same pubKey are fine), because such transactions requires to fetch all input transactions to extract the value to determine the highest one which would otherwise be not necessary.

I have no solution how data packages can be safely identified and ordered and no implementation is currently able to parse a transaction with unordered data packages.

But if a given order is strictly required it would make the whole concept of sequence numbers more or less obsolete. I don't want to believe this though.

Here is my take:

1. Class A transactions are seperated and can be treated completey different. It's obsolete anyway, so workarounds or inefficiencies are not an issue.
2. I suggest to disallow multiple inputs with different public keys. This does not invalidate any transaction up until now, it is much more painless and furthermore the identification of the input reference is solely possible via the input itself. Including the input reference as part of a multisig still makes a lot of sense to redeem the output, but that's not mutually exclusive.
3. Fixing the prefix issue of compressed public keys is advised.
4. It would be very, very, very awesome, if there is a) a way to distinguish between data packages and non-data packages and b) if this is also possible, if data packages are not ordered. If this is the case, then including the pubKey as output would not require a special note nor would any malformated or additional pubKey in the outputs raise a conflict.

So the questions:

What do you think about dropping the support for multiple inputs with different pubKeys (= different wallets) for class B transactions?

How should multi sig outputs be treated which are neither a valid input reference (e.g. due to flawed compression, compression or because it's simply junk) nor a valid data package?

Currently all this mostly affects transactions that were issued by devs and those conflicts did not yet lead to notable problems, but once it gets real, there might be no turning back anymore.

That's my biggest "fear". Grin
sr. member
Activity: 284
Merit: 250
Actually, unfortunately this is not simply a UI issue for me.  It goes to the core of the logic I currently apply.  Let's say there is an accept in block 3 for 50 MSC.  I then search block 3 to block 3+timelimit for payments to the seller.  For example:
1) Accept 50 MSC for 5 BTC in block 3
2) Check blocks 3 to 9 for payment, yep found 5 BTC payment to seller in block 8
3) Accept 50 MSC for 5 BTC in block 6
4) Check blocks 6 to 12 for payment, yep found 5 BTC payment to seller in block 8

Oops, same payment has now been applied to two accepts.  So as we can see logic was written with the design assumption of a single accept per address per sell.

Also we can't simply merge the two accepts, what happens if the seller updated the sell with a different price in between the two accepts?  They have to be handled as seperate entities and thus we have to define an order of precedent for applying payments and so on.

I'll put my thinking hat on and go review my code logic, but there will be some complexities to allowing this.


Ugh. Good point. I'm leaning towards just one accept allowed per unique buyer/seller at a time, because it is more complicated than I at first thought, and I like simplicity whenever I can get it.

Bitoy and Grazcoin, how bad does that sound to you?

We have 5 days before we go live, and originally we wanted 10-14 days of consensus before that. We will not have that, but we really can't wait for the last moment.
Two implementations have consensus on the current code base now, and if we make another change, we may lose that.

I was asking to drop the whole multiple payments saying that it contradicts the basic design of my code, and it hides some complexities that we didn't think of, but you guys insisted.
It was 2 full working days with a lot of testing, and a huge patch.

At the current stage, I prefer either to keep the consensus without limiting user freedom for multiple accepts and ask Zathras to join the consensus, or roll back the whole multiple payments feature.



legendary
Activity: 1260
Merit: 1031
Rational Exuberance
Actually, unfortunately this is not simply a UI issue for me.  It goes to the core of the logic I currently apply.  Let's say there is an accept in block 3 for 50 MSC.  I then search block 3 to block 3+timelimit for payments to the seller.  For example:
1) Accept 50 MSC for 5 BTC in block 3
2) Check blocks 3 to 9 for payment, yep found 5 BTC payment to seller in block 8
3) Accept 50 MSC for 5 BTC in block 6
4) Check blocks 6 to 12 for payment, yep found 5 BTC payment to seller in block 8

Oops, same payment has now been applied to two accepts.  So as we can see logic was written with the design assumption of a single accept per address per sell.

Also we can't simply merge the two accepts, what happens if the seller updated the sell with a different price in between the two accepts?  They have to be handled as seperate entities and thus we have to define an order of precedent for applying payments and so on.

I'll put my thinking hat on and go review my code logic, but there will be some complexities to allowing this.


Ugh. Good point. I'm leaning towards just one accept allowed per unique buyer/seller at a time, because it is more complicated than I at first thought, and I like simplicity whenever I can get it.

Bitoy and Grazcoin, how bad does that sound to you?
sr. member
Activity: 266
Merit: 250

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?

Actually, unfortunately this is not simply a UI issue for me.  It goes to the core of the logic I currently apply.  Let's say there is an accept in block 3 for 50 MSC.  I then search block 3 to block 3+timelimit for payments to the seller.  For example:
1) Accept 50 MSC for 5 BTC in block 3
2) Check blocks 3 to 9 for payment, yep found 5 BTC payment to seller in block 8
3) Accept 50 MSC for 5 BTC in block 6
4) Check blocks 6 to 12 for payment, yep found 5 BTC payment to seller in block 8

Oops, same payment has now been applied to two accepts.  So as we can see logic was written with the design assumption of a single accept per address per sell.

Also we can't simply merge the two accepts, what happens if the seller updated the sell with a different price in between the two accepts?  They have to be handled as seperate entities and thus we have to define an order of precedent for applying payments and so on.

I'll put my thinking hat on and go review my code logic, but there will be some complexities to allowing this.
legendary
Activity: 1260
Merit: 1031
Rational Exuberance

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?
legendary
Activity: 1106
Merit: 1026
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?
sr. member
Activity: 449
Merit: 250
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)
sr. member
Activity: 449
Merit: 250
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.
sr. member
Activity: 284
Merit: 250
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?)

sr. member
Activity: 266
Merit: 250
legendary
Activity: 1106
Merit: 1026
With Masterchain as reference:

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=TMSC

Masterchest -PASSED-
MyMastercoins -PASSED-

There are 2 accepts that happen in the same block (all from 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL)
0.025 https://masterchain.info/sellaccept.html?tx=8e12e87dc2a04f10115726dfe385b6744b8721bc4ffc08a6e1089c5c22271897¤cy=TMSC

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-

0.002 BTC (for 0.01 TMSC - that's all which is left on that accept) https://masterchain.info/btcpayment.html?tx=df3b38afcfc1fe20d065d58e5d02360d9150e0e1d9f5f7691c33d84c07e3acc4¤cy=TMSC
Total bought is the full 0.025 TMSC of that accept.

Masterchest -UNAVAILABLE-
MyMastercoins -PASSED-

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=TMSC

Masterchest -FAILED- (shows unit price: 0.16 BTC, total price: 0.008 BTC)
MyMastercoins -PASSED-

A 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=TMSC
0.03 TMSC bought.

Masterchest -UNAVAILABLE-
MyMastercoins -PASSED-

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=TMSC
0.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).

Masterchest -UNAVAILABLE-
MyMastercoins -PASSED-

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=TMSC

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)

simple send of 0.500111 TMSC from the seller 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX
https://masterchain.info/simplesend.html?tx=d173a8b6ed41b20ed225124d79a5307923f3f703b7e511deefba9bcdf70d59dc¤cy=TMSC
This transaction should be invalidated due to "balance too low".

Masterchest -PASSED-
MyMastercoins -PASSED-

A click on the explorer name forwards to the transaction. Wink


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.
sr. member
Activity: 284
Merit: 250
Deep DEx tesing

We 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=TMSC

There are 2 accepts that happen in the same block (all from 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL)
0.025 https://masterchain.info/sellaccept.html?tx=8e12e87dc2a04f10115726dfe385b6744b8721bc4ffc08a6e1089c5c22271897¤cy=TMSC
0.04 https://masterchain.info/sellaccept.html?tx=263b7c420b2456b3f04eea4d92ddf35b95703859173a321c9fdeb71e6c1f5328¤cy=TMSC

For the first accept (0.25), 3 payments are done:
0.0005 BTC (for 0.005 TMSC) https://masterchain.info/btcpayment.html?tx=42f470a5c00be4e434055fd63515d14d7fdd6d96e0eedea6a494620a5818554b¤cy=TMSC
0.001 BTC (for 0.01 TMSC) https://masterchain.info/btcpayment.html?tx=36ef617e944bfad6b5d43f9faccc8ead27c33d54e07f2793fe13f1980846488b¤cy=TMSC
0.002 BTC (for 0.01 TMSC - that's all which is left on that accept) https://masterchain.info/btcpayment.html?tx=df3b38afcfc1fe20d065d58e5d02360d9150e0e1d9f5f7691c33d84c07e3acc4¤cy=TMSC
Total 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=TMSC

A 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=TMSC
0.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=TMSC
0.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=TMSC

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.

simple send of 0.500111 TMSC from the seller 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX
https://masterchain.info/simplesend.html?tx=d173a8b6ed41b20ed225124d79a5307923f3f703b7e511deefba9bcdf70d59dc¤cy=TMSC
This 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.

sr. member
Activity: 266
Merit: 250
Deep DEx tesing

We 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=TMSC

There are 2 accepts that happen in the same block (all from 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL)
0.025 https://masterchain.info/sellaccept.html?tx=8e12e87dc2a04f10115726dfe385b6744b8721bc4ffc08a6e1089c5c22271897¤cy=TMSC
0.04 https://masterchain.info/sellaccept.html?tx=263b7c420b2456b3f04eea4d92ddf35b95703859173a321c9fdeb71e6c1f5328¤cy=TMSC

For the first accept (0.25), 3 payments are done:
0.0005 BTC (for 0.005 TMSC) https://masterchain.info/btcpayment.html?tx=42f470a5c00be4e434055fd63515d14d7fdd6d96e0eedea6a494620a5818554b¤cy=TMSC
0.001 BTC (for 0.01 TMSC) https://masterchain.info/btcpayment.html?tx=36ef617e944bfad6b5d43f9faccc8ead27c33d54e07f2793fe13f1980846488b¤cy=TMSC
0.002 BTC (for 0.01 TMSC - that's all which is left on that accept) https://masterchain.info/btcpayment.html?tx=df3b38afcfc1fe20d065d58e5d02360d9150e0e1d9f5f7691c33d84c07e3acc4¤cy=TMSC
Total 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=TMSC

A 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=TMSC
0.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=TMSC
0.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=TMSC

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.

simple send of 0.500111 TMSC from the seller 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX
https://masterchain.info/simplesend.html?tx=d173a8b6ed41b20ed225124d79a5307923f3f703b7e511deefba9bcdf70d59dc¤cy=TMSC
This 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
sr. member
Activity: 266
Merit: 250
Graz, not sure if you're around but Bitoy & I are on IRC now if you want to jump in & discuss consensus Smiley
sr. member
Activity: 284
Merit: 250
Deep DEx tesing

We 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=TMSC

There are 2 accepts that happen in the same block (all from 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL)
0.025 https://masterchain.info/sellaccept.html?tx=8e12e87dc2a04f10115726dfe385b6744b8721bc4ffc08a6e1089c5c22271897¤cy=TMSC
0.04 https://masterchain.info/sellaccept.html?tx=263b7c420b2456b3f04eea4d92ddf35b95703859173a321c9fdeb71e6c1f5328¤cy=TMSC

For the first accept (0.25), 3 payments are done:
0.0005 BTC (for 0.005 TMSC) https://masterchain.info/btcpayment.html?tx=42f470a5c00be4e434055fd63515d14d7fdd6d96e0eedea6a494620a5818554b¤cy=TMSC
0.001 BTC (for 0.01 TMSC) https://masterchain.info/btcpayment.html?tx=36ef617e944bfad6b5d43f9faccc8ead27c33d54e07f2793fe13f1980846488b¤cy=TMSC
0.002 BTC (for 0.01 TMSC - that's all which is left on that accept) https://masterchain.info/btcpayment.html?tx=df3b38afcfc1fe20d065d58e5d02360d9150e0e1d9f5f7691c33d84c07e3acc4¤cy=TMSC
Total 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=TMSC

A 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=TMSC
0.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=TMSC
0.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=TMSC

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.

simple send of 0.500111 TMSC from the seller 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX
https://masterchain.info/simplesend.html?tx=d173a8b6ed41b20ed225124d79a5307923f3f703b7e511deefba9bcdf70d59dc¤cy=TMSC
This transaction should be invalidated due to "balance too low".
Pages:
Jump to: