|
zathras
|
 |
March 12, 2014, 02:30:31 AM |
|
Great, please see inline  I think what Dexx is getting it is allowing a sequence of Master Protocol packets anywhere in the multisig outputs, as long as the packets are contiguous. I'm not sure that's necessary at this stage (I think if we're to lock in packet ordering then let's keep it simple). Also re 1-of-3, yep I know technically we can go higher but not while maintaining widespread support. My own view is that we'll see OP_RETURN before better native multisig handling in the reference client, but that's pure speculation of course. Dexx, I know you posted an analysis a few pages back but could you pick say two or three transactions, post them & a brief summary on why you think they're invalid/contain junk. Happy to take a look Thanks. Yes and I agree, keeping it as simple as possible, would be good. Okay, I'll try to cover a few cases I found: 1. https://blockchain.info/tx/bda81e0c2117fb6ecefb92143995a6ebc3d9569f54c4a0c074ff3070bcf3e011Input: compressed public key Output: compressed input public key, data-package #1, data-package #2 No conflict. 2. https://blockchain.info/tx/95b10a4721a69a1028e70fd2ccd0692219095fb6f5087b9e72b155a3e0832602Input: uncompressed public key Output: uncompressed public key, data package #1 Conflict: "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" (has only one compressed public key) There needs to be a spec amendment here - while I was authoring that appendix I was pushing for us to compress the sender key if uncompressed in the wallet (I was on a charge to be as 'light' blockchain wise as possible and that saved a chunk (32 bytes)). Graz uses the key in whatever format it's in originally, and I'm going to do the same by dropping sender key compression from my library - cost more transaction space but should avoid any confusion re addresses. The pull just needs to remove the word 'compressed' from that statement.3. https://blockchain.info/tx/f8e2eb56f50f7a98a8c76ef45ed591aedd8aa973c5f4dfd5b7685aae4b48ae6cInput: uncompressed public key Output: compressed public key, data package #1 Public key was compressed, but that's no conflict. Yeah, as above we should allow compressed public keys, but I'll no longer be actively compressing originally uncompressed keys.4. https://blockchain.info/tx/4842af86dac35a2c294f56511c7d08362330e82bd5fcae32c07119844e019b0aInput: uncompresssed public key Output: compressed public key with flawed prefix byte, data package #1 Conflict: "As one signatory must be the sender for redemption purposes, ..." "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" (not the case, because of a small flaw during the compression [prefix "02" instead of "03"], so this output is neither redeemable nor the sender's address) As I mentioned before that first senders key is irrelevant to the Master Protocol transaction, so I'd say we should re-word 'must' to 'should' to reflect what we have in practice (another one word pull). I still need to go over that key compression code as you mentioned, as it's of course possible I'm flipping that bit backwards.5. https://blockchain.info/tx/2ae17011888e9a2e6c752999774cd6d88feb7c0751abe72a602be89858e44f6aInput: compressed public key Output: unknown package, data package #1 Conflict: "As one signatory must be the sender for redemption purposes, ..." "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" (not the case, because the first package has no relation to the input address) I'd have to fire that transaction up in step by step decoding (which I can do, I'm just kind of occupied right now) to take a look, but if we went with the word change above that would also address this one (should=guideline we don't have to check, must=explicit rule we must enforce - that's how I think of it anyway)6. https://blockchain.info/tx/1ce1e44f40da1f7eddca5f81d72d76a005f8f45b83ee1f9b07ca901f3e6ec235Input: uncompressed public key Output: data package #1, compressed public key This is an edge case. All data packages are ordered (it's only one) and it includes the sender's address. This will be invalidated once we lock in that the order of each multisig needs to be {senderkey,masterpacket1,masterpacket2} |
|
|
|
dexX7
Legendary
 Offline
Activity: 1106
Merit: 1024
|
|
March 12, 2014, 03:00:57 AM |
|
Awesome, really not much of a change. Not sure about this: Case 4 and 5 basically allow to have no input public key included, but case 6 requires one, more or less? |
|
|
|
|
zathras
|
|
March 12, 2014, 03:50:24 AM |
|
Awesome, really not much of a change. Not sure about this: Case 4 and 5 basically allow to have no input public key included, but case 6 requires one, more or less? Case 4 and 5 have the first master protocol packet as the second public key, which to date has been an assumed - but will now be a locked in - specification. Case 6 has the first master protocol packet as the first public key, which moving forward has been agreed will not be valid. Thanks Zathras |
|
|
|
|
Bitoy
|
|
March 12, 2014, 06:58:36 AM |
|
Is this transaction invalid ?
a7120ed05e1b42f48fec59d0a3b56202d15a0bb8272653f995ac584f16e67c09
What happened is Buyer 1G3P5bws8wRVrVfKWxv8F85pRjs9qXyyA6 placed a
Purchase offer 0.002
6ea30cd210ae4521c58d026114f16ef4e63c86d9550de5dba72f588f789aa69c
for Sell Offer
8b2deeb03c2590bbc6698ab3d663eb920e8bb7e89437a7984a54b8d0154d6741
Paid for 0.002
Tried to Purchase again 0.007 from the same Sell Offer
8b2deeb03c2590bbc6698ab3d663eb920e8bb7e89437a7984a54b8d0154d6741
|
|
|
|
|
|
|
|
Bitoy
|
|
March 12, 2014, 10:06:58 AM |
|
Ok. So we are invalidating only "concurrent accept". Invalid Purchase offer transactions due to minimum miners fee not reached. b9a870a6c1bc12c954b1b01fbdb86a8f71aa8c31ff77624dd8b58f84ef21bbfb b31a720e9b8ede0b6aa0c3b10ed1a7274b257d489f81e11470499281cb0402d7 61d922eb409fcd932798cb519f97ba65de18099c501b324ae86b4658530da92b f6bb04e866fcf7a267f1af5659a7350a87b2c132ee1253757846c5be0b455a42 8a8c2e7fe253fe8635d34ecc71510955d3a344546410db6961b35cd51809d3ea 77702fd6333eb5a67fa03b6fdb0fda04981bd671fd2a9175e2bee43340770940 |
|
|
|
|
dacoinminster (OP)
Legendary
Offline
Activity: 1260
Merit: 1031
Rational Exuberance
|
|
March 12, 2014, 06:06:20 PM |
|
And the official changeover block to trade MSC on the distributed exchange is . . . (drumroll) 290630History suggests that our target date of 2014-03-15 00:00:00 GMT should fall somewhere between blocks 290607 and 290630. I chose the later number because I want to make sure we get every last ounce of testing we deserve |
|
|
|
|
jeroenn13
|
|
March 12, 2014, 06:12:04 PM |
|
And the official changeover block to trade MSC on the distributed exchange is . . . (drumroll) 290630History suggests that our target date of 2014-03-15 00:00:00 GMT should fall somewhere between blocks 290607 and 290630. I chose the later number because I want to make sure we get every last ounce of testing we deserve Yes, we have an block number! Only 2 days! Thank you Dacoinminster and others.  |
|
|
|
|
|
marvschneider
Newbie
Offline
Activity: 4
Merit: 0
|
|
March 12, 2014, 07:44:13 PM |
|
Devs,
Some general questions that don't require an immediate reply. I'm not looking to distract you.
I'm just curious -
When you show a coin balance for an address, does it include or exclude any reserved/committed/escrowed amount (is it the available balance)? Is this clear to the user? Is it easy for the user to see the reserved/committed/escrowed amounts and related details?
Is the user able to see why coins were returned to the available balance, e.g. when a sell offer is updated or canceled, a buyer underpays or doesn't pay at all?
|
|
|
|
|
|
grazcoin
|
|
March 12, 2014, 08:03:16 PM |
|
Devs,
Some general questions that don't require an immediate reply. I'm not looking to distract you.
I'm just curious -
When you show a coin balance for an address, does it include or exclude any reserved/committed/escrowed amount (is it the available balance)? Is this clear to the user? Is it easy for the user to see the reserved/committed/escrowed amounts and related details?
Is the user able to see why coins were returned to the available balance, e.g. when a sell offer is updated or canceled, a buyer underpays or doesn't pay at all?
Reserved is taken from the available balance, until it is no longer reserved. I think it is clear from the UI, e.g. https://masterchain.info/Address.html?addr=182osbPxCo88oaSX4ReJwUr9uAcchmJVaL¤cy=TMSC |
|
|
|
|
grazcoin
|
|
March 12, 2014, 08:06:01 PM |
|
I just checked the logs of masterchain.info now, and it is already 3 days that I get more than 350 unique visits daily (not including wallet). This number is generated by http://goaccess.prosoftcorp.com/Grazcoin |
|
|
|
ripper234
Legendary
Offline
Activity: 1358
Merit: 1003
Ron Gross
|
|
March 12, 2014, 09:28:30 PM |
|
I just checked the logs of masterchain.info now, and it is already 3 days that I get more than 350 unique visits daily (not including wallet). This number is generated by http://goaccess.prosoftcorp.com/Grazcoin Great stuff Graz! Do you have details on how many people created a wallet? Any statistics you can share would be interesting. |
|
|
|
|
zathras
|
|
March 13, 2014, 12:18:04 AM |
|
Graz/Bitoy,
Closing in on consensus - but I think you guys have a problem in the way you're handling the blocking of simultaneous accepts from the same buyer.
You guys have accept 9ecd7a40eba06ea554fa42dadca1c4c94dc301040d656484a85c45d68d80963a as valid.
However that accept above was in block 289755.
All the payments for the previous accept took place in block 289755.
As all the payments took place in block 289755 the previous accept is thus closed in block 289755. A new accept should not be allowed until the next block, 289756 - otherwise we are encouraging new accepts while payments are still unconfirmed (which means we then need to go to checking whether the payments occurred 'earlier in the block' than the new accept etc)
Therefore accept 9ecd7a40eba06ea554fa42dadca1c4c94dc301040d656484a85c45d68d80963a should be invalid as its in the same block as the payments for the previous accept.
Thanks
Zathras
|
|
|
|
|
Herp
|
|
March 13, 2014, 01:56:50 AM |
|
I just checked the logs of masterchain.info now, and it is already 3 days that I get more than 350 unique visits daily (not including wallet). This number is generated by http://goaccess.prosoftcorp.com/Grazcoin Great stuff Graz! Do you have details on how many people created a wallet? Any statistics you can share would be interesting. wallet here is not intuitive at all. I have no clue how to use it without looking for some documentation. Quite frustrating for someone expecting something resembling Blockchain.info. It should be average user friendly if not retard friendly. Out of the 3 existing wallets, not one of them is user friendly or without weird errors during installation. Perhaps you shouldn't pay bounties to any sloppy job and demand more quality and polished products, be more demanding in general to those who take on these bounties. |
|
|
|
|
zathras
|
|
March 13, 2014, 05:46:06 AM |
|
I also think a4be2bc89c0b11977ed907605993680ea893ebe316878586f05bd755275f559b should be invalidated. An address buying coins from itself is invalid IMO, I can't see any use cases for it (boggles the mind actually  ) - just adds unnecessary complexity to support it and throws up questions around how we'd handle this. Thanks Zathras |
|
|
|
|
|
|
zathras
|
|
March 13, 2014, 06:38:05 AM
Last edit: March 13, 2014, 06:51:23 AM by zathras |
|
Hey Graz, Agree that in this case the next accept offer is ordered after the payments in the same block. But at the time the accept was transmitted, the previous payments inherently had to have been unconfirmed (for them both to be in the same block) so the sender has no way of knowing if that accept would be before or after the payments. It's much cleaner to say they're not allowed same block. I'll have to go through and add more code to support a scenario I thought we'd all agreed was not allowed (broadcasting a new accept before the previous accept has been confirmed closed). How hard is it for you guys to enforce that users can't send new accepts while the payments for the previous accepts are still unconfirmed? (ie invalidate accepts in the same block as payment for previous accept) |
|
|
|
|
grazcoin
|
|
March 13, 2014, 07:46:22 AM
Last edit: March 13, 2014, 08:02:39 AM by grazcoin |
|
Hey Graz, Agree that in this case the next accept offer is ordered after the payments in the same block. But at the time the accept was transmitted, the previous payments inherently had to have been unconfirmed (for them both to be in the same block) so the sender has no way of knowing if that accept would be before or after the payments. It's much cleaner to say they're not allowed same block. I'll have to go through and add more code to support a scenario I thought we'd all agreed was not allowed (broadcasting a new accept before the previous accept has been confirmed closed). How hard is it for you guys to enforce that users can't send new accepts while the payments for the previous accepts are still unconfirmed? (ie invalidate accepts in the same block as payment for previous accept) The mastercoin protocol is not aware of anything outside the blockchain and has no perception of "time" - only order. Users are allowed to send whichever transaction they like, and the parsing implementations enforce the protocol (e.g. sometimes by invalidating transactions). Although we think of transactions as "transmitted", we should keep in mind that they can also get included in a block by the miner without ever being transmitted. It happens very often that nodes get to know about a tx only when they get it in the next block. Those splits into blocks are random, and actually masterchain protocol could ignore them and only look on the order of the transactions in the blockchain (except for the accept timeout feature that measures expiration time using the block height). Introducing a "time" component is wrong and may cause bugs. You never know what is before or after - the blockchain order is the only consensus out there. Also a user - he has no idea when his accept gets included in the blockchain. Do you want a randomly fact like mined block to determine if his accept is valid or not? A more intuitive usage would be to fully pay his last accept, and when he is done to create a new accept. If that happened to be in the same block (as there are sometimes 1h gaps between blocks), the accept shouldn't be affected. Bottom line - I think the change you suggest is wrong. To implement it should be possible, but again - it would be another testing deployment cycle that I would rather avoid, also since we're so close to deadline. |
|
|
|
|
zathras
|
|
March 13, 2014, 08:27:49 AM |
|
Hey Graz, Agree that in this case the next accept offer is ordered after the payments in the same block. But at the time the accept was transmitted, the previous payments inherently had to have been unconfirmed (for them both to be in the same block) so the sender has no way of knowing if that accept would be before or after the payments. It's much cleaner to say they're not allowed same block. I'll have to go through and add more code to support a scenario I thought we'd all agreed was not allowed (broadcasting a new accept before the previous accept has been confirmed closed). How hard is it for you guys to enforce that users can't send new accepts while the payments for the previous accepts are still unconfirmed? (ie invalidate accepts in the same block as payment for previous accept) The mastercoin protocol is not aware of anything outside the blockchain and has no perception of "time" - only order. Users are allowed to send whichever transaction they like, and the parsing implementations enforce the protocol (e.g. sometimes by invalidating transactions). Although we think of transactions as "transmitted", we should keep in mind that they can also get included in a block by the miner without ever being transmitted. It happens very often that nodes get to know about a tx only when they get it in the next block. Those splits into blocks are random, and actually masterchain protocol could ignore them and only look on the order of the transactions in the blockchain (except for the accept timeout feature that measures expiration time using the block height). Introducing a "time" component is wrong and may cause bugs. You never know what is before or after - the blockchain order is the only consensus out there. Also a user - he has no idea when his accept gets included in the blockchain. Do you want a randomly fact like mined block to determine if his accept is valid or not? A more intuitive usage would be to fully pay his last accept, and when he is done to create a new accept. If that happened to be in the same block (as there are sometimes 1h gaps between blocks), the accept shouldn't be affected. Bottom line - I think the change you suggest is wrong. To implement it should be possible, but again - it would be another testing deployment cycle that I would rather avoid, also since we're so close to deadline. I appreciate your viewpoint but I don't think that's necessarily true. We already observe block boundaries for separating stages in a DEx transaction - for example you have to wait until an accept is confirmed in a block before sending payment (ie an accept and its associated payments can't be in the same block). When a client transmits these transactions there is no guarantee that the miner who eventually mines the next block will include the transactions in the same order they were originally broadcast. The different transactions will end up taking disparate routes to the miner that ends up mining the block and when relaying through the various hops is complete the miner may receive the first transaction after the second. Thus it's possible even though the payments were broadcast before the accept, that when the block is mined the accept is before the payments in the block. Thus when you mention random chance allowing this does exactly that - whether the accept would be valid is entirely dependent in what order the eventual mining node received them/added them to the block. Forcing things (like accepts and payments) to be confirmed in a block before moving on to the next stage I think is actually pretty core to the way our DEx operates |
|
|
|
|
