MasterCoin: New Protocol Layer Starting From “The Exodus Address”

[grazcoin]

I really like your idea of using uncompressed public keys versus compressed keys. The only problem I have with it is that according to my knowledge the public key you build is not a valid ECDSA point.

Code:

0046727d1b3d6847f9ed344561a315f54b801edf637cad93d000450000000000000002000000000000000300000000000000000000000000000000000000000000

A public key should either start with 04 or 02 your starts with 004. I don't see how this could be a valid public key. Could you, or somebody else, explain why this transaction has been accepted and mined? Even if I remove the leading zero and add it to the end my software recognises that it's not a valid point address.

I also played with a version that rotates the first 0 to the end, but miners seem to take the tx as is.
Can you please show me on the satoshi code (and better on the protocol) where the list of public keys in BIP11 are checked to be valid ECDSA points?

[1715284392]

1715284392

[1715284392]

1715284392

[1715284392]

1715284392

[Tachikoma]

I really like your idea of using uncompressed public keys versus compressed keys. The only problem I have with it is that according to my knowledge the public key you build is not a valid ECDSA point.

Code:

0046727d1b3d6847f9ed344561a315f54b801edf637cad93d000450000000000000002000000000000000300000000000000000000000000000000000000000000

A public key should either start with 04 or 02 your starts with 004. I don't see how this could be a valid public key. Could you, or somebody else, explain why this transaction has been accepted and mined? Even if I remove the leading zero and add it to the end my software recognises that it's not a valid point address.

I also played with a version that rotates the first 0 to the end, but miners seem to take the tx as is.
Can you please show me on the satoshi code (and better on the protocol) where the list of public keys in BIP11 are checked to be valid ECDSA points?

Obviously this isn't done otherwise your transaction would be rejected.

The fact that the reference client currently does not check if a public key is actually a valid one does not mean we should also disregard it. What happens if an update does check for the validity and none of the transactions get accepted anymore? I'm trying to think ahead.

[grazcoin]

I really like your idea of using uncompressed public keys versus compressed keys. The only problem I have with it is that according to my knowledge the public key you build is not a valid ECDSA point.

Code:

0046727d1b3d6847f9ed344561a315f54b801edf637cad93d000450000000000000002000000000000000300000000000000000000000000000000000000000000

A public key should either start with 04 or 02 your starts with 004. I don't see how this could be a valid public key. Could you, or somebody else, explain why this transaction has been accepted and mined? Even if I remove the leading zero and add it to the end my software recognises that it's not a valid point address.

I also played with a version that rotates the first 0 to the end, but miners seem to take the tx as is.
Can you please show me on the satoshi code (and better on the protocol) where the list of public keys in BIP11 are checked to be valid ECDSA points?

Obviously this isn't done otherwise your transaction would be rejected.

The fact that the reference client currently does not check if a public key is actually a valid one does not mean we should also disregard it. What happens if an update does check for the validity and none of the transactions get accepted anymore? I'm trying to think ahead.

First of all - the only rule in our game is the bitcoin protocol. If the reference client decides to do something new (e.g. dropping tx which don't follow some new rules), it may be considered as a fork (there are already other implementations out there, as well as old clients). Saying that, I don't mind changing the format of the fake pubkey so it passes a pubkey test. Do you have some verification code that checks if pubkey is really pubkey?

[Tachikoma]

I'm using bitcoin-ruby to test my points. A ruby wrapper around some OpenSSL functions.

Code:

1.9.3-p286 :002 > require 'bitcoin'
 => true
1.9.3-p286 :003 > Bitcoin::Key.new(nil, '02010000000000000002000000000000000d000000000000000000000000000000')
 => #<Bitcoin::Key:0x007ffe639629e0 @key=#<OpenSSL::PKey::EC:0x007ffe63962940>, @pubkey_compressed=true>
1.9.3-p286 :005 > Bitcoin::Key.new(nil, '02000000000000000002000000000000000d000000000000000000000000000000')
OpenSSL::PKey::EC::Point::Error: invalid compressed point
1.9.3-p286 :006 > Bitcoin::Key.new(nil, '0046727d1b3d6847f9ed344561a315f54b801edf637cad93d000450000000000000002000000000000000300000000000000000000000000000000000000000000')
OpenSSL::PKey::EC::Point::Error: invalid encoding

Perhaps something like python-ecdsa or similar might be able to do the same.

[grazcoin]

I'm using bitcoin-ruby to test my points. A ruby wrapper around some OpenSSL functions.

Code:

1.9.3-p286 :002 > require 'bitcoin'
 => true
1.9.3-p286 :003 > Bitcoin::Key.new(nil, '02010000000000000002000000000000000d000000000000000000000000000000')
 => #<Bitcoin::Key:0x007ffe639629e0 @key=#<OpenSSL::PKey::EC:0x007ffe63962940>, @pubkey_compressed=true>
1.9.3-p286 :005 > Bitcoin::Key.new(nil, '02000000000000000002000000000000000d000000000000000000000000000000')
OpenSSL::PKey::EC::Point::Error: invalid compressed point
1.9.3-p286 :006 > Bitcoin::Key.new(nil, '0046727d1b3d6847f9ed344561a315f54b801edf637cad93d000450000000000000002000000000000000300000000000000000000000000000000000000000000')
OpenSSL::PKey::EC::Point::Error: invalid encoding

Perhaps something like python-ecdsa or similar might be able to do the same.

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.

[vokain]

To my knowledge, nothing we are doing breaks any laws. We are building tools, which users could use to break laws, just like any tool.

Carefully consider why Satoshi took great pains to be anonymous.

Do you really think that anything built upon your 'protocol' won't be subject to reprisal? If anything, it will be a "live" simulation of how governments react when they have a target.

You're either horribly naive, or fatally idealistic to think this is going to end well.

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?

[Mooshire]

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

[vokain]

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

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

[dacoinminster]

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!

[dacoinminster]

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?

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.

[grazcoin]

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!

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.

[Tachikoma]

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.

[HammerFist]

I'm afraid J.R. is not the perfect candidate to this because he is too detached from the actual development.

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.

Getting killed by my government is very low on my current list of worries.

[Tachikoma]

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.

[dacoinminster]

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?

[dacoinminster]

For complete financial transparency:

---------- Forwarded message ----------
From: J.R. Willett
Date: Tue, Oct 1, 2013 at 8:12 AM
Subject: Notice of proposed expenditures
To: Mastercoin Board


Please be advised of a couple upcoming payments from MasterCoin project funds.

$45.90 in BTC to 1CTctpqg7JdomAeq3fz7Ynw43VDVJjc4o3 to reimburse David's purchase of a couple MasterCoin-related domains
1 BTC to 1KLoFjuq6o4Q6RGNdDSdHoWjazQqQLRnmH to Mich for our slick new website

I'll try to process these tomorrow if I don't hear any objections.

Thanks!

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.

[maxmint]

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.

[dacoinminster]

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.

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.

[klee]

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

[Luckybit]

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.

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

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.

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.

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.