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

Tachikoma

hero member

Activity: 938

Merit: 1000

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')
 => #, @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

sr. member

Activity: 284

Merit: 250

Quote from: Tachikoma on October 07, 2013, 03:29:36 AM

Quote from: grazcoin on October 07, 2013, 03:23:14 AM

Quote from: Tachikoma on October 07, 2013, 03:02:37 AM

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

hero member

Activity: 938

Merit: 1000

Quote from: grazcoin on October 07, 2013, 03:23:14 AM

Quote from: Tachikoma on October 07, 2013, 03:02:37 AM

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

sr. member

Activity: 284

Merit: 250

Quote from: Tachikoma on October 07, 2013, 03:02:37 AM

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?

Tachikoma

hero member

Activity: 938

Merit: 1000

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.

grazcoin

sr. member

Activity: 284

Merit: 250

Quote from: W2014 on October 06, 2013, 11:05:12 PM

Finally back up - any developments? Grin

The blackout did only good to mastercoin-tools:
https://bitcointalksearch.org/topic/m.3290646

Quote from: grazcoin on October 07, 2013, 02:22:07 AM

Added

send mastercoin transaction (the real thing, not "advisor")
implement sending and parsing of "simple multisig"

simple multisig

dust limit to 1EXoDus
all the change to BIP11 1-of-2
- pubkey1 is the one of the sender (redeemable)
- pubkey2 is recipientHex+dataHex+padding

on the blockchain

Mastercoin tx:
https://blockchain.info/tx/aa64fd6088532156a37670e6cbd175c74bb101f1406517613a1a0ae6bc02fb02
Test Mastercoin tx:
https://blockchain.info/tx/298a6af50089184f7b434c700f83f390d5dfdd5dac10b39b95f99036a5c66df7

parsing

Code:

$ python msc_parse.py -t aa64fd6088532156a37670e6cbd175c74bb101f1406517613a1a0ae6bc02fb02
[I] main: {'currency_type_str': 'Mastercoin', 'transaction_type_str': 'Simple send', 'currencyId': '00000001', 'transaction_method_str': 'multisig_simple', 'recipientAddress': '17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX', 'padding': '000000', 'amount': '0000000002faf080', 'changeAddress': '182osbPxCo88oaSX4ReJwUr9uAcchmJVaL', 'formatted_amount': '0.50000000', 'baseCoin': '00', 'dataSequenceNum': '45', 'transactionType': '00000000'}
$
$ python msc_parse.py -t 298a6af50089184f7b434c700f83f390d5dfdd5dac10b39b95f99036a5c66df7
[I] main: {'currency_type_str': 'Test Mastercoin', 'transaction_type_str': 'Simple send', 'currencyId': '00000002', 'transaction_method_str': 'multisig_simple', 'recipientAddress': '17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX', 'padding': '000000', 'amount': '0000000000000003', 'changeAddress': '182osbPxCo88oaSX4ReJwUr9uAcchmJVaL', 'formatted_amount': '0.00000003', 'baseCoin': '00', 'dataSequenceNum': '45', 'transactionType': '00000000'}
$

outputs results
https://github.com/grazcoin/mastercoin-tools/blob/master/outputs/parse-with-multisig-simple.log

redeem multisig
https://github.com/grazcoin/mastercoin-tools/blob/master/NOTES

help on commands

Code:

$ python msc_send.py -h
Usage: msc_send.py [options]

Options:
    -h, --help            show this help message and exit
    -m TX_METHOD, --transaction-method=TX_METHOD
                          basic or multisig
    -c CURRENCY_ID, --currency-id=CURRENCY_ID
                          1 for Mastercoin, 2 for Test Mastercoin
    -a AMOUNT, --amount=AMOUNT
                          amount of coins
    -x FEE, --fee=FEE     fee for transaction
    -r RECIPIENT_ADDRESS, --recipient=RECIPIENT_ADDRESS
                          recipient address
    -f FROM_ADDRESS, --from=FROM_ADDRESS
                          from address or pubkey
    -p PRIV_KEY, --private-key=PRIV_KEY
                          private key for signing the tx (overrides from
                          address)
    -k, --key-prompt      prompt for hidden private key for signing the tx
                          (overrides from address)
    -s HOST_PORT, --send-tx=HOST_PORT
                          transmit tx to specific bitcoin node HOST:PORT
    -b, --broadcast-tx    broadcast tx to bitcoin network
    -d, --debug           turn debug mode on

Code:

$ python msc_parse.py -h
Usage: msc_parse.py [options]

Options:
  -h, --help            show this help message and exit
  -d, --debug           turn debug mode on
  -t SINGLE_TX, --transaction=SINGLE_TX
                        hash of a specific tx to parse

bitcoinian

newbie

Activity: 19

Merit: 0

and...... we're back

W2014

member

Activity: 205

Merit: 10

Finally back up - any developments? Grin

TraderTimm

legendary

Activity: 2408

Merit: 1121

Quote from: dacoinminster on October 02, 2013, 04:00:52 PM

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.

dacoinminster

legendary

Activity: 1260

Merit: 1031

Rational Exuberance

Quote from: TraderTimm on October 02, 2013, 02:57:21 PM

Don't forget being targeted for encouraging money-laundering. If you think this 'protocol' idea isn't going to be under scrutiny from the Federal authorities, you're mistaken.

I'd recommend dacoinminster to return all the funds and take his ball and go home, before he ends up in a cell next to Dread Pirate Roberts.

But of course, he'll rationalize a way not to suspend development.

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.

Speaking of dangerous tools, this whole silk road situation brings to the forefront of my mind something that has been percolating for awhile. The MasterCoin protocol could be rather trivially extended to support decentralized e-commerce. For instance:

Define a message for declaring what you are selling, your alias name and a link to a webpage with more info (if webpage gets taken down, simply rebroadcast this message with a new URL)
Define a message for a buyer to initiate a purchase, with funds held in escrow by the protocol
Define a message for a seller to accept a purchase initiated by a buyer (required before a buyer can complete payment and leave feedback)
Define a message for a buyer to complete the transaction (either destroy funds in escrow or pay them to seller)
- Includes feedback as a rating number and a link to a webpage with feedback comments
- If purchase is completed successfully, a percentage of funds are destroyed (to make it more expensive to create fake feedback) Percentage can be lower once seller is established)

If we made something like this, it would then be possible to parse these messages to create a list of sellers and their reputations (and buyers and their reputations). Identities would be tied to bitcoin addresses. Payments would be in MasterCoin (or MasterCoin-derived currencies).

I'm not sure we'll ever do this though. I'm not sure there are enough legal use cases to justify it!

TraderTimm

legendary

Activity: 2408

Merit: 1121

Quote from: murraypaul on October 02, 2013, 10:05:21 AM

Quote from: zathras on October 01, 2013, 04:38:00 PM

If we really wanted to remove the same amount requirement, perhaps we could:

Design a protocol and blockchain that actually support what you need to do?

I know noone wants to hear this, but you are having all these problems just encoding a simple altcoin A->B transaction.
How much worse it is going to be when you are trying to trade coins built on top of MasterCoin, or implement distributed exchanges, or any of the other cool ideas?
You have created an altcoin, but rather than running an altcoin blockchain, you are trying to cram your information into someone else's blockchain.

You are trying to take a car chassis and transmission and built an aircraft.
You might eventually manage it, but it will be one hell of an ugly aircraft, and probably won't fly well.

Don't forget being targeted for encouraging money-laundering. If you think this 'protocol' idea isn't going to be under scrutiny from the Federal authorities, you're mistaken.

I'd recommend dacoinminster to return all the funds and take his ball and go home, before he ends up in a cell next to Dread Pirate Roberts.

But of course, he'll rationalize a way not to suspend development.

dacoinminster

legendary

Activity: 1260

Merit: 1031

Rational Exuberance

Quote from: dacoinminster on October 02, 2013, 12:20:53 PM

Wow. Dread Pirate Roberts in jail, silk road seized, bitcoin prices plummeting.

Just a reminder: the contest is for $25k, not a specific number of bitcoins. I was thinking of making the next contest for a specific number of bitcoins, but . . . maybe not.

This is a good opportunity to mention something important: once we have features which COULD be used for illegal things, all devs should make sure to have really bold and visible warnings that everyone is responsible to know the laws in their own jurisdiction, and not break them. We must never be seen as encouraging illegal activity, even though our tools can be used in that way.

Tachikoma

hero member

Activity: 938

Merit: 1000

Quote from: grazcoin on October 02, 2013, 09:59:42 AM

how about having only 2 outputs:

dust limit to 1EXoDus
All the rest to the BIP11 that includes [changeAddr, (modified)recipientAddr, dataAddr]

This is not very different from what we have now. We just drop 2 extra outputs (to recipientAddr and to changeAddr).
In order to avoid spending of the tx by the recipient address, we would modify it lightly (e.g. by changing the first 0 to 1), so it is still readable, but it can't sign the tx. By using this method we avoid the need to differ between the outputs (there are only one simple and one multisig).

We don't have to change the recipient address, as far as I know you can only use public keys, not addresses. The problem is that you can't just make a public key that looks like an address since it's hex only. We could convert an address to hex but this would increase the amount of bytes needed for encoding. The other problem is that multisigs are harder to spent then a normal address at the moment. However this could be tackled by automatically creating a 'clean-up' transaction from a mastercoin-client that looks for all multisigs and send them to a normal address.

murraypaul

sr. member

Activity: 476

Merit: 250

Quote from: zathras on October 01, 2013, 04:38:00 PM

If we really wanted to remove the same amount requirement, perhaps we could:

Design a protocol and blockchain that actually support what you need to do?

I know noone wants to hear this, but you are having all these problems just encoding a simple altcoin A->B transaction.
How much worse it is going to be when you are trying to trade coins built on top of MasterCoin, or implement distributed exchanges, or any of the other cool ideas?
You have created an altcoin, but rather than running an altcoin blockchain, you are trying to cram your information into someone else's blockchain.

You are trying to take a car chassis and transmission and built an aircraft.
You might eventually manage it, but it will be one hell of an ugly aircraft, and probably won't fly well.

Mooshire

sr. member

Activity: 322

Merit: 250

Now what do I do with the 2 mastercoins I have XD

grazcoin

sr. member

Activity: 284

Merit: 250

Quote from: Tachikoma on October 02, 2013, 03:58:31 AM

Quote from: zathras on October 01, 2013, 04:38:00 PM

I think if we remove the requirement to have outputs be for the same amount I think we're going to run up against a lot of transactions that are ambiguous. It's worth pointing out that in multisig transactions the seq number now always starts with 0, so there are no sequence numbers to help us distinguish destination vs change outputs.

Actually all my multisig sequences start with 1 because otherwise I couldn't create valid looking ECDSA points. Could you check your implementation if you can get that to work? If so we should probably switch to 0.

Quote from: zathras on October 01, 2013, 04:38:00 PM

If we really wanted to remove the same amount requirement, perhaps we could:
* drop a few bytes of checksum for the destination address in the data pubkey?
* require that mastercoin clients always make the change address the same as the sending address?

I have been doing the latter; making sure the change always goes back to the sending address. It makes sense since you need funds to keep making transactions and it makes the parsing much easier. By forcing such rules we also force users to start using real clients with multisig support instead of using the parasitic address version.

I am more for optimization of the multisig tx, so I repeat my previous suggestion at:
https://bitcointalksearch.org/topic/m.3143365

how about having only 2 outputs:

dust limit to 1EXoDus
All the rest to the BIP11 that includes [changeAddr, (modified)recipientAddr, dataAddr]

This is not very different from what we have now. We just drop 2 extra outputs (to recipientAddr and to changeAddr).
In order to avoid spending of the tx by the recipient address, we would modify it lightly (e.g. by changing the first 0 to 1), so it is still readable, but it can't sign the tx. By using this method we avoid the need to differ between the outputs (there are only one simple and one multisig).

Tachikoma

hero member

Activity: 938

Merit: 1000

Quote from: zathras on October 01, 2013, 04:38:00 PM

I think if we remove the requirement to have outputs be for the same amount I think we're going to run up against a lot of transactions that are ambiguous. It's worth pointing out that in multisig transactions the seq number now always starts with 0, so there are no sequence numbers to help us distinguish destination vs change outputs.

Actually all my multisig sequences start with 1 because otherwise I couldn't create valid looking ECDSA points. Could you check your implementation if you can get that to work? If so we should probably switch to 0.

Quote from: zathras on October 01, 2013, 04:38:00 PM

If we really wanted to remove the same amount requirement, perhaps we could:
* drop a few bytes of checksum for the destination address in the data pubkey?
* require that mastercoin clients always make the change address the same as the sending address?

I have been doing the latter; making sure the change always goes back to the sending address. It makes sense since you need funds to keep making transactions and it makes the parsing much easier. By forcing such rules we also force users to start using real clients with multisig support instead of using the parasitic address version.

zathras

sr. member

Activity: 266

Merit: 250

Quote from: dacoinminster on September 30, 2013, 11:25:01 AM

Quote from: zathras on September 29, 2013, 06:08:27 PM

Quote from: Tachikoma on September 29, 2013, 09:53:30 AM

Quote from: zathras on September 29, 2013, 07:50:21 AM

Tachikoma, regarding your test transactions...

My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same

I wouldn't even make it that strict (unless J.R. already wrote that in the spec) if I want to send more bitcoins then I should be free to do so and it should not invalidate the Mastercoin transaction.

I believe this is actually already explicitly defined by JR both in his comments and the spec. It's less about the value of the amount, more that all outputs have the same amount.

Quote from: dacoinminster on September 19, 2013, 10:28:55 AM

All protocol transactions should have the same output amount. If one output is different, that is the change address.

Quote

(From the spec)
All transaction outputs should be for the same amount, which should be above the “dust” threshold, and should include an appropriate fee to ensure that miners include them in the block chain in a timely manner. For instance, the first MasterCoin transactions had three outputs of 0.00006 BTC each, with a 0.0001 BTC transaction fee.

Based on the above those rules are applied in my implementation and I require all outputs to be for the same amount. The exception is multisig where I've temporarily allowed the multisig output amount to be ref/exodus amount * 2 while we firm up the discussion.

Having all the outputs be the same amount is merely a convenience for identifying the change address. I'm fine with a less strict implementation as long as it is still possible to identify the change address.

I think if we remove the requirement to have outputs be for the same amount I think we're going to run up against a lot of transactions that are ambiguous. It's worth pointing out that in multisig transactions the seq number now always starts with 0, so there are no sequence numbers to help us distinguish destination vs change outputs.

Let's say we remove the requirement for outputs to be for the same amount & allow any value to be used, example tx:

Output 1: 0.0005 (what is this output for? change or destination?)
Output 2: 0.0043 (what is this output for? change or destination?)
Output 3: 0.0006 (easily identifiable as Exodus from the address used)
Output 4: 0.001 (easily identifiable as multisig)

I'm not sure how we'd determine destination vs change in that scenario.

If we really wanted to remove the same amount requirement, perhaps we could:
* drop a few bytes of checksum for the destination address in the data pubkey?
* require that mastercoin clients always make the change address the same as the sending address?

I'm keen to firm this up as I notice people are trading thousands of dollars on the buyer/seller thread and once I throw a windows desktop wallet into the mix I think there will be an increasing level of transactions - it's critical to our success that our community have confidence a valid transaction now will not be invalidated in future, and vice versa that an invalid transaction now will not become valid in future (hence my desire to explicitly lock in 'simple send' transaction processing rules).

Please let me know if there is a set of transaction processing rules that I've somehow glossed over or if I'm missing something obvious (eg destination address will always be vout1 of the sendmany transaction) but I haven't seen anything stated.

Thanks!

dacoinminster

legendary

Activity: 1260

Merit: 1031

Rational Exuberance

For complete financial transparency:

Quote

---------- 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!

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: Tachikoma on September 30, 2013, 11:29:48 AM

Can anybody verify that in the code example above; nValue is the (Bitcoin) amount and (int)GetSerializeSize(SER_DISK,0) the bytesize of the output script.

nValue is the bitcoin amount, in satoshis.

GetSerializeSize() is the serialization of the transaction output, not the script.

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