MasterCoin: New Protocol Layer Starting From “The Exodus Address” - page 118.

dacoinminster

legendary

Activity: 1260

Merit: 1031

Rational Exuberance

Quote from: zathras on September 19, 2013, 03:22:36 AM

Quote from: grazcoin on September 19, 2013, 03:10:40 AM

Quote from: zathras on September 18, 2013, 10:18:59 PM

1) The total number of Mastercoins is 619478.593384398.

Again accuracy minor issue:
We have 8 digits after the decimal point, so the number is 619478.59338440

That'll teach me for using 'calc' at work Tongue

This transaction has 4 outputs of 0.0006 - how did you consider destination vs change address?
https://blockchain.info/tx/2d69ad4c5ec9380b2da89c06ef9fd263755d70f9fe7fe0774fe8c8a2494938ee

EDIT: Answered my own question I think, loop through ambiguous address sequence numbers checking for first data packet sequence number-1.

I think somebody created that on purpose just for testing

I'm a little worried about corner cases here. Let's see if I can define some rules for processing:

All protocol transactions should have the same output amount. If one output is different, that is the change address.
If all outputs are the same, then look at sequence numbers:
- If there is a broken sequence (i.e. 3,4,8), then the odd-man-out is the change address (8 in this example)
- If there is an ambiguous sequence (i.e. 3,4,4), then the transaction is invalid!
- If there is a perfect sequence (i.e. 3,4,5), then the transaction is invalid!
  - The first version of this post had some additional rules for perfect sequences, due to the possibility of two data addresses, but then I realized that there will NEVER be two data addresses, because data addresses are only used by standard bitcoin clients for simple sends, which only have one data address. Advanced features will only run on MasterCoin clients, which can avoid ambiguity explicitly by making sure that either there is no change or that the change address has a different output than the other addresses.

I'll put those rules into the next rev of the spec.

If somebody wants to try their hand at getting some test cases like the above into the block chain, we can make sure that all clients handle them the same.

zathras

sr. member

Activity: 266

Merit: 250

Quote from: grazcoin on September 19, 2013, 03:10:40 AM

Quote from: zathras on September 18, 2013, 10:18:59 PM

1) The total number of Mastercoins is 619478.593384398.

Again accuracy minor issue:
We have 8 digits after the decimal point, so the number is 619478.59338440

That'll teach me for using 'calc' at work Tongue

This transaction has 4 outputs of 0.0006 - how did you consider destination vs change address?
https://blockchain.info/tx/2d69ad4c5ec9380b2da89c06ef9fd263755d70f9fe7fe0774fe8c8a2494938ee

EDIT: Answered my own question I think, loop through ambiguous address sequence numbers checking for first data packet sequence number-1.

zathras

sr. member

Activity: 266

Merit: 250

Quote from: zathras on September 18, 2013, 06:19:32 AM

Quote from: grazcoin on September 18, 2013, 05:53:18 AM

Quote from: zathras on September 18, 2013, 04:46:00 AM

OK fixed, I was being a little strict with my block time verification.

Please to say my code is now calculating a total equal to the implementations from others

Take care - I think you missed 2 dacoins, probably rounding 18 dacoins to 20.
With currency systems, accuracy is very important, and in our case it is 8 places after the decimal point.

Thanks. Yep 8 decimal places is what I'm working with - the actual figure is 563,162.35762208 which is != 563,162.35762218 so there is still a slight discrepancy I'll need to trace.

EDIT: Transactions are written to the database to 8 decimal digits but I'm using raw values from the bonus calcs in the total calculation which may explain the slight skew, will look into it further.

Quick update on the above - when I query the database directly (select sum) I get the correct number of dacoins - 563,162.35762218. The skew was introduced by my using an array which held my raw (>8 decimal places) instead of my processed (8 decimal place) values.

grazcoin

sr. member

Activity: 284

Merit: 250

Quote from: zathras on September 18, 2013, 10:18:59 PM

1) The total number of Mastercoins is 619478.593384398.

Again accuracy minor issue:
We have 8 digits after the decimal point, so the number is 619478.59338440

zathras

sr. member

Activity: 266

Merit: 250

Quote from: dacoinminster on September 18, 2013, 07:11:13 PM

It sounds mostly like a question of presentation. I'm fine with treating the coins as "created but not spendable" if that is a better message to the layperson.

Nice work so far (judging from the screenshots). I can't wait to see more!

Great stuff, thanks. Completely agree it's an issue of presentation and I think now we're clear on this we can make the following explicit statements:

1) The total number of Mastercoins is 619478.593384398.
2) No new Mastercoins will ever be created.

By having those statements explicit (rather than with caveats such as (paraphrasing) "with the exception of new coins awarded to the dev fund" etc) we are simplifying the overview for new entrants I believe.

Thanks, I'm working through my milestones but I'm sure you know how it is with other commitments (job/family) etc - so far I've found it easier to sacrifice something else (sleep!).

dacoinminster

legendary

Activity: 1260

Merit: 1031

Rational Exuberance

Quote from: zathras on September 18, 2013, 04:15:31 PM

Sorry to hear you're unwell Tachikoma Sad

JR, as per my question above re reward Mastercoins; I think it would be prudent to clarify - please consider the following:
Sce1) Reward Mastercoins were created along with each 10 Mastercoin purchase at the same point in time (ie during August), but cannot be spent until they have been awarded to the Exodus address
Sce2) Reward Mastercoins are created at the point in time they are awarded to the Exodus address

I concur the total number of coins does not change in either case, but let's play semantics for a moment - consider how the layperson may interpret:
Sce1) Mastercoins have all been minted (created) and no more will ever be created (layperson may interpret as fixed/finite supply of coins)
Sce2) A small number of Mastercoins are created in an ongoing/continuing process (layperson may interpret as increasing supply of coins)

For those involved in Mastercoin, we can recognize that both provide the same total supply of coins of course. This may be considered a non-issue and perhaps I'm overthinking it, but I thought whilst less technically relevant it could have a bearing on certain perceptions of Mastercoin.

Going back to the nuts and bolts, I'm including reward Mastercoins in my implementation starting @ 1377993600 for now.

EDIT: Missed your storage Q - no work done on Tachikoma's suggested storage approach as yet I'm still knee deep in my base wallet & explorer implementation.

It sounds mostly like a question of presentation. I'm fine with treating the coins as "created but not spendable" if that is a better message to the layperson.

Nice work so far (judging from the screenshots). I can't wait to see more!

bybitcoin

hero member

Activity: 672

Merit: 500

Quote from: Tachikoma on September 18, 2013, 03:18:04 PM

I've been under the weather these past days and bound to bed. I have done some initial work and I will be releasing some source code as soon I've fought of this flu

Sorry to ask this, a long thread: are you coding in c++ or java or perhaps python? I am thinking about joining the force but am not sure yet

zathras

sr. member

Activity: 266

Merit: 250

Sorry to hear you're unwell Tachikoma Sad

JR, as per my question above re reward Mastercoins; I think it would be prudent to clarify - please consider the following:
Sce1) Reward Mastercoins were created along with each 10 Mastercoin purchase at the same point in time (ie during August), but cannot be spent until they have been awarded to the Exodus address
Sce2) Reward Mastercoins are created at the point in time they are awarded to the Exodus address

I concur the total number of coins does not change in either case, but let's play semantics for a moment - consider how the layperson may interpret:
Sce1) Mastercoins have all been minted (created) and no more will ever be created (layperson may interpret as fixed/finite supply of coins)
Sce2) A small number of Mastercoins are created in an ongoing/continuing process (layperson may interpret as increasing supply of coins)

For those involved in Mastercoin, we can recognize that both provide the same total supply of coins of course. This may be considered a non-issue and perhaps I'm overthinking it, but I thought whilst less technically relevant it could have a bearing on certain perceptions of Mastercoin.

Going back to the nuts and bolts, I'm including reward Mastercoins in my implementation starting @ 1377993600 for now.

EDIT: Missed your storage Q - no work done on Tachikoma's suggested storage approach as yet I'm still knee deep in my base wallet & explorer implementation.

Tachikoma

hero member

Activity: 938

Merit: 1000

I've been under the weather these past days and bound to bed. I have done some initial work and I will be releasing some source code as soon I've fought of this flu

dacoinminster

legendary

Activity: 1260

Merit: 1031

Rational Exuberance

One thing I haven't seen any discussion of (and I don't think I mentioned explicitly in the spec) is the continuous nature of the function describing the vesting of the 10% coins. That is, you can feed 0.5 years into that equation. Technically, a small number of them are spendable right now. To my knowledge, nobody currently recognizes those coins.

Also, I didn't explicitly say the date to start counting from - I think September 1st 2013 makes sense. By my calculations, ~0.05 years have passed since then, so (1 - 0.5^0.05) = ~3.4% of the 10% would currently be unlocked. I'll try to make these details clear in the next rev of the spec.

I have no plans to use those MasterCoins soon, so I don't care much about recognizing them now, but they will probably be used at some point as part of a compensation package for full-time employees - kind of like vesting stock options.

I love seeing the collaboration here. Is anybody working on using Tachikoma's new method of data storage yet? I assume he is, at least . . .

zathras

sr. member

Activity: 266

Merit: 250

Quote from: grazcoin on September 18, 2013, 05:53:18 AM

Quote from: zathras on September 18, 2013, 04:46:00 AM

OK fixed, I was being a little strict with my block time verification.

Please to say my code is now calculating a total equal to the implementations from others

Take care - I think you missed 2 dacoins, probably rounding 18 dacoins to 20.
With currency systems, accuracy is very important, and in our case it is 8 places after the decimal point.

Thanks. Yep 8 decimal places is what I'm working with - the actual figure is 563,162.35762208 which is != 563,162.35762218 so there is still a slight discrepancy I'll need to trace.

EDIT: Transactions are written to the database to 8 decimal digits but I'm using raw values from the bonus calcs in the total calculation which may explain the slight skew, will look into it further.

grazcoin

sr. member

Activity: 284

Merit: 250

Quote from: zathras on September 18, 2013, 04:46:00 AM

OK fixed, I was being a little strict with my block time verification.

Please to say my code is now calculating a total equal to the implementations from others

Take care - I think you missed 2 dacoins, probably rounding 18 dacoins to 20.
With currency systems, accuracy is very important, and in our case it is 8 places after the decimal point.

zathras

sr. member

Activity: 266

Merit: 250

OK fixed, I was being a little strict with my block time verification.

Please to say my code is now calculating a total equal to the implementations from others

P.S. that screenie is simply dev code to help me build an implementation to interact with bitcoind's RPC server and loop through the transactions in each block to parse mastercoin data - the web front end etc is still progressing nicely and will be the UI once I get to the stage of opening it up.

zathras

sr. member

Activity: 266

Merit: 250

Using your CSV file of exodus purchases and running that against my implementation I come up with two addresses with discrepancies:
1Bqp4VEweM1S8FKGHWYviRRtSxv5tMAVih
1KDCt8VoY45ya3QnExwtZEdugAnRAncr1Z

The difference in amount is ~3859.95, which if added to 559302.41 comes out at the same total yourself and Tachikoma have (563162.36).

Bug somewhere in my code. Hunting time.

EDIT: Both transactions have purchases in block 255365 & those values account for the discrepancies. It's been agreed that purchases in that block will be included I believe.

zathras

sr. member

Activity: 266

Merit: 250

Quote from: grazcoin on September 18, 2013, 03:39:35 AM

Quote from: zathras on September 18, 2013, 01:25:39 AM

Tachikoma, on mastercoin-explorer you have a total MSC of 563,162.36 - could you advise how you are reaching this result? Are you including anything other than Exodus purchases?

My code calculates the total purchased from the Exodus address to be 559,302.41, then when the 10% dev fund is added on I make the total MSC created during the 'minting' if you will to be 615,232.65.

Given that Mastercoins will never again be created (ie both the initial mastercoins and the delayed reward dev fund were 'minted' during August, a once off process) and thus the total number of MSC should forever stay fixed unless they start getting destroyed for some reason. If my reasoning is accurate then we should be able to define 'THE' fixed number of MSC that exist, a number that should not change and put that fundamental to bed once and for all.

Edit: occurs to me reading the spec - "For every 10 MasterCoins sold, an additional “reward MasterCoin” will also be created which will be awarded to the Exodus Address slowly over the following years" -I would read this as implying the 'reward mastercoin' was created at the point in time the 10 mastercoins were sold, thus all 'reward mastercoins' have already been created, but are not spendable until they are awarded. Is this interpretation in line with your intentions JR?

You can see the exact calculation on:
https://github.com/grazcoin/mastercoin-tools/blob/master/msc_bootstrap.py
the result of msc per exodus address on:
https://github.com/grazcoin/mastercoin-tools/blob/master/outputs/msc_per_address.csv
and the exact total sum is:
563162.35762218
Tachikoma has confirmed that out calculations agree.

It is possible to interpret that the 10% were already generated and they are not yet spendable.
Trying to keep the bitcoins interpretation i.e. ~21M BTC will be generated, but we still consider a bitcoin existence only after it got mined, I rather use the dual approach and interpret it in a way that every year new mastercoins are being born, and only then they exist.

If you insist on your view, than the calculation is:
563162.35762218 * 110% = 619478.593384398 -> 619478.59338440

There is absolutely no practical difference between those views.

Thanks for the feedback. I have no strong views on the reward mastercoins either way, but ambiguity is bad so would be good to get locked away...

I'm going through my code looking for discrepancy - just ran through your list of differing values and mine seem to agree with yours:

Code:

Masterchest has: 107.00200066 ,Explorer has: 11000200066, Tools has: 10700200066 for 12LSJoCAqvVQyvW5qaKGp6ZKMaaZpUcCv3
Masterchest has: 6996.19940476, Explorer has: 574619940476, Tools has: 699619940476 for 12bDX26J84x545pzfSZouULeqjfBtAe9Lv
Masterchest has: 211.34827433, Explorer has: 21234827433, Tools has: 21134827433 for 13P8CSqRoboefrNsXKZieWYtZhJ4KcQHhH
Masterchest has: 36.08607308, Explorer has: 4058607308, Tools has: 3608607308 for 13qJCzNQUx7dFcixjq9Rab7wPgUCtYS48v
Masterchest has: 10.87679398, Explorer has: 2087679398, Tools has: 1087679398 for 13x2dka6tVhjsNNNomGJjUPi2iJQCb67bw
Masterchest has: 246.01309524, Explorer has: 24701309524, Tools has: 24601309524 for 158qYAqDu4GKeVHDiTYA2xAu5Ew4sEU2Ug
Masterchest has: 529.3432826, Explorer has: 39434328263, Tools has: 52934328263 for 15og4WXZPwkMnnsb3dj6HqgTUfcRLx4J9b
Masterchest has: 531.68692130, Explorer has: 53568692130, Tools has: 53168692130 for 16QkgycuGwFvwQ8oZ5cYHgVjDNSavcwovS
Masterchest has: 60.56807478, Explorer has: 7056807478, Tools has: 6056807478 for 17QqwZtZ221Dod33bY33SAZMXrSmi89rsP
Masterchest has: 101.73350529, Explorer has: 10273350529, Tools has: 10173350529 for 1AgZvwAoNDFGkQYEF193RAm3qxipWAEFAH
Masterchest has: 151.42266518, Explorer has: 15342266518, Tools has: 15142266518 for 1ApWmGDViVjTPqRKBhPydpBZ5DRjpuEEic
Masterchest has: 101.27878638, Explorer has: 10227878638, Tools has: 10127878638 for 1Bitcoin4yZjSSPoXUceJaiyQLABx7B2LL
Masterchest has: 5017.80257937, Explorer has: 501650257937, Tools has: 501780257937 for 1Eo6FGPytuYvuA3ZS6ToXqP8sScWWtKhWN
Masterchest has: 57.20500793, Explorer has: 2220500793, Tools has: 5720500793 for 1GaNupdUBzfVF2B3JUAY1rZwHoXJgjyzXj
Masterchest has: 101.03326720, Explorer has: 9933326720, Tools has: 10103326720 for 1K5Tofy7UTfcrpWBnXcJhHZzvLTksDdasQ
Masterchest has: 3003.15819775, Explorer has: 301315819775, Tools has: 300315819775 for 1K5ZEkQ8Pzwqedg2WHsKQd3xiAGnj7MeCD
Masterchest has: 317.76650397, Explorer has: 32276650397, Tools has: 31776650397 for 1Kk6eLpM3cpgC4NEzXLzjKvdndd8bPox6f
Masterchest has: 107.12380845, Explorer has: 10812380845, Tools has: 10712380845 for 1LjT88X7Zu8BdbqJw8vfRa83NJuzYL9kqm
Masterchest has: 104.76380622, Explorer has: 10526380622, Tools has: 10476380622 for 1donutMH4L7kdRqh4xvSvesfd3KFu3UNm

Could you please let me know the total count of transactions you are considering mastercoin purchases from the Exodus address?

Thanks

grazcoin

sr. member

Activity: 284

Merit: 250

Quote from: zathras on September 18, 2013, 01:25:39 AM

Tachikoma, on mastercoin-explorer you have a total MSC of 563,162.36 - could you advise how you are reaching this result? Are you including anything other than Exodus purchases?

My code calculates the total purchased from the Exodus address to be 559,302.41, then when the 10% dev fund is added on I make the total MSC created during the 'minting' if you will to be 615,232.65.

Given that Mastercoins will never again be created (ie both the initial mastercoins and the delayed reward dev fund were 'minted' during August, a once off process) and thus the total number of MSC should forever stay fixed unless they start getting destroyed for some reason. If my reasoning is accurate then we should be able to define 'THE' fixed number of MSC that exist, a number that should not change and put that fundamental to bed once and for all.

Edit: occurs to me reading the spec - "For every 10 MasterCoins sold, an additional “reward MasterCoin” will also be created which will be awarded to the Exodus Address slowly over the following years" -I would read this as implying the 'reward mastercoin' was created at the point in time the 10 mastercoins were sold, thus all 'reward mastercoins' have already been created, but are not spendable until they are awarded. Is this interpretation in line with your intentions JR?

You can see the exact calculation on:
https://github.com/grazcoin/mastercoin-tools/blob/master/msc_bootstrap.py
the result of msc per exodus address on:
https://github.com/grazcoin/mastercoin-tools/blob/master/outputs/msc_per_address.csv
and the exact total sum is:
563162.35762218
Tachikoma has confirmed that out calculations agree.

It is possible to interpret that the 10% were already generated and they are not yet spendable.
Trying to keep the bitcoins interpretation i.e. ~21M BTC will be generated, but we still consider a bitcoin existence only after it got mined, I rather use the dual approach and interpret it in a way that every year new mastercoins are being born, and only then they exist.

If you insist on your view, than the calculation is:
563162.35762218 * 110% = 619478.593384398 -> 619478.59338440

There is absolutely no practical difference between those views.

grazcoin

sr. member

Activity: 284

Merit: 250

Quote from: Tachikoma on September 11, 2013, 01:20:50 PM

Quote from: grazcoin on September 11, 2013, 12:12:51 PM

Quote from: dacoinminster on September 10, 2013, 04:07:30 PM

Yup, biggest contributor gets the coins. I believe the latest rev of the spec now says this explicitly.

This is a convenience for the user, especially those that bought from twenty different addresses at once. I know it makes the parsing a bit trickier . . .

https://github.com/grazcoin/mastercoin-tools got updated.
Tachikoma: can you please verify that mastercoin per address of mastercoin-tools and mastercoin-explorer is identical?
https://raw.github.com/grazcoin/mastercoin-tools/master/outputs/msc_per_address.csv

19 differences

Code:

Explorer has: 11000200066, Tools has: 10700200066 for 12LSJoCAqvVQyvW5qaKGp6ZKMaaZpUcCv3
Explorer has: 574619940476, Tools has: 699619940476 for 12bDX26J84x545pzfSZouULeqjfBtAe9Lv
Explorer has: 21234827433, Tools has: 21134827433 for 13P8CSqRoboefrNsXKZieWYtZhJ4KcQHhH
Explorer has: 4058607308, Tools has: 3608607308 for 13qJCzNQUx7dFcixjq9Rab7wPgUCtYS48v
Explorer has: 2087679398, Tools has: 1087679398 for 13x2dka6tVhjsNNNomGJjUPi2iJQCb67bw
Explorer has: 24701309524, Tools has: 24601309524 for 158qYAqDu4GKeVHDiTYA2xAu5Ew4sEU2Ug
Explorer has: 39434328263, Tools has: 52934328263 for 15og4WXZPwkMnnsb3dj6HqgTUfcRLx4J9b
Explorer has: 53568692130, Tools has: 53168692130 for 16QkgycuGwFvwQ8oZ5cYHgVjDNSavcwovS
Explorer has: 7056807478, Tools has: 6056807478 for 17QqwZtZ221Dod33bY33SAZMXrSmi89rsP
Explorer has: 10273350529, Tools has: 10173350529 for 1AgZvwAoNDFGkQYEF193RAm3qxipWAEFAH
Explorer has: 15342266518, Tools has: 15142266518 for 1ApWmGDViVjTPqRKBhPydpBZ5DRjpuEEic
Explorer has: 10227878638, Tools has: 10127878638 for 1Bitcoin4yZjSSPoXUceJaiyQLABx7B2LL
Explorer has: 501650257937, Tools has: 501780257937 for 1Eo6FGPytuYvuA3ZS6ToXqP8sScWWtKhWN
Explorer has: 2220500793, Tools has: 5720500793 for 1GaNupdUBzfVF2B3JUAY1rZwHoXJgjyzXj
Explorer has: 9933326720, Tools has: 10103326720 for 1K5Tofy7UTfcrpWBnXcJhHZzvLTksDdasQ
Explorer has: 301315819775, Tools has: 300315819775 for 1K5ZEkQ8Pzwqedg2WHsKQd3xiAGnj7MeCD
Explorer has: 32276650397, Tools has: 31776650397 for 1Kk6eLpM3cpgC4NEzXLzjKvdndd8bPox6f
Explorer has: 10812380845, Tools has: 10712380845 for 1LjT88X7Zu8BdbqJw8vfRa83NJuzYL9kqm
Explorer has: 10526380622, Tools has: 10476380622 for 1donutMH4L7kdRqh4xvSvesfd3KFu3UNm

Diving into the why right now

Edit: Are you counting incoming/outgoing payments towards the balance; or is this just exodus payments? If the latter that accounts for the difference

I just noticed that mastercoin-explorer.com added "Bought via Exodus" field, which has the exact values that msc_bootstrap.py of mastercoin-tools generated.
https://github.com/grazcoin/mastercoin-tools/blob/master/msc_bootstrap.py checks only the bootstrap phase, which means only "Bought via Exodus", so it fits.
The parsing of transactions is done separately on https://github.com/grazcoin/mastercoin-tools/blob/master/msc_parse.py

bottom line: we're still in sync (at least with the current transactions).

zathras

sr. member

Activity: 266

Merit: 250

Tachikoma, on mastercoin-explorer you have a total MSC of 563,162.36 - could you advise how you are reaching this result? Are you including anything other than Exodus purchases?

My code calculates the total purchased from the Exodus address to be 559,302.41, then when the 10% dev fund is added on I make the total MSC created during the 'minting' if you will to be 615,232.65.

Given that Mastercoins will never again be created (ie both the initial mastercoins and the delayed reward dev fund were 'minted' during August, a once off process) and thus the total number of MSC should forever stay fixed unless they start getting destroyed for some reason. If my reasoning is accurate then we should be able to define 'THE' fixed number of MSC that exist, a number that should not change and put that fundamental to bed once and for all.

Edit: occurs to me reading the spec - "For every 10 MasterCoins sold, an additional “reward MasterCoin” will also be created which will be awarded to the Exodus Address slowly over the following years" -I would read this as implying the 'reward mastercoin' was created at the point in time the 10 mastercoins were sold, thus all 'reward mastercoins' have already been created, but are not spendable until they are awarded. Is this interpretation in line with your intentions JR?

dacoinminster

legendary

Activity: 1260

Merit: 1031

Rational Exuberance

Quote from: Tachikoma on September 17, 2013, 12:53:56 PM

I really appreciate the answer. I am happy that even though you are probably not a big supporter of Mastercoin you still take the time to answer a question that is in essence a Bitcoin question.

Before deciding on a spec I think we should exhaust every option presented to us. I will see if I can find a way of doing it via P2SH if that really is the best way to prevent any type of bloat. If that is indeed not possible I suggest we switch to multisig encryption until OP_RETURN becomes available at what time we can switch back to using address encoded data.

Emphatically agreed! Thanks everybody - I think we have a pretty clear path ahead of us now.

Tachikoma

hero member

Activity: 938

Merit: 1000

Quote from: jgarzik on September 17, 2013, 12:45:02 PM

Quote from: Tachikoma on September 17, 2013, 09:52:02 AM

Quote from: killerstorm on September 16, 2013, 04:50:44 PM

CHECKMULTISIG works right now (as far as I know), and arguments against it are largely theoretical: it does bloat UTXO space, but currently it isn't a limiting factor.

It is important that CHECKMULTISIG doesn't do permanent damage, unlike your current approach which does permanent damage.

The way I understand it is that the UTXO space can only bloat when an output is not-redeemable. Since the suggest multisig implementation uses a real/existing publickey it can always be redeemed. This holds true as long as my understanding of multisig outputs is correct. Since people are still worried about bloat I can only come to the conclusion that my understanding is wrong.

Making the outputs redeemable is a good and welcome improvement -- but that doesn't eliminate their UTXO storage cost. It just makes that storage recoverable and transferable.

The extraneous data continues to be stored in the UTXO set, with this multisig method. One person may redeem a MasterCoin multisig transaction, yes, but the payment target will just create another multisig output that consumes similar amount of UTXO storage space. The data continues to bloat the UTXO dataset, because there is always some multisig output sitting around, waiting to be spent.

Quote from: killerstorm on September 16, 2013, 04:50:44 PM

So my advice would be:

1. switch to CHECKMULTISIG ASAP
2. make it possible to use OP_RETURN approach

What I (think) to know about OP_RETURN is that it basically creates an unspendable output but at least we know it's unspendable. This is basically a way to destroy coins. Is this correct? And if so is this preferable to having increased UTXO space (if I indeed misunderstand spending multisigs).

Correct. OP_RETURN data is provably not spendable. Anything provably unspendable may be eliminated from the UTXO data set.

Note! Besides OP_RETURN, there is yet another possibility: P2SH: https://en.bitcoin.it/wiki/BIP_0016

With P2SH, the MasterCoin data could be stored in the input scriptSig, as a part of redeeming. This may be unworkable, because the MasterCoin data would only be revealed when you spend a MasterCoin, and not when you receive a MasterCoin.

I really appreciate the answer. I am happy that even though you are probably not a big supporter of Mastercoin you still take the time to answer a question that is in essence a Bitcoin question.

Before deciding on a spec I think we should exhaust every option presented to us. I will see if I can find a way of doing it via P2SH if that really is the best way to prevent any type of bloat. If that is indeed not possible I suggest we switch to multisig encryption until OP_RETURN becomes available at what time we can switch back to using address encoded data.

Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address” - page 118. (Read 448462 times)