dacoinminster



Offline



Activity: 1260

Merit: 1024





Rational Exuberance







LegendaryActivity: 1260Merit: 1024Rational Exuberance Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 16, 2013, 07:49:02 PM

Last edit: September 16, 2013, 08:53:08 PM by dacoinminster #941



Quote from: dacoinminster on September 16, 2013, 07:47:49 PM Quote from: Mike Hearn on September 16, 2013, 07:44:00 PM You should just fix the issues with making provably unspendable OP_RETURN outputs. There's already an open pull request for it. I'm not a fan of any "solution" that involves putting things which are not keys into OP_CHECKMULTISIG scripts. They're intended for keys, not other data.



But I'm really unclear why you need to build things into Bitcoin anyway. If you or the people you're working with aren't able to make a merge mined coin with your current abilities, then maybe it's time to learn how? I explained years ago how alternative chains can interact with the Bitcoin chain (e.g. have the contents of your new database depend on the contents of the bitcoin database).



Thanks for your reply!



Making another alt-coin isn't really interesting to me, merged-mined or not. Frankly, I wouldn't have raised much money at all if I were trying to make another alt coin. I'm very committed to making a new protocol layer on top of bitcoin, but I want to do it in the most friendly way possible

Thanks for your reply!Making another alt-coin isn't really interesting to me, merged-mined or not. Frankly, I wouldn't have raised much money at all if I were trying to make another alt coin. I'm very committed to making a new protocol layer on top of bitcoin, but I want to do it in the most friendly way possible

edit:



Mike followed up with an appeal to stop what I'm doing entirely and reboot the project as an alt-chain! I of course refused, as charitably as I could:



Quote from: dacoinminster on September 16, 2013, 08:34:12 PM Quote from: Mike Hearn on September 16, 2013, 07:57:40 PM Yes, I'm familiar with your reasons for not wanting to make an alt coin.



The fact that you raised money isn't relevant to anything. A block chain is merely a technical method to synchronise a database. It has no importance beyond that. To say a new block chain "competes" with Bitcoin is meaningless because there's no requirement that the block chain be used to create another currency. It could do anything that requires a key/value store. It could, for instance, track annotations to regular Bitcoin transactions but which are nonetheless not stored in the Bitcoin chain.



In short, your ideas for MasterCoin will succeed or fail independently of whether you use the Bitcoin block chain or create a new one. I suspect the real reason you want to use normal Bitcoin transactions is you don't have the technical skill required to implement your ideas in a separate system. This will not gain much sympathy from other people.



You're also going to cause big problems for other people who are building apps using the protocol as it was meant to be designed (like me) - now features we're using to make things will be seen as a vector for abuse (your abuse) and people will argue to remove those features rather than risk the viability of the core system. I've had to spend a lot of time arguing against people disabling useful features because of abuse by technically inadequate programmers, and I'm tired of it.



In short - stop now, step back, and evaluate alternative technical approaches. If necessary temporarily return money that was given to you and promise to come back with a MasterCoin v2 that resolves the valid technical concerns people have. If you don't then people with far more experience than you will start looking for ways to shut MasterCoin out of the network, and that would be a huge timesink and potentially quite damaging to both Bitcoin and MasterCoin itself. Nobody wants to go there.



Thanks Mike. I definitely understand your concerns, and I partially agree with your reasoning (partially, because I don't expect I would have any trouble making an alt chain, if my interests were in that direction). I can understand your frustration with wanting to have more features in bitcoin, balanced against the fear that people will abuse them.



I appreciate that it would be better for you (and perhaps lots of other people) if I stopped what I am doing and approached the matter from a different angle. However, I think it's much more constructive to recognize that people are going to try to do things like this, and try to minimize the impact on the block chain. Even if I did exactly as you suggest, someone else would try it, possibly even someone more foolish than myself, if you can imagine that



I understand that my approach may result in changes to bitcoin which might not be favorable to my project, but I spent quite a bit of time contemplating how to make sure my transactions didn't get banned from bitcoin, and I don't plan on relying on any mechanism that would allow that. Frankly, I simply can't conceive of anything that would shut MasterCoin out of the block chain permanently. Perhaps I just lack imagination.



You can predict my future actions with perfect accuracy if you simply assume that "J.R. will do what he thinks is best for the owners of MasterCoins", which of course includes myself. If I thought that a complete reboot of my project was in the best interests of my investors, I would do it in a heartbeat. Any argument attempting to get me to change direction must appeal to that motivation, not my compassion for whatever projects of yours that my project may be hindering, or my concern for the bitcoin economy in general, or . . . anything else at all. If it's not in the best interest of my investors, I won't do it. Period.



I really do appreciate your feedback though, and I highly respect your views on this matter. One thing that is in the interest of my investors is to make our project as bitcoin-friendly as possible, since if we don't, someone else will gain a competitive advantage over us by being better block-chain citizens.



Perhaps the end result will be that someone will create an alt-coin using merged mining which is more in line with what you would like to see, and that coin will win out by its inherent superiority. Perhaps you yourself might create it? If so, I sincerely wish you luck - I might even buy some!



-J.R.

Thanks Mike. I definitely understand your concerns, and I partially agree with your reasoning (partially, because I don't expect I would have any trouble making an alt chain, if my interests were in that direction). I can understand your frustration with wanting to have more features in bitcoin, balanced against the fear that people will abuse them.I appreciate that it would be better for you (and perhaps lots of other people) if I stopped what I am doing and approached the matter from a different angle. However, I think it's much more constructive to recognize that people are going to try to do things like this, and try to minimize the impact on the block chain. Even if I did exactly as you suggest, someone else would try it, possibly even someone more foolish than myself, if you can imagine thatI understand that my approach may result in changes to bitcoin which might not be favorable to my project, but I spent quite a bit of time contemplating how to make sure my transactions didn't get banned from bitcoin, and I don't plan on relying on any mechanism that would allow that. Frankly, I simply can't conceive of anything that would shut MasterCoin out of the block chain permanently. Perhaps I just lack imagination.You can predict my future actions with perfect accuracy if you simply assume that "J.R. will do what he thinks is best for the owners of MasterCoins", which of course includes myself. If I thought that a complete reboot of my project was in the best interests of my investors, I would do it in a heartbeat. Any argument attempting to get me to change direction must appeal to that motivation, not my compassion for whatever projects of yours that my project may be hindering, or my concern for the bitcoin economy in general, or . . . anything else at all. If it's not in the best interest of my investors, I won't do it. Period.I really do appreciate your feedback though, and I highly respect your views on this matter. One thing that is in the interest of my investors is to make our project as bitcoin-friendly as possible, since if we don't, someone else will gain a competitive advantage over us by being better block-chain citizens.Perhaps the end result will be that someone will create an alt-coin using merged mining which is more in line with what you would like to see, and that coin will win out by its inherent superiority. Perhaps you yourself might create it? If so, I sincerely wish you luck - I might even buy some!-J.R.

Another reply. Looks like he'll be mostly satisfied if we just use OP_RETURN.



Quote from: dacoinminster on September 16, 2013, 08:51:09 PM Quote from: Mike Hearn on September 16, 2013, 08:42:07 PM Well, you're assigning new semantics to existing transactions. So nothing stops you from hard-forking your own system onto a separate chain. You just say "at block height X on the bitcoin chain, the mastercoin genesis block will be initialized to the contents of the system at that height and all new mastercoin transactions take place on the new chain". It's not impossible or anything to split it off, as you already define the rules and indeed the system doesn't have much code yet.



At the moment it seems that MasterCoin transactions all pay money to the exodus address (i.e. you), so that seems like a fairly major giveaway. For your system to work, there has to be a way to identify the special transactions, and if your software can do it so can any other program. Perhaps I missed something but that seems fairly fundamental.



People are much more relaxed about provably unspendable outputs. Using the OP_RETURN form is a quick fix that doesn't require much effort on your part, but it does mean finishing off the work Jeff did on the bitcoind patch and getting it merged in, then starting to use it once people upgrade. Your software can recognise both forms so the transition is smooth.



Your current approach strikes me as similar to a company executive whose factory is dumping waste into a river. People in the community ask you to stop, and even suggest ideas for how to avoid doing it, but you simply answer that you only care about your shareholders and anyway, anyone can dump toxic waste in the river so it shouldn't matter that you're doing it. That may be so, but that attitude will alienate the people around you. Eventually it will cause problems.



The tiny outputs which reference the exodus address are not intended as a way to raise money, but merely as a convenience for finding our data in the block chain. We could switch to a different reference address at any time if for some reason bitcoin clients started looking for that address.



I think that's exactly the direction we are heading (using OP_RETURN once it becomes possible to do so). I DO want to minimize the toxic waste being dumped in the river, and thankfully I believe it is in the best interests of my investors to do so



I personally think that the river-polluting example is a pretty strong argument against an-cap world-views, but that is a different conversation . . .

The tiny outputs which reference the exodus address are not intended as a way to raise money, but merely as a convenience for finding our data in the block chain. We could switch to a different reference address at any time if for some reason bitcoin clients started looking for that address.I think that's exactly the direction we are heading (using OP_RETURN once it becomes possible to do so). I DO want to minimize the toxic waste being dumped in the river, and thankfully I believe it is in the best interests of my investors to do soI personally think that the river-polluting example is a pretty strong argument against an-cap world-views, but that is a different conversation . . . Mike Hearn also votes for OP_RETURN. His message and my reply:Mike followed up with an appeal to stop what I'm doing entirely and reboot the project as an alt-chain! I of course refused, as charitably as I could:Another reply. Looks like he'll be mostly satisfied if we just use OP_RETURN.

Check out my attempt at

I have seen I wrote The Second Bitcoin Whitepaper Check out my attempt at using memes to explain bitcoin I have seen bitcoin's dystopian future

killerstorm



Offline



Activity: 1022

Merit: 1000









LegendaryActivity: 1022Merit: 1000 Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 16, 2013, 09:50:44 PM #943 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.



So my advice would be:



1. switch to CHECKMULTISIG ASAP

2. make it possible to use OP_RETURN approach



That is, you can write code to parse both CHECKMULTISIG and OP_RETURN, and test in on the testnet.



Code which creates transactions will use only CHECKMULTISIG now.



If at some point OP_RETURN will be viable, a new version of client can start using it: and old versions will be able to recognize such transactions too.



Now as CHECKMULTISIG adds more bloat to UTXO space, developers have an incentive to approve OP_RETURN.



I think everybody can agree that CHECKMULTISIG is definitely better than what you're doing now, so there are no reasons not to upgrade. (I mean, aside from desire to piggyback on existing clients.) Use of OP_RETURN is a separate issue.



Passive-aggressive strategy like you mentioned can work too, but it will create some junk in process, and, sadly, that junk will stay in UTXO set forever, which is kinda sad. Chromia : a better dapp platform

zathras



Offline



Activity: 266

Merit: 250









Sr. MemberActivity: 266Merit: 250 Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 16, 2013, 11:01:28 PM #945



I'm currently attempting a build of a web wallet and block explorer - 'Masterchest'. Some notes:



* Ground-up build (though bitcoind still used to return raw tx info over JSON-RPC)

* Hosted at masterchest.info

* Everything will be open sourced - I think this is in the best interests of a web wallet so the community can peer review for weaknesses etc

* The web wallet has simplicity in mind and will only manage MSC, not MSC & BTC. This lowers risk and complexity. You'll instead be able to simply buy 'transactions' (eg 20 for 0.01BTC - whatever it works out to be - I'll fund first 5 transactions myself for all users). This allows the system to simply hold a count of each users available transactions rather than attempt to handle bitcoin funds too.

* Tools to lookup addresses and transactions (block explorer)

* Initial support will be simple send only

* There will definitely be restrictions on how many MSC you can store (probably <100MSC per account), especially during development



I have a family and a full-time job so time is already a luxury for me! but I bought some Mastercoins and I'd like to contribute to the project - doing my best to find time to work on this! If by some miracle I complete all the functions I'll happily jump in to try and get my head around the storage issue to contribute, though I think brighter minds than mine are already hard at work on this.



At present I'm in the middle of finishing the parsing engine (decoding the raw transactions where Exodus is an output and warehousing them in a format that facilitates easy data retrieval) - I have a semi-working implementation but I'm not willing to open it up just yet. I'll post updates here as I (hopefully) progress.



Edit: Pictures help so quick teaser screenshot

I thought I should make a post and detail what I'm working onI'm currently attempting a build of a web wallet and block explorer - 'Masterchest'. Some notes:* Ground-up build (though bitcoind still used to return raw tx info over JSON-RPC)* Hosted at masterchest.info* Everything will be open sourced - I think this is in the best interests of a web wallet so the community can peer review for weaknesses etc* The web wallet has simplicity in mind and will only manage MSC, not MSC & BTC. This lowers risk and complexity. You'll instead be able to simply buy 'transactions' (eg 20 for 0.01BTC - whatever it works out to be - I'll fund first 5 transactions myself for all users). This allows the system to simply hold a count of each users available transactions rather than attempt to handle bitcoin funds too.* Tools to lookup addresses and transactions (block explorer)* Initial support will be simple send only* There will definitely be restrictions on how many MSC you can store (probably <100MSC per account), especially during developmentI have a family and a full-time job so time is already a luxury for me! but I bought some Mastercoins and I'd like to contribute to the project - doing my best to find time to work on this! If by some miracle I complete all the functions I'll happily jump in to try and get my head around the storage issue to contribute, though I think brighter minds than mine are already hard at work on this.At present I'm in the middle of finishing the parsing engine (decoding the raw transactions where Exodus is an output and warehousing them in a format that facilitates easy data retrieval) - I have a semi-working implementation but I'm not willing to open it up just yet. I'll post updates here as I (hopefully) progress.Edit: Pictures help so quick teaser screenshot Smart Property & Distributed Exchange: Master Protocol for Bitcoin

maraoz



Offline



Activity: 56

Merit: 0









NewbieActivity: 56Merit: 0 Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 16, 2013, 11:15:12 PM #946 Quote from: Tachikoma on September 16, 2013, 08:54:39 AM



1-out-of-3

1-out-of-2

While technically I can think of no reason to not support any 1-out-of-n transactions, the reference client won't relay or mine these for now. It also seems then if you use uncompressed public keys they are not valid ECDSA points which means that we are stuck with compress public keys for now until somebody finds a way to use uncompressed ones.



What this means is that we can use a maximum of 128 bytes per multisig-output (two compressed public keys of 64 bytes each). Since the first public key will always be one of our own public keys so we can redeem the output.



Grazcoin suggested we could use the public key to encode the Bitcoin address of the receiver. However I think this might be more trouble then it's worth. If you convert a Bitcoin address to a hex string you would end up with a 68 byte string. Which is just over the length of one public key. It would make parsing the much harder since you are guaranteed to need two ouputs for every transaction.



I would like to suggest that we keep the original spec and use one output for the receiving address.



We also need to rethink the sequence number. Since we always know what the target address is we no longer have to use a sequence number based on the receiving address and since public keys are kept in order in a multisig output (although I would appreciate if somebody could confirm this) we don't need sequences on a per public key basis, we need them per output.



We can just use a integer that counts up from zero, per multisig output, making sequencing much easier in the new situation.



A simple encoded simple send would look like (and forgive my horrible photoshop skills):



https://dl.dropboxusercontent.com/u/374/SimpleSend.png



A complete tx could look something like this:



Code: {"hash":"c4551b2e0b8470cc3e03212f823cb9a66580c512aa66ac71a4bfc0a6500dd1eb","ver":1,"vin_sz":1,"vout_sz":2,"lock_time":0,"size":305,

"in":[{"prev_out":{"hash":"c9fc3f6f8dc828d11eab3196393f13e8c147f835d2d0568df26009aba9617a6e","n":0},"scriptSig":"3046022100cb314569b0b194c2e510a101c5a6d9ec5a95a9a8cfc4009bd8f11affbec1b835022100b6e8b08be3b42e037a18f497a595996c40c49e83b114dc360601fdb3526e4d8001 04ea5fbd95738d81e3857067e8156b0887aad60ba2018c21807705c0e5cd4ee9f5187d56e6a827b5c7f54721c46c9c372bdc929a16f3331c3290fdbebc55a7572e"}],

"out":[

{"value":"0.00006000","scriptPubKey":"OP_DUP OP_HASH160 e8c6391242865cb288487d938f87d40706381c12 OP_EQUALVERIFY OP_CHECKSIG"},

{"value":"0.00006000","scriptPubKey":"OP_DUP OP_HASH160 exodusaddressshouldbeinsertedhere OP_EQUALVERIFY OP_CHECKSIG"},

{"value":"0.00006000","scriptPubKey":"1 02c5ac10feed00d99b6571bb42567d43e255b8ace9adf078908e3c4827f954d918 020000000001000000020000000000000001000000000000000000000000000000 2 OP_CHECKMULTISIG"}]}



I appreciate some feedback on this spec before I start writing code

There are two types of multisig outputs available at the moment that are useful for us.While technically I can think of no reason to not support any 1-out-of-n transactions, the reference client won't relay or mine these for now. It also seems then if you use uncompressed public keys they are not valid ECDSA points which means that we are stuck with compress public keys for now until somebody finds a way to use uncompressed ones.Grazcoin suggested we could use the public key to encode the Bitcoin address of the receiver. However I think this might be more trouble then it's worth. If you convert a Bitcoin address to a hex string you would end up with a 68 byte string. Which is just over the length of one public key. It would make parsing the much harder since you are guaranteed to need two ouputs for every transaction.We also need to rethink the sequence number. Since we always know what the target address is we no longer have to use a sequence number based on the receiving address and since public keys are kept in order in a multisig output (although I would appreciate if somebody could confirm this) we don't need sequences on a per public key basis, we need them per output.A simple encoded simple send would look like (and forgive my horrible photoshop skills):A complete tx could look something like this:I appreciate some feedback on this spec before I start writing code

Wow, it's becoming harder and harder to stay up to date with Mastercoin.

First off, Tachikoma thank you for all your work. You've contributed far more than anyone else to Mastercoin. I'm sad to hear you are demotivated by the way some community members react.





Back to the new data method proposal: I can't see any error in the details of what you said. That transaction does contain the data, and the bitcoins are redeemable via the actual public key. Nevertheless, the mysterious PM dacoinminister cited got me thinking more broadly about the method. I think there might be a more general problem in the concept of storing data in the blockchain using multisig txs. For mastercoin to work we need mastercoin transactions to be stored in a decentralized, permanent way (like bitcoin transactions are). Using multisig transactions and then taking the bitcoin away with the other key may cause the transaction to be pruned from the blockchain by future bitcoin clients (why would you need to store transactions which have all its outputs spent?). In fact, the same should happen with ANY method which doesn't bloat the UTXO. If a transaction can be pruned for whatever reason (multisig, op_return), it means bitcoin clients could potentially delete that transaction, thus deleting mastercoin data?



Clearly my technical knowledge of the bitcoin protocol is below most of the people reading/writing here, so I'm sorry if what I'm saying is stupid.



Wow, it's becoming harder and harder to stay up to date with Mastercoin.First off, Tachikoma thank you for all your work. You've contributed far more than anyone else to Mastercoin. I'm sad to hear you are demotivated by the way some community members react.Back to the new data method proposal: I can't see any error in the details of what you said. That transaction does contain the data, and the bitcoins are redeemable via the actual public key. Nevertheless, the mysterious PM dacoinminister cited got me thinking more broadly about the method. I think there might be a more general problem in the concept of storing data in the blockchain using multisig txs. For mastercoin to work we need mastercoin transactions to be stored in a decentralized, permanent way (like bitcoin transactions are). Using multisig transactions and then taking the bitcoin away with the other key may cause the transaction to be pruned from the blockchain by future bitcoin clients (why would you need to store transactions which have all its outputs spent?). In fact, the same should happen with ANY method which doesn't bloat the UTXO. If a transaction can be pruned for whatever reason (multisig, op_return), it means bitcoin clients could potentially delete that transaction, thus deleting mastercoin data?Clearly my technical knowledge of the bitcoin protocol is below most of the people reading/writing here, so I'm sorry if what I'm saying is stupid.

dacoinminster



Offline



Activity: 1260

Merit: 1024





Rational Exuberance







LegendaryActivity: 1260Merit: 1024Rational Exuberance Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 17, 2013, 12:02:56 AM #947 Quote from: maraoz on September 16, 2013, 11:15:12 PM Wow, it's becoming harder and harder to stay up to date with Mastercoin.

First off, Tachikoma thank you for all your work. You've contributed far more than anyone else to Mastercoin. I'm sad to hear you are demotivated by the way some community members react.





Back to the new data method proposal: I can't see any error in the details of what you said. That transaction does contain the data, and the bitcoins are redeemable via the actual public key. Nevertheless, the mysterious PM dacoinminister cited got me thinking more broadly about the method. I think there might be a more general problem in the concept of storing data in the blockchain using multisig txs. For mastercoin to work we need mastercoin transactions to be stored in a decentralized, permanent way (like bitcoin transactions are). Using multisig transactions and then taking the bitcoin away with the other key may cause the transaction to be pruned from the blockchain by future bitcoin clients (why would you need to store transactions which have all its outputs spent?). In fact, the same should happen with ANY method which doesn't bloat the UTXO. If a transaction can be pruned for whatever reason (multisig, op_return), it means bitcoin clients could potentially delete that transaction, thus deleting mastercoin data?



Clearly my technical knowledge of the bitcoin protocol is below most of the people reading/writing here, so I'm sorry if what I'm saying is stupid.



If my understanding is correct, bitcoin-only clients could ignore the transaction itself, but it would still be in the block chain for MasterCoin clients to use. Anybody storing the entire block-chain would have our transactions.



MasterCoin clients will want to do their own style of pruning - they don't need to look at or store any transaction which does not reference the Exodus Address. Currently that lets us ignore almost everything



For the record, I don't think this question is stupid at all. If my understanding is correct, bitcoin-only clients could ignore the transaction itself, but it would still be in the block chain for MasterCoin clients to use. Anybody storing the entire block-chain would have our transactions.MasterCoin clients will want to do their own style of pruning - they don't need to look at or store any transaction which does not reference the Exodus Address. Currently that lets us ignore almost everythingFor the record, I don't think this question is stupid at all.

Check out my attempt at

I have seen I wrote The Second Bitcoin Whitepaper Check out my attempt at using memes to explain bitcoin I have seen bitcoin's dystopian future

dacoinminster



Offline



Activity: 1260

Merit: 1024





Rational Exuberance







LegendaryActivity: 1260Merit: 1024Rational Exuberance Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 17, 2013, 12:07:44 AM #948 Quote from: zathras on September 16, 2013, 11:01:28 PM



I'm currently attempting a build of a web wallet and block explorer - 'Masterchest'. Some notes:



* Ground-up build (though bitcoind still used to return raw tx info over JSON-RPC)

* Hosted at masterchest.info

* Everything will be open sourced - I think this is in the best interests of a web wallet so the community can peer review for weaknesses etc

* The web wallet has simplicity in mind and will only manage MSC, not MSC & BTC. This lowers risk and complexity. You'll instead be able to simply buy 'transactions' (eg 20 for 0.01BTC - whatever it works out to be - I'll fund first 5 transactions myself for all users). This allows the system to simply hold a count of each users available transactions rather than attempt to handle bitcoin funds too.

* Tools to lookup addresses and transactions (block explorer)

* Initial support will be simple send only

* There will definitely be restrictions on how many MSC you can store (probably <100MSC per account), especially during development



I have a family and a full-time job so time is already a luxury for me! but I bought some Mastercoins and I'd like to contribute to the project - doing my best to find time to work on this! If by some miracle I complete all the functions I'll happily jump in to try and get my head around the storage issue to contribute, though I think brighter minds than mine are already hard at work on this.



At present I'm in the middle of finishing the parsing engine (decoding the raw transactions where Exodus is an output and warehousing them in a format that facilitates easy data retrieval) - I have a semi-working implementation but I'm not willing to open it up just yet. I'll post updates here as I (hopefully) progress.



Edit: Pictures help so quick teaser screenshot



I thought I should make a post and detail what I'm working onI'm currently attempting a build of a web wallet and block explorer - 'Masterchest'. Some notes:* Ground-up build (though bitcoind still used to return raw tx info over JSON-RPC)* Hosted at masterchest.info* Everything will be open sourced - I think this is in the best interests of a web wallet so the community can peer review for weaknesses etc* The web wallet has simplicity in mind and will only manage MSC, not MSC & BTC. This lowers risk and complexity. You'll instead be able to simply buy 'transactions' (eg 20 for 0.01BTC - whatever it works out to be - I'll fund first 5 transactions myself for all users). This allows the system to simply hold a count of each users available transactions rather than attempt to handle bitcoin funds too.* Tools to lookup addresses and transactions (block explorer)* Initial support will be simple send only* There will definitely be restrictions on how many MSC you can store (probably <100MSC per account), especially during developmentI have a family and a full-time job so time is already a luxury for me! but I bought some Mastercoins and I'd like to contribute to the project - doing my best to find time to work on this! If by some miracle I complete all the functions I'll happily jump in to try and get my head around the storage issue to contribute, though I think brighter minds than mine are already hard at work on this.At present I'm in the middle of finishing the parsing engine (decoding the raw transactions where Exodus is an output and warehousing them in a format that facilitates easy data retrieval) - I have a semi-working implementation but I'm not willing to open it up just yet. I'll post updates here as I (hopefully) progress.Edit: Pictures help so quick teaser screenshot

Awesome! We have a new entrant!



Well, maybe not so awesome for everybody else competing, but it's awesome for the MasterCoin project anyway



I am so sad that the contest isn't going to fairly compensate everyone for their work, but I'm really pumped that so many people are excited to contribute! Awesome! We have a new entrant!Well, maybe not so awesome for everybody else competing, but it's awesome for the MasterCoin project anywayI am so sad that the contest isn't going to fairly compensate everyone for their work, but I'm really pumped that so many people are excited to contribute!

Check out my attempt at

I have seen I wrote The Second Bitcoin Whitepaper Check out my attempt at using memes to explain bitcoin I have seen bitcoin's dystopian future

TomHirsch



Offline



Activity: 41

Merit: 0







NewbieActivity: 41Merit: 0 Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 17, 2013, 03:18:41 PM #952 Quote from: dacoinminster on September 17, 2013, 12:07:44 AM I am so sad that the contest isn't going to fairly compensate everyone for their work, but I'm really pumped that so many people are excited to contribute!

J.R. - I don't think you have a good read on these people. They are all going to be fairly compensated. Their compensation comes in producing fine results on a very interesting project. Probably very few people are in this for the money.



Don't spend another second being 'so sad that...' - your efforts to keep the project healthy and going down a good path are all they need as compensation to work hard. Your organization of the project assures their efforts are not wasted. It is a perfect synergy. Forget about $$$, BTC, or MSC. Building something cool is far more rewarding than having a pocket full of money.

However, hot chicks tend not to agree with that I suspect.

J.R. - I don't think you have a good read on these people. They are all going to be fairly compensated. Their compensation comes in producing fine results on a very interesting project. Probably very few people are in this for the money.Don't spend another second being 'so sad that...' - your efforts to keep the project healthy and going down a good path are all they need as compensation to work hard. Your organization of the project assures their efforts are not wasted. It is a perfect synergy. Forget about $$$, BTC, or MSC. Building something cool is far more rewarding than having a pocket full of money.However, hot chicks tend not to agree with that I suspect.

jgarzik



Offline



Activity: 1596

Merit: 1007







LegendaryActivity: 1596Merit: 1007 Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 17, 2013, 05:45:02 PM #955 Quote from: Tachikoma on September 17, 2013, 02:52:02 PM Quote from: killerstorm on September 16, 2013, 09: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.

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 Question 1:

Having a valid public key in a 1-3 multisig is not enough to redeem said output and thus prevent UTXO bloat?



Quote from: killerstorm on September 16, 2013, 09: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).

Having a valid public key in a 1-3 multisig is not enough to redeem said output and thus prevent UTXO bloat?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.



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 alwaysmultisig output sitting around, waiting to be spent.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_0016With P2SH, the MasterCoin data could be stored in thescriptSig, 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. Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.

Visit bloq.com / metronome.io

Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj

Tachikoma



Offline



Activity: 938

Merit: 1000









Hero MemberActivity: 938Merit: 1000 Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 17, 2013, 05:53:56 PM #956 Quote from: jgarzik on September 17, 2013, 05:45:02 PM Quote from: Tachikoma on September 17, 2013, 02:52:02 PM Quote from: killerstorm on September 16, 2013, 09: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.

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 Question 1:

Having a valid public key in a 1-3 multisig is not enough to redeem said output and thus prevent UTXO bloat?



Quote from: killerstorm on September 16, 2013, 09: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).

Having a valid public key in a 1-3 multisig is not enough to redeem said output and thus prevent UTXO bloat?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.





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 alwaysmultisig output sitting around, waiting to be spent.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_0016With P2SH, the MasterCoin data could be stored in thescriptSig, 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. 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. Electrum : the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported

zathras



Offline



Activity: 266

Merit: 250









Sr. MemberActivity: 266Merit: 250 Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 18, 2013, 06:25:39 AM

Last edit: September 18, 2013, 06:37:25 AM by zathras #958 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?









Smart Property & Distributed Exchange: Master Protocol for Bitcoin