Bitcoin Forum
April 25, 2019, 12:57:44 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 ... 166 »
  Print  
Author Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address”  (Read 447605 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
ldrgn
Member
**
Offline Offline

Activity: 118
Merit: 10


View Profile
September 09, 2013, 07:02:02 PM
 #841

Haven't read the thread, but may eventually.  If this stuff was brought up before that's great, otherwise idk how everyone ignored it for so long:

General notes:
  • if you can get a PKI in the blockchain using this system that single feature would make MasterCoin actually viable.  Seriously, everything in here is schlock compared to that.
  • URLs in the prospectus messages is a pretty useful idea, it's probably worth having your MasterCoin foundation buy a domain and use it as an official shortener.  Alternatively if you still want everything in the blockchain I'd have a special URL message type with the ability for other messages to refer to it and the ability for the URL messages to succeed each other.
  • Pretty much everything here would benefit from a 'prospectus' parent message with a numeric ID (or pubkey) and 'update' messages that reference the parent rather than re-specify all the bajillion little details
  • Even if you're not coding you can start outlining a test suite now


Data streams:
  • You use strings but don't mention encodings?  What have you been working on for the past 10 years of software experience?  The 80s are over brah.
  • I think you're greatly underestimating the value of identity for a data stream, especially for one where you have to pay to get the data into the blockchain[0].  If you're going to the step of paying to put it into the blockchain and distribute it publicly like that it's likely that people are interested in your exact stream and not a generic category like Commodities::Metals::Gold.  So why keep the categorization in the blockchain and waste your precious transaction space?  Why use the serial number (unique identifier in the spec) at all?  Why not just stick to the source address as the identifier for a stream and leave it at that?  Nobody's interested in "Gold", they're interested in "The gold spot price at xyz exchange as published by the xyz exchange".  The whole category system is pointlessly wasteful.
  • It would be cool to keep data feeds optionally encrypted for paid services but this might necessitate a PKI (also another useful thing to build)
  • It would be cool to have the feed choose what the multiplier goes against (another sub-currency or another feed).  That's a much more useful use of transaction space than the category c strings.
  • You need to have 'update' and 'prospectus' message types to save on size/cost

Bets:

It seems like you would be better served by implementing a scripting language allowing you to express conditionals for contracts of all types rather than the somewhat specific bet transaction type.

Smart Property:
  • This is woefully under-specified.  Issuing new shares is a critical part of financing any business.
  • Why do you waste space on another string identifier (redundant, addresses fill that role much better) but don't leave space for a URL (something actually useful?)
  • Once again a place that would benefit from a scripting language for contracts/trades

Currency stabilization:
In general this is antithetical to the idea of a decentralized currency - someone in authority needs to pick a data stream and use it for your hedging.  So why keep all this stuff in the blockchain if it's not decentralized?  You're making an inefficient and wasteful service by keeping it there.

  • You need to specify the formulas/algorithms that are going to be used for hedging!!!!!!!!
  • You need to publish a paper modelling these algorithms and showing possible outcomes, measuring risk and generally throwing the wall at it under simulation.  Anything else is not due diligence.
  • Another string as an identifier, wtf mate

You might have experience as a programmer but I take it you're not a systems guy.  Find someone who is and have them draft the spec.  You might not be familiar with hedging algorithms but you've got one implemented for the currency stabilization process.  Either find one and have them write a paper for you or dig up what the finance guys have in their literature and refer to it.  You don't have a bibliography and that's a bad thing, there is a whole lot here that is not novel and needs to be referenced so everyone knows you're not butting heads with what's generally held to be true.  tl;dr shoddy work designed by the clueless and implemented by the fools that follow them, stay away
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1556153864
Hero Member
*
Offline Offline

Posts: 1556153864

View Profile Personal Message (Offline)

Ignore
1556153864
Reply with quote  #2

1556153864
Report to moderator
dacoinminster
Legendary
*
Offline Offline

Activity: 1260
Merit: 1022


Rational Exuberance


View Profile WWW
September 09, 2013, 07:40:25 PM
 #842

Haven't read the thread, but may eventually.  If this stuff was brought up before that's great, otherwise idk how everyone ignored it for so long:

General notes:
  • if you can get a PKI in the blockchain using this system that single feature would make MasterCoin actually viable.  Seriously, everything in here is schlock compared to that.
  • URLs in the prospectus messages is a pretty useful idea, it's probably worth having your MasterCoin foundation buy a domain and use it as an official shortener.  Alternatively if you still want everything in the blockchain I'd have a special URL message type with the ability for other messages to refer to it and the ability for the URL messages to succeed each other.
  • Pretty much everything here would benefit from a 'prospectus' parent message with a numeric ID (or pubkey) and 'update' messages that reference the parent rather than re-specify all the bajillion little details
  • Even if you're not coding you can start outlining a test suite now


Data streams:
  • You use strings but don't mention encodings?  What have you been working on for the past 10 years of software experience?  The 80s are over brah.
  • I think you're greatly underestimating the value of identity for a data stream, especially for one where you have to pay to get the data into the blockchain[0].  If you're going to the step of paying to put it into the blockchain and distribute it publicly like that it's likely that people are interested in your exact stream and not a generic category like Commodities::Metals::Gold.  So why keep the categorization in the blockchain and waste your precious transaction space?  Why use the serial number (unique identifier in the spec) at all?  Why not just stick to the source address as the identifier for a stream and leave it at that?  Nobody's interested in "Gold", they're interested in "The gold spot price at xyz exchange as published by the xyz exchange".  The whole category system is pointlessly wasteful.
  • It would be cool to keep data feeds optionally encrypted for paid services but this might necessitate a PKI (also another useful thing to build)
  • It would be cool to have the feed choose what the multiplier goes against (another sub-currency or another feed).  That's a much more useful use of transaction space than the category c strings.
  • You need to have 'update' and 'prospectus' message types to save on size/cost

Bets:

It seems like you would be better served by implementing a scripting language allowing you to express conditionals for contracts of all types rather than the somewhat specific bet transaction type.

Smart Property:
  • This is woefully under-specified.  Issuing new shares is a critical part of financing any business.
  • Why do you waste space on another string identifier (redundant, addresses fill that role much better) but don't leave space for a URL (something actually useful?)
  • Once again a place that would benefit from a scripting language for contracts/trades

Currency stabilization:
In general this is antithetical to the idea of a decentralized currency - someone in authority needs to pick a data stream and use it for your hedging.  So why keep all this stuff in the blockchain if it's not decentralized?  You're making an inefficient and wasteful service by keeping it there.

  • You need to specify the formulas/algorithms that are going to be used for hedging!!!!!!!!
  • You need to publish a paper modelling these algorithms and showing possible outcomes, measuring risk and generally throwing the wall at it under simulation.  Anything else is not due diligence.
  • Another string as an identifier, wtf mate

You might have experience as a programmer but I take it you're not a systems guy.  Find someone who is and have them draft the spec.  You might not be familiar with hedging algorithms but you've got one implemented for the currency stabilization process.  Either find one and have them write a paper for you or dig up what the finance guys have in their literature and refer to it.  You don't have a bibliography and that's a bad thing, there is a whole lot here that is not novel and needs to be referenced so everyone knows you're not butting heads with what's generally held to be true.  tl;dr shoddy work designed by the clueless and implemented by the fools that follow them, stay away

I certainly can't stop people for escaping unicode characters in the ASCII strings if that is what they want to do, but I'm trying to keep the spec simple, with a tiny footprint in the block chain, so I'm not including unicode support in the spec out of the gate. I believe internationalization effort should be mostly client-side, and via URLs which have been shortened, as you alluded to.

As for the rest, I look forward to seeing your much-improved spec, or anybody else's for that matter. I waited a long time for somebody else to take a crack at this, and finally got tired of waiting, but maybe now that I have demonstrated the fund-raising method others will take a shot. We'll do our best to shamelessly steal any good ideas we see Smiley

ripper234
Legendary
*
Offline Offline

Activity: 1274
Merit: 1000


Ron Gross


View Profile WWW
September 09, 2013, 08:06:10 PM
 #843

Woah, nice addition.

Can the spec be moved to github, for better history tracking and pull requests?

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
September 09, 2013, 08:19:56 PM
 #844

Sorry, wall of text incoming Smiley


Tachikoma's opinion on this issue matters a lot to me, since he has the best implementation of MasterCoin so far. Tachikoma, are you willing to update your code to recognize transactions through block 255365?

I'm absolutely firm on one thing though - I don't want to include more blocks beyond 255365 unless they can be shown to contain MasterCoin purchases sent before the deadline!

I'm updating the code right now to include everything up to and including 255365. Nothing we can do about it now but I think the spec should be more pro-active to prevent problems like this in the future.

The only caveat is that you'll have to release the source code at the end of the contest, which I assume won't be a problem

I always planned to release the underlying libraries but originally did not plan to release the source code to the website since it's just one implementation of the library itself.

  • Specified that advanced features (beyond simple send) need to wait for a better way to store our data in the block chain

This a thousand times. It's very easy to extend the functionality once there is a proper way to store data in the chain. I will focus on this next if nobody comes forward with a way to do this in the next few days.

Spec Updated to 1.1
I did not re-read it yet so forgive me if you already did this. Did you describe which timestamps to use for transactions and how to deal multiple transactions from the same user in the same block (especially if not all transactions can be satisfied)? (See discussion on the previous page)

Tachikoma has done some great work on it so far, on his own volition. Its looks awesome and it's appreciated by everyone who invested. However, the project is barely out of the conceptual stage. Do you really want to start playing loose and fast with the investment funds? Wouldn't it be better to have a structured Bounty/Reward system laid out and discuss this kind of thing with the board before throwing out random offers?

I tend to agree. This project is barely started up and there is so much work to be done still. Although I really appreciate the gesture I think a formal bounty system would benefit Mastercoin better. I will see what I can do to just claim some bounties Smiley

Although I have no problems releasing my code but I really want to motivate others to build the same stuff I did. In order for Mastercoin to work a dialog needs to happen between developers. A lot of things in Mastercoin are open for interpretation and having multiple coders working on it in their own code might bring the problems to the surface. The other problem with releasing it now is that a lot of stuff that's written at the moment won't work when we implement a new method to encode the data and it won't work with anything other then simple send. I rather release it once these problems have been solved so it's at least future complete.

Lastly; thanks everybody for the compliments; I am happy that my work these past days is appreciated Smiley

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
maraoz
Newbie
*
Offline Offline

Activity: 55
Merit: 0



View Profile
September 09, 2013, 08:20:26 PM
 #845

Haven't read the thread, but may eventually.  If this stuff was brought up before that's great, otherwise idk how everyone ignored it for so long:

General notes:
  • if you can get a PKI in the blockchain using this system that single feature would make MasterCoin actually viable.  Seriously, everything in here is schlock compared to that.
  • URLs in the prospectus messages is a pretty useful idea, it's probably worth having your MasterCoin foundation buy a domain and use it as an official shortener.  Alternatively if you still want everything in the blockchain I'd have a special URL message type with the ability for other messages to refer to it and the ability for the URL messages to succeed each other.
  • Pretty much everything here would benefit from a 'prospectus' parent message with a numeric ID (or pubkey) and 'update' messages that reference the parent rather than re-specify all the bajillion little details
  • Even if you're not coding you can start outlining a test suite now


Data streams:
  • You use strings but don't mention encodings?  What have you been working on for the past 10 years of software experience?  The 80s are over brah.
  • I think you're greatly underestimating the value of identity for a data stream, especially for one where you have to pay to get the data into the blockchain[0].  If you're going to the step of paying to put it into the blockchain and distribute it publicly like that it's likely that people are interested in your exact stream and not a generic category like Commodities::Metals::Gold.  So why keep the categorization in the blockchain and waste your precious transaction space?  Why use the serial number (unique identifier in the spec) at all?  Why not just stick to the source address as the identifier for a stream and leave it at that?  Nobody's interested in "Gold", they're interested in "The gold spot price at xyz exchange as published by the xyz exchange".  The whole category system is pointlessly wasteful.
  • It would be cool to keep data feeds optionally encrypted for paid services but this might necessitate a PKI (also another useful thing to build)
  • It would be cool to have the feed choose what the multiplier goes against (another sub-currency or another feed).  That's a much more useful use of transaction space than the category c strings.
  • You need to have 'update' and 'prospectus' message types to save on size/cost

Bets:

It seems like you would be better served by implementing a scripting language allowing you to express conditionals for contracts of all types rather than the somewhat specific bet transaction type.

Smart Property:
  • This is woefully under-specified.  Issuing new shares is a critical part of financing any business.
  • Why do you waste space on another string identifier (redundant, addresses fill that role much better) but don't leave space for a URL (something actually useful?)
  • Once again a place that would benefit from a scripting language for contracts/trades

Currency stabilization:
In general this is antithetical to the idea of a decentralized currency - someone in authority needs to pick a data stream and use it for your hedging.  So why keep all this stuff in the blockchain if it's not decentralized?  You're making an inefficient and wasteful service by keeping it there.

  • You need to specify the formulas/algorithms that are going to be used for hedging!!!!!!!!
  • You need to publish a paper modelling these algorithms and showing possible outcomes, measuring risk and generally throwing the wall at it under simulation.  Anything else is not due diligence.
  • Another string as an identifier, wtf mate

You might have experience as a programmer but I take it you're not a systems guy.  Find someone who is and have them draft the spec.  You might not be familiar with hedging algorithms but you've got one implemented for the currency stabilization process.  Either find one and have them write a paper for you or dig up what the finance guys have in their literature and refer to it.  You don't have a bibliography and that's a bad thing, there is a whole lot here that is not novel and needs to be referenced so everyone knows you're not butting heads with what's generally held to be true.  tl;dr shoddy work designed by the clueless and implemented by the fools that follow them, stay away

Great feedback. The final aggression was unnecessary, though. I don't know why people on this forum tend to attack people instead of ideas...
dacoinminster
Legendary
*
Offline Offline

Activity: 1260
Merit: 1022


Rational Exuberance


View Profile WWW
September 09, 2013, 08:45:21 PM
 #846

Sorry, wall of text incoming Smiley


Tachikoma's opinion on this issue matters a lot to me, since he has the best implementation of MasterCoin so far. Tachikoma, are you willing to update your code to recognize transactions through block 255365?

I'm absolutely firm on one thing though - I don't want to include more blocks beyond 255365 unless they can be shown to contain MasterCoin purchases sent before the deadline!

I'm updating the code right now to include everything up to and including 255365. Nothing we can do about it now but I think the spec should be more pro-active to prevent problems like this in the future.

The only caveat is that you'll have to release the source code at the end of the contest, which I assume won't be a problem

I always planned to release the underlying libraries but originally did not plan to release the source code to the website since it's just one implementation of the library itself.

  • Specified that advanced features (beyond simple send) need to wait for a better way to store our data in the block chain

This a thousand times. It's very easy to extend the functionality once there is a proper way to store data in the chain. I will focus on this next if nobody comes forward with a way to do this in the next few days.

Spec Updated to 1.1
I did not re-read it yet so forgive me if you already did this. Did you describe which timestamps to use for transactions and how to deal multiple transactions from the same user in the same block (especially if not all transactions can be satisfied)? (See discussion on the previous page)

Tachikoma has done some great work on it so far, on his own volition. Its looks awesome and it's appreciated by everyone who invested. However, the project is barely out of the conceptual stage. Do you really want to start playing loose and fast with the investment funds? Wouldn't it be better to have a structured Bounty/Reward system laid out and discuss this kind of thing with the board before throwing out random offers?

I tend to agree. This project is barely started up and there is so much work to be done still. Although I really appreciate the gesture I think a formal bounty system would benefit Mastercoin better. I will see what I can do to just claim some bounties Smiley

Although I have no problems releasing my code but I really want to motivate others to build the same stuff I did. In order for Mastercoin to work a dialog needs to happen between developers. A lot of things in Mastercoin are open for interpretation and having multiple coders working on it in their own code might bring the problems to the surface. The other problem with releasing it now is that a lot of stuff that's written at the moment won't work when we implement a new method to encode the data and it won't work with anything other then simple send. I rather release it once these problems have been solved so it's at least future complete.

Lastly; thanks everybody for the compliments; I am happy that my work these past days is appreciated Smiley


Awesome.

We need some closure on the refunds issue, so let's draw the line at block 255365. Do NOT ask me to massage the spec to include your attempted purchase which was not included after block 255365! Everything after that block (not including MasterCoin transaction outputs) will be refunded. If somebody sends MORE money to the Exodus Address after I process the refund, they risk never seeing that money again.

Tachikoma, I'm sorry - I just have a very strong impulse to send you money after all the work you've done. I'll try to restrain myself. My board is already doing their job - when I mentioned this to them, they also advised me to not be too fast and loose with the money Smiley

It's up to you whether you release the source code for the library only or for the whole web page. The rules for the contest will only allow consideration of projects which have source code released at the end of the contest, so only your library would be considered in the contest if you didn't release the code to the web page. Either way is fine by me.

Regarding the timestamp question, I did not clarify it further (although I did address several other things which have come up). Let's take MasterCoin transactions in the order they are included in the block by the miner. I'll try to address that in the next rev of the spec.

Do we have another timestamp we could use besides the timestamp on the block itself? I was assuming the block timestamp was our only option . . . 


Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
September 09, 2013, 08:47:47 PM
 #847

Do we have another timestamp we could use besides the timestamp on the block itself? I was assuming the block timestamp was our only option . . .  

Hah no I think that's the only one; just think it needs to be added to the spec ^^

All the transactions up to 255365 should be added. But it's late so I did not check them all.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
maxmint
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500



View Profile
September 09, 2013, 09:33:03 PM
 #848


Tachikoma, I'm sorry - I just have a very strong impulse to send you money after all the work you've done. I'll try to restrain myself. My board is already doing their job - when I mentioned this to them, they also advised me to not be too fast and loose with the money Smiley


Let's not forget that there's a bitcoin address posted in the footer of mastercoin-explorer.com (1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B).
I just sent a small tip because I think this site just totally rocks!

My PGP-Key: 462D02D8
Verify my messages using keybase: https://keybase.io/maxmint
W2014
Member
**
Offline Offline

Activity: 205
Merit: 10



View Profile
September 10, 2013, 04:20:18 AM
Last edit: September 10, 2013, 05:59:18 AM by W2014
 #849

I've just put a new version of the http://mastercoin-explorer.com online.

This version actually has some useful information. For one it can approximate balances for a given address and show what kind of transactions where done by them. As always this is an initial version of this functionality so don't expect any miracles Smiley

J.R.: I spend way more time on this then I originally planned. So to be honest I hope there will still be a bounty for something like this even if I build it already; not that that was the reason for me doing it to begin with Smiley

Fantastic job, Tachikoma! Thanks for your efforts!

Question: if you click on "New Transaction" the MasterCoin Advisor appears. How does this work?

VIAZ   ►   First Major Decentralized Peer-to-Peer Funding Platform on Tezos   ◄
WEBSITE | BOUNTY CAMPAIGN | WHITEPAPER | FACEBOOK | TWITTER | TELEGRAM
maraoz
Newbie
*
Offline Offline

Activity: 55
Merit: 0



View Profile
September 10, 2013, 05:14:39 AM
 #850

Hey people. It's late over here (2am) so I'll post a quick update and tomorrow I'll expand. I'm working on a python mastercoin client (works connecting to a running bitcoin client). I made it open-source from the start so that dacoinminster and Tachikoma (and anyone) can peer-review it.

https://github.com/maraoz/pymastercoin

Right now it works like the Mastercoin Advisor script, only that it can also automatically create and broadcast the actual transactions. (no need to create them manually). Anyway, my plan was to build this as a base to test new methods for storing the data payload.

cheers! I'll send some technical questions tomorrow before I continue! (Maybe it's time to create a development thread?)
Manuel
ripper234
Legendary
*
Offline Offline

Activity: 1274
Merit: 1000


Ron Gross


View Profile WWW
September 10, 2013, 05:53:55 AM
 #851

I would like to remind everyone that we have a github account - https://github.com/mastercoin-MSC

I would like to request that at some point (either from the start, or when they feel they're ready), they transfer their projects to this repository. It will make it easier to find all Mastercoin related open source code. (They will retain full history and push rights to the repository, of course).

Please contact me if you're interested in such a migration.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
September 10, 2013, 09:09:54 AM
 #852

Thanks for the donations guys! Smiley

Fantastic job, Tachikoma! Thanks for your efforts!

Question: if you click on "New Transaction" the MasterCoin Advisor appears. How does this work?

It tells you what Bitcoin transactions to send in order to do a Mastercoin transaction. You can see J.R's examples earlier in the thread. For now however I would want to ask you to wait until we have a better way to encode the data in the blockchain.

Hey people. It's late over here (2am) so I'll post a quick update and tomorrow I'll expand. I'm working on a python mastercoin client (works connecting to a running bitcoin client). I made it open-source from the start so that dacoinminster and Tachikoma (and anyone) can peer-review it.

https://github.com/maraoz/pymastercoin

Right now it works like the Mastercoin Advisor script, only that it can also automatically create and broadcast the actual transactions. (no need to create them manually). Anyway, my plan was to build this as a base to test new methods for storing the data payload.

cheers! I'll send some technical questions tomorrow before I continue! (Maybe it's time to create a development thread?)
Manuel

Awesome; I will go over it tonight. If you want to bounce ideas around for encoding data in the chain you can always hit me up with a pm or find me on irc Smiley

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
maxmint
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500



View Profile
September 10, 2013, 09:36:40 AM
 #853

Tachikoma, the latest Mastercoin transactions are not showing up yet on mastercoin-explorer.com. Are they showing up delayed or is there something wrong?

My PGP-Key: 462D02D8
Verify my messages using keybase: https://keybase.io/maxmint
Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
September 10, 2013, 09:47:34 AM
 #854

Tachikoma, the latest Mastercoin transactions are not showing up yet on mastercoin-explorer.com. Are they showing up delayed or is there something wrong?

Right now new transactions are added based on a cron job which I suspect might not be running well. I ran it manually now and will check why the cron job isn't working on it's own.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
maxmint
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500



View Profile
September 10, 2013, 09:49:12 AM
 #855

Tachikoma, the latest Mastercoin transactions are not showing up yet on mastercoin-explorer.com. Are they showing up delayed or is there something wrong?

Right now new transactions are added based on a cron job which I suspect might not be running well. I ran it manually now and will check why the cron job isn't working on it's own.

Alright, thanks. Recent transactions are showing up now.

My PGP-Key: 462D02D8
Verify my messages using keybase: https://keybase.io/maxmint
cunicula
Legendary
*
Offline Offline

Activity: 1036
Merit: 1003


ARAX-Universal Crypto Wallet


View Profile WWW
September 10, 2013, 09:53:04 AM
 #856

You might have experience as a programmer but I take it you're not a systems guy.  Find someone who is and have them draft the spec.  You might not be familiar with hedging algorithms but you've got one implemented for the currency stabilization process.  Either find one and have them write a paper for you or dig up what the finance guys have in their literature and refer to it.  You don't have a bibliography and that's a bad thing, there is a whole lot here that is not novel and needs to be referenced so everyone knows you're not butting heads with what's generally held to be true.  tl;dr shoddy work designed by the clueless and implemented by the fools that follow them, stay away
There is more to this than hedging. You can reduce the risk of escrow fund exhaustion to zero and still fail to create a mastercoinUSD that is actually worth one USD.

Perfectly stable mastercoinUSD will sell for more than one USD. After all they teleport, real USD bills don't.
If I made USD bills that could teleport, would you pay face value for it? or would you be willing to pay a premium?
What if the network expanded so that you could use my teleporting USD in more places, wouldn't the premium increase?

At the same time unstable mastercoinUSD can sell for less than one USD. After all, they are exchangeable for at most one USD in mastercoin.
If the escrow fund runs dry, they are exchangeable for less than one USD in mastercoin. So their market price will decrease as the amount of backing falls.

The whole point is to achieve parity with the USD.


 



Own, Track
───────────  and 

Pay

with

ARAX
Your Universal
.Crypto Wallet.
█▄                                      ▄█
▀███▄                                ▄███▀
▄ ▀████▄                          ▄████▀ ▄
▀██▄██████▄         ██         ▄██████▄██▀
  ▀██████████▄     ████     ▄██████████▀
 █▄▄▄▀█████████   ██████  ▄█████████▀▄▄▄█
  ▀███████████▀▀ ███  ███  ▀███████████▀
    ███████████▄███    ███▄███████████
      ▀███████████      ███████████▀
         ▀███████        ███████▀
             ███          ███
            ███            ███
           ███              ███
          ███                ███
         ███                  ███
  | 


▀█▄▄          
██▄▀███▄▄      
████▄▀████▀▄▄  
██████▄▀█▀█████
█████▀▄███▄▀▀  
███▀▄██▀▀      
█▀▄█▀▀         

GET IN ON

.Google Play.
  |TELEGRAM      TWITTER
        ANN THREAD
FACEBOOK   MEDIUM
maraoz
Newbie
*
Offline Offline

Activity: 55
Merit: 0



View Profile
September 10, 2013, 01:48:57 PM
 #857

OK, time for technical questions.

  • What is the endianness for the data? self-answered, found on specification: big-endian. Good, I agree.
  • Why does Mastercoin Advisor use a data sequence number lower than the recipient sequence number? Shouldn't it be the successor of the recipient sequence number, as the protocol specifies?
Code:
recipientSequenceNum = ord(recipientBytes[1])
dataSequenceNum = recipientSequenceNum - 1
if dataSequenceNum < 0:
dataSequenceNum = dataSequenceNum + 256

Quote
In order to distinguish data packets from the reference address, the data packet sequence numbers start
at n+1 where n is the sequence number of the reference packet if it were treated as a data packet. Any
additional data packets can continue to use up sequence numbers n+2, n+3, and so on until all sequence
numbers are used except for n-1.
As an example of how this works, let's imagine a MasterCoin transaction that has two data packets. If
the reference address happens to have a sequence number of 62, then the first data packet has a
sequence number of 63 and the second has a sequence number of 64. Note that sequence number 255
is followed by 0.


My implementation: https://github.com/maraoz/pymastercoin/blob/master/message.py#L24 (line 24)
We should define the desired behaviour because if not we won't have compatible parsers/transaction generators.


  • What happens if the Mastercoin data payload is less than 20 bytes? or not a multiple of 20 bytes? I see from Mastercoin Advisor that zeroes are padded. Shouldn't we add that to the specification?
  • Bitcoin testnet Exodus address proposal. Should we define a Testnet exodus address to be able to test stuff in the testnet? I suggest dacoinminster to setup an address and to set the Testnet epoch to 1-Oct-2013, so we have time to buy this testnet mastercoins for the coding contest. This way we don't need to spend real bitcoins to test new protocol features or services.


Two final points: I'm willing to help polish the specification to have something clear for any developer to implement a client or blockchain parser. And later today I'm starting with alternate (not-yet-specified by the Mastercoin protocol) ways of storing  the data in the blockchain. I hope this helps with the blockchain bloating problem.
Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
September 10, 2013, 01:54:43 PM
 #858

  • Bitcoin testnet Exodus address proposal. Should we define a Testnet exodus address to be able to test stuff in the testnet? I suggest dacoinminster to setup an address and to set the Testnet epoch to 1-Oct-2013, so we have time to buy this testnet mastercoins for the coding contest. This way we don't need to spend real bitcoins to test new protocol features or services.

I proposed the same mechanism but nothing came off it. So I did the same thing you did and just took a random address and promoted it to tesnet-exodus. In theory there is no reason to have an end date for the testnet address it could be a few years in the future which will make it easier for other developers to buy coins as they come on board.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
maraoz
Newbie
*
Offline Offline

Activity: 55
Merit: 0



View Profile
September 10, 2013, 01:59:24 PM
 #859

  • Bitcoin testnet Exodus address proposal. Should we define a Testnet exodus address to be able to test stuff in the testnet? I suggest dacoinminster to setup an address and to set the Testnet epoch to 1-Oct-2013, so we have time to buy this testnet mastercoins for the coding contest. This way we don't need to spend real bitcoins to test new protocol features or services.

I proposed the same mechanism but nothing came off it. So I did the same thing you did and just took a random address and promoted it to tesnet-exodus. In theory there is no reason to have an end date for the testnet address it could be a few years in the future which will make it easier for other developers to buy coins as they come on board.

+1! Yeah, no reason to set the epoch so close to the present. I retract that. Let's have it a year from now or something.
By the way. which IRC server are you in? I'm in #mastercoin, in freenode. Would be nice to have someone to chat when I'm developing mastercoin-related stuff.
dacoinminster
Legendary
*
Offline Offline

Activity: 1260
Merit: 1022


Rational Exuberance


View Profile WWW
September 10, 2013, 02:58:44 PM
 #860

OK, time for technical questions.

  • What is the endianness for the data? self-answered, found on specification: big-endian. Good, I agree.
  • Why does Mastercoin Advisor use a data sequence number lower than the recipient sequence number? Shouldn't it be the successor of the recipient sequence number, as the protocol specifies?
Code:
recipientSequenceNum = ord(recipientBytes[1])
dataSequenceNum = recipientSequenceNum - 1
if dataSequenceNum < 0:
dataSequenceNum = dataSequenceNum + 256

Quote
In order to distinguish data packets from the reference address, the data packet sequence numbers start
at n+1 where n is the sequence number of the reference packet if it were treated as a data packet. Any
additional data packets can continue to use up sequence numbers n+2, n+3, and so on until all sequence
numbers are used except for n-1.
As an example of how this works, let's imagine a MasterCoin transaction that has two data packets. If
the reference address happens to have a sequence number of 62, then the first data packet has a
sequence number of 63 and the second has a sequence number of 64. Note that sequence number 255
is followed by 0.


My implementation: https://github.com/maraoz/pymastercoin/blob/master/message.py#L24 (line 24)
We should define the desired behaviour because if not we won't have compatible parsers/transaction generators.


  • What happens if the Mastercoin data payload is less than 20 bytes? or not a multiple of 20 bytes? I see from Mastercoin Advisor that zeroes are padded. Shouldn't we add that to the specification?
  • Bitcoin testnet Exodus address proposal. Should we define a Testnet exodus address to be able to test stuff in the testnet? I suggest dacoinminster to setup an address and to set the Testnet epoch to 1-Oct-2013, so we have time to buy this testnet mastercoins for the coding contest. This way we don't need to spend real bitcoins to test new protocol features or services.


Two final points: I'm willing to help polish the specification to have something clear for any developer to implement a client or blockchain parser. And later today I'm starting with alternate (not-yet-specified by the Mastercoin protocol) ways of storing  the data in the blockchain. I hope this helps with the blockchain bloating problem.

Aw crap. I meant to update the spec to change how the sequence numbers worked. Thanks for catching that.

When I was writing the code for MasterCoin Adviser, it occurred to me that it might be easier to parse MasterCoin transactions if the first data packet had the first sequence number, then additional data packets following, and then the reference packet last, with the last sequence number. But I never went back and updated the spec to reflect that change. I made that change because I thought it might help if we ever had transactions with data but no reference address.

I had intended Test MasterCoins to be used so I didn't have to create a TestNet version at all, but I have no opposition to TestNet implementations if that is helpful, especially if that helps reduce block-chain bloat Smiley

As you noticed, MasterCoinAdvisor adds zero padding to fill up the unused remainder of any data packet, although you could probably put anything you want there since clients won't look at those bytes. Still, probably best to keep it clean and stick to zeroes unless we think of a reason not to.

edit:
I sent a PM to you about working on the spec, but then I realized other people might want to work on it too, so I've quoted the PM below:

I saw that you'd be interested in helping polish the spec. Ron suggested that we convert it to markdown so that it is more diff-friendly and git-friendly. He would be most pleased if we could get that checked in to our github repo: https://github.com/mastercoin-MSC

If you'd like to work on that, I uploaded the *.doc version here: https://sites.google.com/site/2ndbtcwpaper/MasterCoin%20Specification%201.1.doc?attredirects=0&d=1

Thanks for working on the project! If it weren't for my day-job, I'd have the programming contest launched by now. Sorry . . .

-J.R.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 ... 166 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!