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

Cool, congrats to the release!

I don't have access to windows. Is there a way to try this out anyway?

Masterchest Library

Initial alpha release of the Masterchest library.  

This library provides a number of Mastercoin related functions in a .NET DLL for easy referencing in a project.  This library is used by both my wallet and the masterchest engine (the blockchain scanner behind masterchest.info).

With thanks to:  BouncyCastle, Newtonsoft, Tachikoma

Requirements: .NET 4, bitcoind/qt RPC server with transaction indexing enabled (disabled by default in 0.8+, add txindex=1 in bitcoin.conf and then start with -reindex to readd transaction index).

Disclaimer:  Please use it as you see fit, but remember this is very, very alpha.  You should not risk anything other than a small amount of coins (bitcoin or mastercoin) when testing.  To put some context around the risks involved - consider that as we build and broadcast transactions from scratch, if we grab a 100BTC input and miscalculate the change, then a miner somewhere is going to be very happy and you are going to lose out.  I'm encouraging any and all testers to spin up a VM, create a new bitcoin wallet, depsoit a fraction of a bitcoin to cover fees and then use Masterchest software with this new bitcoin wallet.

I'm going to be quite brief for now as I have a lot to get through this evening, please feel free to ask any questions and I'll be happy to answer them A quick readme I threw together:

Firstly import Masterchest:

Create a new instance of the Masterchest lib:

Create a bitcoind/qt connection:

Retrieve a block hash:

Retrieve a block:

Retrieve the block currently being mined:

Create an array of transaction IDs in a block:

Loop through transactions in a block:

Retrieve a transaction:

Check if a transaction looks like it cointains a Mastercoin transaction:

Decode a Mastercoin transaction (original or multisig):

Encode a Mastercoin transaction (multisig only):
   
Compiled DLL & Source : https://github.com/zathras-crypto/masterchest-library

Feedback/questions always of course welcome

I think we have to start working on the smart property feature right now. Share issuers are running out of alternatives and are in need of a new and robust system.

Here's what I'd suggest:
- Start a new posting to collect ideas and get more people involved in smart property.
- Contact share issuers and ask them if they would be interested in this (one or two of the bigger ones could bring huge momentum). Then start working with them and build a system that fills their needs.

I know we should not jump the gun on this, but I really think that time is of essence here.

Thanks Tachikoma, I've spun up your wallet but again I'm really not having much joy with ruby - wallet bombs with an SSL error (note this is another fresh ruby install, this time trying on Windows):

FYI, I tried a 'gem install ssl' as a shot in the dark - it installed an SSL gem but same error.  I can't see an ssl.dll anywhere in the /ruby192 tree so again likely environment related.  Perhaps if I can find some time I'll try and figure out what's up here.  

I will say however that Mastercoin-explorer picks up my multisigs as valid which is good, seems we have compatible implementations


I didn't get very far using 0 and stopped testing fairly quickly, my implementation also starts multisig sequences with 1 these days.  


The most recent versions of my code also do away with requiring the output amounts to be the same, both in original and multisig flavours.  Now the forums are back up I'm going to be doing some releases so I'll include some info about how I'm handling transaction processing rules.  In a nutshell though for multisig if there is a 4th output for change it must be the same as the sending address otherwise change/destination addresses are ambiguous and I throw the tx out.


I think Tachikoma may have already alluded to this but we don't have the recipient address public key so can't include it as a signatory (thus the concern over the recipient redeeming the multisig shouldn't be an issue).  Tachikoma has also addressed the address>key encoding byte requirement so I won't rehash that here


Satoshi code and the protocol aren't the critical issue here - the miners are.  Uncompressed public keys would be great I agree, but where possible we need to ensure best ability to relay & include transactions in blocks.  It's worth mentioning that a lot of blocks are mined by pools, and some of the bigger pools run custom patches on bitcoind (and some use an entirely different software stack completely) which should encourage us to stay as close to 'vanilla' bitcoin transactions as possible (to minimize the risk of transactions being left out by miners).


I'm supportive of compressed keys for now too (not to detract from Grazcoin's ideas, we can certainly review further but in the interests of keeping momentum and removing the concerns about ECDSA point validity I think sticking with compressed is the clearest path).


I'm still here, still doing things  Noticed the forums came back up yesterday.  Progress update & a couple of code releases incoming over the next few hours (oh and I'll write a brief summary as you requested before the forums went down).

Thanks all!

In light of recent events, you would think that Mastercoin stands most to benefit from Bitfunder and BTCT shutting down. If Havelock is on the way then perhaps now is the time for developers to start focusing on Mastercoin.


Smart property by far. Not everyone can benefit from stuff like SR. Most people aren't demanding it. Everyone benefits form smart property and it's a completely legitimate use which can only grow the global economy.

The sooner there is smart property the better because it gives people stuff to buy with Bitcoins. What I want to know is whether or not the technology developed by Mastercoin can be ported over to Litecoin? If the answer is yes then this idea has a great long term future but if its for Bitcoin only then it has a point of failure (Bitcoin) and that in my opinion isn't good.


How far away from this are you?

Perhaps you should offer a bounty to people who bring developers to Mastercoin? The moment of opportunity is now to get developer interest. Advertise Mastercoin now, start a thread or go to the threads where people are in panic. I've already taken liberty of directing some of them to Mastercoin but since you are the Mastercoinminster it should be you.

So which is more important now, a marketplace (see SR) or a smart property exchange?

Yup! Future contests will be feature-driven. Basically, once we reach a milestone, the project will pay anybody who helped us get there, in proportion to the size of their contribution. As before there will be a big focus on collaboration, and probably an explicit code review requirement in the acceptance criteria.

We've got to get the distributed exchange working before smart property will make sense though.

Bitfunder.com is going to exclude US residents from trading on their platform. This could be the first step of shutting down their site (as seen with btct.co). This would cause a huge vacuum in the bitcoin stock world and would create an even greater opportunity for Mastercoin's smart property feature. I'm calling for a dedicated development team and / or dedicated smart property contest.

I couldn't post when I made this transaction (because the forum was offline), but it did happen: http://blockchain.info/tx/fe12cbb37bf81f20feede134a00a31b8b51c568072b57ed480d9994e016830b7

I finally got my act together and got the disparate change outputs consolidated back at the Exodus Address again. The balance at that address now accurately reflects the available project funds again.

I think I have enough information now. The uncompressed public key would be absolutely ideal IF we could be confident that the bitcoin core devs were friendly to our cause. However, some of those guys are openly hostile to us, and if anybody in that group supports us, they haven't said so publicly.

Grazcoin, I hope you won't be sad if we hold onto your idea until we are more established? It's clear to me that we can't use it exclusively right now. We might be able to support both types of transactions, but I don't want to make things more complicated than we absolutely have to.

I would LOVE to get a CTO working full-time on this. That is one of the stated goals of our coding contest. I'm too expensive, and after some private conversations with Tachikoma, he's probably too expensive also, although I won't close that door completely until he does.

The board and I have bandied about 40 BTC/month as a suggested salary for a full-time hire, along with a generous allotment of MasterCoins, vesting like stock options.

Even when we have a CTO, I'll probably make the final decision on core issues like this, or at least reserve veto power.

So, for now, let's use Tachikoma's method. Once we are firmly established and/or the core bitcoin devs become friendly to our cause, we should switch to grazcoin's implementation, or at least support it.

Zathras - I haven't heard anything from you in awhile. What have you been up to?

What I was trying to say, before others also misinterpret my words, is that J.R. is not as well versed in the whole technical aspect of multisig transactions as the current developers are. He needs to rely on information he is being given from the other developers like me and Grazcoin.

While it is OK if he is not the primary coder, why is he detached from development?  Not just detached, but 'too detached'?  That is not good.  We need a CTO quick.  J.R.?  WTF?


Oh, OK.  Now I see what is going on.  He is busy worrying about who is trying to kill him.

There is nothing wrong with using uncompressed public keys; I'm all for it.

The problem is that you can't guarantee that your uncompressed public key is also a valid ECDSA point, this is the part I'm worried about since it would be fairly easy for the reference client to add a simple check to see if a public key is actually a valid one and flag it as nonValid if this is not the case.

I think it's time the Mastercoin foundation appoints an official developer that will be the Linus to our Linux. He/She should decide on the official implementations so that after hearing all the sites the discussion a decision can be made on the official spec. I'm afraid J.R. is not the perfect candidate to this because he is too detached from the actual development.

The transaction being used is a standard BIP11:
https://en.bitcoin.it/wiki/BIP_0011
The spec simply says:
m {pubkey}...{pubkey} n OP_CHECKMULTISIG
and that is what "simple multisig" uses.
compressed public keys is something was later introduced, but the original is the non compressed one.

The last discussion was about potential enforcing rules on the public keys or not.
The protocol says nothing about this data, and if in the future the consensus requests a change, mastercoin spec can adapt as well.
Any change would anyway influence only new transactions.

For me it is clear that simplicity and unambiguity should be main concerns in defining a protocol. Also keeping enough place for future enhancements is important. Embedding the recipient address inside the data enables also dynamic recipients (like pay to script or some encryption layer), which contributes flexibility to the mastercoin protocol. Having only 2 outputs instead of 4, lowers the utxo pollution and is more esthetic.

You can see that there are already many such transactions on the blockchain:
https://encrypted.google.com/#q=site%3Ablockchain.info+Escrow

As for the rotation of the data - the idea is to change the data pubkey string from  "004....000" to "04....0000", so it "looks" more like a normal public key, but since the protocol and all common implementations do not request such a verification, I left it out. If ever a public verification code becomes part of the bitcoin protocol, the rotated data would not pass the verification anyway, so let's leave it aside.

Getting killed by my government is very low on my current list of worries. I very much doubt they are paying attention to this project yet. If they do start paying attention, they would have no reason whatsoever to bother me. I'm developing a very powerful set of tools, and any powerful set of tools can be used for bad purposes. They have no more reason to hassle me than they have to hassle Gavin. If they did hassle me, I'd probably stop what I'm doing, but there would be no shortage of people well-qualified to take my place. I've heard Gavin make similar statements.

I'm not out to destroy my government. Crypto-currencies do threaten to destroy our existing monetary systems, but that is simply because they are superior, not because they are malicious. It is in the government's interest to keep people like me involved - I'm not hostile to my government, and I'm very easy to keep an eye on. Why would they want to risk my being replaced by an anonymous anarchist? I tend to think of the government as inept, but even I don't think they are that inept.

What are the advantages of using uncompressed public keys?

I'd really rather not rely on transactions which are non-standard in any way if they can be easily distinguished from normal bitcoin transactions. It wouldn't be very long before somebody introduced a "patch" to "fix the problem" (and exclude our transactions). I get the feeling that there are a couple people (at least) who have that kind of clout and wouldn't mind making an object lesson out of us. I don't want to make it easy for them!

What would be involved with "rotating" the data? Would the benefits of this method be worth the extra effort of the rotation and un-rotation?

Thanks!

As of right now, buying and selling them as far as I know (via project milestones on post #2), though I believe there are no similar tools like bitcoin-d yet? As such, I'm not sure what the actual process of transferring ownership is at the moment. People will either buy or sell based on what future potential they see in MSC.
MasterCoin Buyer/Seller Thread

So, what can I do with the master coins I have right now?

First amendment protects us to create these neutral tools. We have no criminal intent by creating Mastercoin, it's not like we created it on the sole, primary, or with even any  intention to break laws, which I believe a prosecutor would have to show. In any regard, JR getting snuffed legally seems very unlikely and trivially defendable.

I suppose that you're alluding to recent events, and that is a very real threat by "fatally idealistic", but in the end, considering likelihoods of various risks, JR, would you agree that Mastercoin is too important not to press on?

I don't know of python-ecdsa code that checks keys. Only sign and verify are there.
Checking what this ruby code does lead me here:
http://ruby-doc.org/stdlib-2.0/libdoc/openssl/rdoc/OpenSSL/PKey/EC.html (check_key)
which is based on:
http://openssl.sourcearchive.com/documentation/1.0.0e-2ubuntu4/crypto_2ec_2ec_8h_af95a20fbf391a4dd8ef484a4c2bc6f6b.html

Although theoretically I could use the free space in the fake public key which is now padded with zeros together with some rotation of the data to generate a valid pubkey (and that is not going to be easy), I think it makes sense to postpone that feature to the point that major part of the bitcoin nodes do have new rules.