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

Activity: 476
Merit: 250


View Profile
September 13, 2013, 08:44:03 PM
 #921

Yes, once you actually have something working, it becomes easier to defend.
At the moment, all there really is is money and some ideas.
Other people have money, and can just steal the ideas.

BTC: 16TgAGdiTSsTWSsBDphebNJCFr1NT78xFW
SRC: scefi1XMhq91n3oF5FrE3HqddVvvCZP9KB
1534591502
Hero Member
*
Offline Offline

Posts: 1534591502

View Profile Personal Message (Offline)

Ignore
1534591502
Reply with quote  #2

1534591502
Report to moderator
1534591502
Hero Member
*
Offline Offline

Posts: 1534591502

View Profile Personal Message (Offline)

Ignore
1534591502
Reply with quote  #2

1534591502
Report to moderator
BOUNTY PORTALS
BLOG
WHERE BOUNTY MANAGEMENT
MEETS AUTOMATION
SIGNATURE CAMPAIGNS
TWITTER
FACEBOOK
MEDIA CAMPAIGNS
AND MORE!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
September 14, 2013, 08:56:06 AM
 #922


It seems that maximum is m-of-20 in the current code base (where m<=20):
https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L882


According to #bitcoin-dev the only supported ones are n-of-3... I think we need to test it out before deciding on the final spec.

Fount the answer in the bitcoind code.

Code:
bool IsStandard(const CScript& scriptPubKey)
{
    vector<valtype> vSolutions;
    txnouttype whichType;
    if (!Solver(scriptPubKey, whichType, vSolutions))
        return false;

    if (whichType == TX_MULTISIG)
    {
        unsigned char m = vSolutions.front()[0];
        unsigned char n = vSolutions.back()[0];
        // Support up to x-of-3 multisig txns as standard
        if (n < 1 || n > 3)
            return false;
        if (m < 1 || m > n)
            return false;
    }

    return whichType != TX_NONSTANDARD;
}


Seems we hit the first bump in the road. I suspect that our publickeys can't be parsed as valid ECDSA coordinates so transaction is not getting processed by nodes on real-net, 'ERROR: CTxMemPool::accept() : nonstandard transaction type'. The reason it worked on testnet is that testnet does not do strict checking before accepting a transaction. I will research to see if there is a way to somehow encode the data in a way that it looks like a valid publickey. I'm trying to figure out why it's not passing the tests.

I would appreciate it if somebody could replicate my tests, perhaps I simply made an error somewhere when crafting my raw transactions.

In order to replicate my tests please create a transaction with one input, two outputs. One ouput with a change address and one with a multisig script with 1 actual publickey, so you can redeem the output, and two data encoded publickeys.

Code:
{"hash":"0e2183cf1d5943c130e9594c44ba3981fe046ceee8851444f4407de6da3232a7","ver":1,"vin_sz":1,"vout_sz":2,"lock_time":0,"size":371,
"in":[{"prev_out":{"hash":"c9fc3f6f8dc828d11eab3196393f13e8c147f835d2d0568df26009aba9617a6e","n":0},"scriptSig":"3046022100ca5d8934c8acf7060e0826e52b55c7e28ae18ab2d22bd9f65b8e44f16856c6c5022100fc69c5d003607aa4114f8eae8026c549aff542ed452ac9af85328ea2b0a292f701 04ea5fbd95738d81e3857067e8156b0887aad60ba2018c21807705c0e5cd4ee9f5187d56e6a827b5c7f54721c46c9c372bdc929a16f3331c3290fdbebc55a7572e"}],
"out":[{"value":"0.23668000","scriptPubKey":"OP_DUP OP_HASH160 e8c6391242865cb288487d938f87d40706381c12 OP_EQUALVERIFY OP_CHECKSIG"},{"value":"0.00006000","scriptPubKey":"1 04c5ac10feed00d99b6571bb42567d43e255b8ace9adf078908e3c4827f954d9188fb464fba3911efc10ac8d1936a088f4682795b40e60aa87b43601339ec76808 045200000001000000020000000000000001000000000000000000000000000000 042600000001000000020000000000000001000000000000000000000000000000 3 OP_CHECKMULTISIG"}]}

Edit: Found an error in my first transaction because I was denoting it as a full publickey while I was actually using compressed ones. This one is valid according to my own tests but bitcoind doesn't like it still. The code responsible for flagging a tx as non-standard can be found here.
Code:
{"hash":"e2fd41377f1fb432e9ebe5fe681a127572f0e157e326598bd217e2117e3104f5","ver":1,"vin_sz":1,"vout_sz":2,"lock_time":0,"size":338,
"in":[{"prev_out":{"hash":"c9fc3f6f8dc828d11eab3196393f13e8c147f835d2d0568df26009aba9617a6e","n":0},"scriptSig":"304502204b08c27d0286660dfde1ee5e79060d57409f3a8eff52e5fddda3c28bf8a9e1b0022100cd5b6591bfcedd6c0cf48a8cece0d1e27baecc723fe1c81d84a7d85d4e88fd8701 04ea5fbd95738d81e3857067e8156b0887aad60ba2018c21807705c0e5cd4ee9f5187d56e6a827b5c7f54721c46c9c372bdc929a16f3331c3290fdbebc55a7572e"}],
"out":[{"value":"0.23668000","scriptPubKey":"OP_DUP OP_HASH160 e8c6391242865cb288487d938f87d40706381c12 OP_EQUALVERIFY OP_CHECKSIG"},{"value":"0.00006000","scriptPubKey":"1 02c5ac10feed00d99b6571bb42567d43e255b8ace9adf078908e3c4827f954d918 025200000001000000020000000000000001000000000000000000000000000000 022600000001000000020000000000000001000000000000000000000000000000 3 OP_CHECKMULTISIG"}]}

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

Activity: 55
Merit: 0



View Profile
September 16, 2013, 12:18:08 AM
 #923

Aw crap. I meant to update the spec to change how the sequence numbers worked. Thanks for catching that.
When I was writing the code for MasterCoin Adviser, it occurred to me that it might be easier to parse MasterCoin transactions if the first data packet had the first sequence number, then additional data packets following, and then the reference packet last, with the last sequence number. But I never went back and updated the spec to reflect that change. I made that change because I thought it might help if we ever had transactions with data but no reference address.
Won't that be a problem when the data chunk is bigger than what fits in one address (20 bytes)? I mean, we'll need more than 1 sequence number, besides the reference sequence number. The only solution I see is to number the data addresses decreasingly from n-1 (n is reference sequence, n-1 for the first data address, n-2 for the second data address, etc), which seems untidy.

Anyway, I hope the alternate methods for data storage will make sequence numbers obsolete Smiley


I had intended Test MasterCoins to be used so I didn't have to create a TestNet version at all, but I have no opposition to TestNet implementations if that is helpful, especially if that helps reduce block-chain bloat Smiley
So... let's agree on a testnet address and epoch so that developers can test on the same grounds. Are you all OK with using miKnddGDQfU6rRYpLp2dhRyttnxH1WUo21 as the testnet exodus address (proposed by Tachikoma) and 15-Sept-2014 as the testnet epoch?

http://www.proofofexistence.com
AlexMc
Jr. Member
*
Offline Offline

Activity: 54
Merit: 0


View Profile
September 16, 2013, 02:13:39 AM
 #924

Would it not be a good idea for dacoinminster to create a Testnet Exodus address?  Surely it should be under his control, or that of the oversight board.

You store & send data in megabytes & gigabytes, why not send money in DigiBytes? (https://bitcointalk.org/index.php?topic=408268.0)
bytemaster
Hero Member
*****
Offline Offline

Activity: 770
Merit: 552

BitShares


View Profile WWW
September 16, 2013, 03:09:06 AM
 #925

Question, when am I going to receive my 3 BTC tip?

https://steemit.com  Blogging is the new Mining
Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
September 16, 2013, 08:05:14 AM
 #926

I've got some time to work on the multsig again and it seems that there is something wrong with the change address output in my transaction. When removing it I successfully send a multsig transaction using Mastercoin encoded data. Working on how to properly encode Mastercoin data using all 1-out-of-3 transactions now.

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

Activity: 938
Merit: 1000



View Profile WWW
September 16, 2013, 08:54:39 AM
 #927

There are two types of multisig outputs available at the moment that are useful for us.

  • 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):



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 Smiley

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

Activity: 311
Merit: 250


View Profile
September 16, 2013, 10:39:14 AM
 #928


It seems that maximum is m-of-20 in the current code base (where m<=20):
https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L882

Quote

According to #bitcoin-dev the only supported ones are n-of-3... I think we need to test it out before deciding on the final spec.

Fount the answer in the bitcoind code.

Code:
bool IsStandard(const CScript& scriptPubKey)
{
    vector<valtype> vSolutions;
    txnouttype whichType;
    if (!Solver(scriptPubKey, whichType, vSolutions))
        return false;

    if (whichType == TX_MULTISIG)
    {
        unsigned char m = vSolutions.front()[0];
        unsigned char n = vSolutions.back()[0];
        // Support up to x-of-3 multisig txns as standard
        if (n < 1 || n > 3)
            return false;
        if (m < 1 || m > n)
            return false;
    }

    return whichType != TX_NONSTANDARD;
}



Ran into this problem also when I was working on an application to try to implement 3 of 4 scheme. I had read somewhere that the maximum is 20 outputs also, but I guess only 3 is supported thus far by miners. Thanks to all you guys pushing this project forward I wish I could dig in and help but I got a full plate. I can be a continuous voice of encouragement for all its worth.



The mastercoin project translated into Chinese on weibo forum is pretty super exciting






The actual amount of the fees is considerably higher for bitcoin/mastercoin distributed exchange than for mastercoin/childcoin (even higher than you are imagining). This is because the seller actually sets a minimum fee which the buyer most pay to lock up the coins from other buyers. The fee goes to the bitcoin miner - it's gone forever. If we don't have something like this, a malicious actor could shut down the whole distributed exchange by spamming fake "intent to buy" messages.

There is a tradeoff here. If the market decides that these fees are too burdensome, there may be room for a centralized exchange website. I expect that the fees will not be too bad, especially compared with the huge risk of trusting an exchange to hold your coins.

If we find that bitcoin miners start spamming intent-to-buy messages to drive up prices, we may need to destroy coins instead. Perhaps the protocol should let the seller choose whether the fee goes to the miner or gets destroyed.

Another possibility would be to have the buyer put some MasterCoins up as collateral that they are making a serious buy offer, but this of course presents a problem for the first-time MasterCoin buyer Smiley

Yet another possibility would be to have the seller put up some additional MasterCoins as collateral that they will do refunds properly. Then the seller could collect the fees directly instead of going to the miners or destroying them. That seems rather complicated though.

I think we should implement the spec as written, and see how it plays out.


All good forethought, I have been thinking about some of those potential problems too. I have several semi planned out solutions if any of some of the problems you mention arise. like the spam problem and centralized solution or the need for a blockchain escrow (integration at Coinsigner). I am bringing some more press to mastercoin this week. Just because I think it is necessary for more people to know about the project.



Nxter,Bitcoiner,Ether highlevel developer working to improve the world.
milkyman
Newbie
*
Offline Offline

Activity: 29
Merit: 0


View Profile
September 16, 2013, 02:44:17 PM
 #929

There was a lot of critics about the Mastercoin network, in particular due to the many generated un-prunable transactions that are necessary to transmit the data between Mastercoin users.

I have an idea how to solve this problem, but this would require some changes to the protocol. Basically, instead of sending Bitoins to a data address without known private key (which is the current Mastercoin implementation), data can also be transmitted by sending Bitcoins to addresses that other Bicoin users own. To do so, a 'directory' of addresses has to be generated first. Each address can store a few bytes of data - and by sending tiny amounts of Bitcoins to these addresses, the pieces of data can be connected (similar to the current Mastercoin implementation). In this presented implementation, each address can store about 3 bytes. Therefore, to have enough data for a Mastercoin transaction, about 6 - 12 Bitcoin transactions have to be sent.

However, there is an important advantage in this implementation: Users that 'own' these addresses can later send all their earned Bitcoins to a single address. As a result, the millions of addresses are fully spent, and the whole system becomes prunable.

In contrast, in the current Mastercoin system, all the data addresses will remain with 0.00006 BTC stored and have to be saved in the blockchain forever.


Here's the implementation:

First, a global list of length 58^4 = 11316496 and width = 30 is created, and each cell can contain a Bitcoin-address. Let us index these cells with (n,#). The size of the list is a few GB, which is well managable to keep in lots of copies among all Mastercoin users.

Now to the actual idea: The cells (1,#) must contain addresses with the last four characters being -1111. The cells (2,#) must contain addresses -1112, and so on. Finally, the cells (11316496,#) must contain addresses with the last 4 characters -zzzz.

Now, every Bitcoin user that finds a key pair can publish the corresponding address in this list. To this end, he has to prove that he owns the private key of this address, to prevent people 'scamming' the list. Assumed, he found an address ending with -1113, he publishes it and it will be written into cell (3,1). Now let's assume > 29 other users also find addresses ending with -1113 and publish them. Then, all these addresses are alphabetically ordered and written into cells (3,1), (3,2), ... (3,30). Addresses with index > 30 are discarded. Obviously, with time, it becomes harder and harder to 'win' a cell in the list, because an address with low alphabetical index has to be found to kick out another one.

Since it is attractive for users to 'own' cells in the list, the time will come the list is complete, meaning that every cell has an address written in it. Of course, after completing the list, new addresses with lower index can still be published, and the list will be continuously updated.

Last, how can a string of data be transmitted?
First, the data is converted into base58 and chopped into pieces with length 4. Example: 3HZ28xpWUhq4... -> 3HZ2, 8xpW, Uhq4... The addresses (taken from the global directory) to send bitcoins to must have the following properties:

1.) They have to end with -3HZ2, -8xpW, -Uhq4...
2.) The addresses have to be in alphabetic order: (...-3HZ2) < (...-8xpW) < (...-Uhq4) < ...

Point 2 is important to connect the data pieces in the right order. It should be possible to find such an alphabetic order, since there are 30 different available addresses for each piece of data.


So, what you think... Assumed that Bitcoin miners feel threatened by the current Mastercoin implementation and stop to confirm transactions that have an Exodus recipient, this implementation could be a solution, since it harms the Bitcoin network less.


edit: follow-up here: https://bitcointalk.org/index.php?topic=284178.msg3166749#msg3166749
dacoinminster
Legendary
*
Offline Offline

Activity: 1232
Merit: 1022


Rational Exuberance


View Profile WWW
September 16, 2013, 04:02:37 PM
 #930

There are two types of multisig outputs available at the moment that are useful for us.

  • 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):



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 Smiley

First of all, I have to admit that I don't understand the inner working of bitcoin well enough yet to tell you if there is a problem with this method. (I'm working on it!) What you propose sounds reasonable to me, although I did receive this PM from a concerned party which seems to indicate there may be some hidden gotchas:

Quote
https://bitcointalk.org/index.php?topic=265488.msg3164831#msg3164831

I was reading the above post describing efforts to come up with a new Mastercoin tx scheme; there are a lot of issues with the above, in particular misconceptions about how Bitcoin works, as well as missed opportunities to add censorship resistance. In addition there are potential upcoming changes to Bitcoin that could seriously harm your protocol - changes that may end up getting more support than otherwise because they do exactly that.

I'd can create a complete specification taking all these issues into account, including explaining those issues are exactly and what trade-offs (and alternatives) were involved in coming up with the spec. In short I plan to answer the question "How do you implement a blockchain on top of Bitcoin in a robust, low-resource, and censor-proof way?"

If you are interested let me know and we can work out a set of concrete deliverables: specification document, design rational, and (optionally) example code written in Python with python-bitcoinlib implementing the proposed specification. Any contract would be fixed price, no-cure-no-pay, with a third party approved by both parties acting as escrow in a 2-of-3 multisig transaction deciding if I had in fact completed it successfully. Jeff Garzik has done work along these lines in the past (pybond) and may be able to take on that role.

I'm not revealing the source, since it was a PM, but it was someone who I believe to have a pretty good grasp of the inner workings - better than my own understanding at any rate. It's also someone who is not particularly enthusiastic about this project, so I imagine their price for the work described would be more than we would be willing to pay. I of course invited them to participate in the contest, but I doubt they will.

I suggest we give Tachikoma's method a shot and see what happens. It may be that we have to change our encoding method again if our skeptical friend is right and future bitcoin changes make this method unworkable. Of course, if anybody has a better idea, I'd love to hear it.


dacoinminster
Legendary
*
Offline Offline

Activity: 1232
Merit: 1022


Rational Exuberance


View Profile WWW
September 16, 2013, 04:07:35 PM
 #931

Would it not be a good idea for dacoinminster to create a Testnet Exodus address?  Surely it should be under his control, or that of the oversight board.

I'm totally fine with someone else doing it - it's the sort of thing that if we run into a snag we can always start a new one. If you guys really want me to I can, but the consequences of making a mistake on testnet are pretty small, and possibly the benefits of such a mistake would be worth the trouble - we might learn something valuable that will help keep the funds at the real Exodus Address safer.

dacoinminster
Legendary
*
Offline Offline

Activity: 1232
Merit: 1022


Rational Exuberance


View Profile WWW
September 16, 2013, 04:13:11 PM
 #932

Question, when am I going to receive my 3 BTC tip?

In your PM, you asked me to send it to 1Nou27Zt2k3yTFHw6yePg3A1df2ohCTFFb:

You can send my tip here: 1Nou27Zt2k3yTFHw6yePg3A1df2ohCTFFb

Which I did in this transaction: http://blockchain.info/tx/99160b37b3294eebc83bd8ff44849c813d2e9da986a25fb127b0c5915e799c0a

If you no longer have that address, I'm very sorry! I did post my intention to use that address for you publicly more than once. For instance: https://bitcointalk.org/index.php?topic=265488.msg3132645#msg3132645

dacoinminster
Legendary
*
Offline Offline

Activity: 1232
Merit: 1022


Rational Exuberance


View Profile WWW
September 16, 2013, 04:38:39 PM
 #933

I thought you guys might like to see what some of the candidates for the open board seats at the bitcoin foundation are saying about MasterCoin:

Ben Davenport:
Quote
Hi JR,

In general, I'm supportive of protocols built on top of the blockchain. As I previously stated, I'm a big fan of the BitcoinX colored coin initiative. Anything that follows the rules of the network ought to be fair game. I'm all for projects succeeding or failing on their own merits. That said, I'd really encourage you to listen to Gavin and GMaxwell about not creating unspendable outputs (especially when they've given you an alternate approach). Bloating the UTXO set will impose negative externalities on the entire network. We should ideally figure out how to disincentivize such behavior.

Elizabeth Ploshay:
Quote
JR,

Thank you for reaching out.

To date, Bitcoin serves as the best base for further development of a number of innovative and valuable tools that will benefit the community and movement towards further decentralization. The Bitcoin Foundation should continue to ensure that Bitcoin remains a stable base so that individuals can continue to develop these tools.

While I have reservations about the feasibility of the implementation of MasterCoin in its current form, I appreciate the concept behind MasterCoin. It is important that protocol layers built on top of bitcoin not undermine the basic function of the network.

I encourage the exploration of tools that enhance the Bitcoin ecosystem as there is still value in the marketplace of ideas and the exchange of information and lessons learned from the strengthens and weaknesses of the variety of digital cryptocurrencies growing today will just continue to strengthen Bitcoin.  

Trace Mayer:
Quote
Hi JR,

Yes, I remember you and I have followed your work with great interest. Indeed, a little over a month ago your name popped up when I was reviewing potential talent with some others and I suggested we pass since the work you were doing on MasterCoin was more important and of higher and better use than what we had in mind.

To quite brow-nosing and address your question directly I am a fan of both alt coins and new protocol layers like MasterCoin. I think they both have, along with other tools like OT and Ripple, significant potential to create some incredible innovations in this space and others yet undeveloped in even the most rudimentary way.

For example, I really like the potential of OT and BitMessage for federated exchanges and think MasterCoin could even further enhance the possibilities. Creating scarcity by code has really opened up so many possibilities!

Consequently, my general attitude is pretty aligned with Gavin's that the Bitcoin protocol should remain very stable and only change slowly, incrementally, with backwards compatibility and by supermajority. Thus, Bitcoin can increasingly become a registry/settlement mechanism and be secured, perhaps overly so, with massive amounts of processing power.

Where I differ with him, but only slightly, would be I really like the idea of experimenting with alt-coins and other projects even if that means allocating some resources away from Bitcoin (people should feel free to allocate their time, attention and money where they feel they want to anyway) whether it is decentralized DNS with Namecoin or a decentralized Twitter with Florincoin. And MasterCoin is really just an even more complicated abstraction and application which I think could end up being really cool with multiple great use case scenarios.

Bottom line: I think we have a ton of opportunity to build out all types of useful things for Cipherspace using both alt-coins and additional protocol layers on either Bitcoin or even other alt-coins that may be more specifically suited to accomplish particular tasks.

Meyer "Micky" Malka:
Quote
J.R. -

Thank you for the question.  I am a fan of Mastercoin and have been following its progress.  I applaud your efforts and others involved in the project for pushing the idea forward.

As a general matter, I am of the view that Bitcoin is and can be different things to different people.  To me, it is both an improved form of money AND a disruptive technology.  So I appreciate and support comparing Bitcoin to gold or fiat currency - i.e. pointing out all the ways that Bitcoin is simply better money (i.e. scarcity, durability, fungibility, divisibility, verifiability, portability) - as well as the view of Bitcoin as a protocol for storing and transferring value.  As an investor and someone who has seen the worst of our existing systems of money, the first is very important to me.  As a venture capitalist and an entrepreneur, the second is where I see the enormous potential for what Bitcoin can become.

To get back to your specific question: in my view, cryptocurrencies are here to stay and Bitcoin is the gold standard.  Solidifying Bitcoin's role as the gold standard requires both continuing to strengthen Bitcoin as well as encouraging innovation on top of it.  New layers can make Bitcoin more functional, increase general accessibility and open up additional use cases (e.g. enabling distributed currency exchange, programmable property, et al.)  I see Mastercoin as one of the first and most ambitious efforts to do exactly this, so I am excited at the prospect.  

I believe (as I know many other members of the foundation do) that Bitcoin today is like the Internet in the early 1990s: the fundamental technology is there, but we are still in early days.  Obviously I do not know whether Mastercoin will take hold, but I believe that by supporting people like you and your colleagues, the Bitcoin community can ensure that the protocol spawns an amazing amount of innovation (just like TCP/IP did) .  And I think that the Foundation, by bolstering Bitcoin and addressing market and regulatory challenges facing the protocol, can help pave the way for this innovation.

Thanks again for the question.  Please reach out to me anytime.

Micky

Luke Dashjr also sent me a PM about his candidacy and MasterCoin, but I don't have an official quote from him yet.

Disclaimer: I'm not endorsing anybody. I don't even know who I'm voting for!

dacoinminster
Legendary
*
Offline Offline

Activity: 1232
Merit: 1022


Rational Exuberance


View Profile WWW
September 16, 2013, 05:00:30 PM
 #934

There was a lot of critics about the Mastercoin network, in particular due to the many generated un-prunable transactions that are necessary to transmit the data between Mastercoin users.

I have an idea how to solve this problem, but this would require some changes to the protocol. Basically, instead of sending Bitoins to a data address without known private key (which is the current Mastercoin implementation), data can also be transmitted by sending Bitcoins to addresses that other Bicoin users own. To do so, a 'directory' of addresses has to be generated first. Each address can store a few bytes of data - and by sending tiny amounts of Bitcoins to these addresses, the pieces of data can be connected (similar to the current Mastercoin implementation). In this presented implementation, each address can store about 3 bytes. Therefore, to have enough data for a Mastercoin transaction, about 6 - 12 Bitcoin transactions have to be sent.

However, there is an important advantage in this implementation: Users that 'own' these addresses can later send all their earned Bitcoins to a single address. As a result, the millions of addresses are fully spent, and the whole system becomes prunable.

In contrast, in the current Mastercoin system, all the data addresses will remain with 0.00006 BTC stored and have to be saved in the blockchain forever.


Here's the implementation:

First, a global list of length 58^4 = 11316496 and width = 30 is created, and each cell can contain a Bitcoin-address. Let us index these cells with (n,#). The size of the list is a few GB, which is well managable to keep in lots of copies among all Mastercoin users.

Now to the actual idea: The cells (1,#) must contain addresses with the last four characters being -1111. The cells (2,#) must contain addresses -1112, and so on. Finally, the cells (11316496,#) must contain addresses with the last 4 characters -zzzz.

Now, every Bitcoin user that finds a key pair can publish the corresponding address in this list. To this end, he has to prove that he owns the private key of this address, to prevent people 'scamming' the list. Assumed, he found an address ending with -1113, he publishes it and it will be written into cell (3,1). Now let's assume > 29 other users also find addresses ending with -1113 and publish them. Then, all these addresses are alphabetically ordered and written into cells (3,1), (3,2), ... (3,30). Addresses with index > 30 are discarded. Obviously, with time, it becomes harder and harder to 'win' a cell in the list, because an address with low alphabetical index has to be found to kick out another one.

Since it is attractive for users to 'own' cells in the list, the time will come the list is complete, meaning that every cell has an address written in it. Of course, after completing the list, new addresses with lower index can still be published, and the list will be continuously updated.

Last, how can a string of data be transmitted?
First, the data is converted into base58 and chopped into pieces with length 4. Example: 3HZ28xpWUhq4... -> 3HZ2, 8xpW, Uhq4... The addresses (taken from the global directory) to send bitcoins to must have the following properties:

1.) They have to end with -3HZ2, -8xpW, -Uhq4...
2.) The addresses have to be in alphabetic order: (...-3HZ2) < (...-8xpW) < (...-Uhq4) < ...

Point 2 is important to connect the data pieces in the right order. It should be possible to find such an alphabetic order, since there are 30 different available addresses for each piece of data.


So, what you think... Assumed that Bitcoin miners feel threatened by the current Mastercoin implementation and stop to confirm transactions that have an Exodus recipient, this implementation could be a solution, since it harms the Bitcoin network less.


edit: follow-up here: https://bitcointalk.org/index.php?topic=284178.msg3166749#msg3166749

I believe that something like this would work, and as you say, it wouldn't create unspendable transactions. However, it would take a LOT more bytes to store the same data in the block chain using this method.

As I've said before, I need to get smarter about the internal workings of bitcoin, but I have a lot of confidence that our developers will come up with something which works. Currently they are (if I understand correctly) attempting to use Gavin's suggestion (https://bitcointalk.org/index.php?topic=284178.msg3040840#msg3040840). If that doesn't work, they may try the OP_RETURN method suggested by maaku on the same thread. If that doesn't work, there may be more options which haven't been suggested yet.

Once this is nailed down, I'll be looking forward with great anticipation to see the first try at the distributed exchange using testnet and/or test MasterCoins. Given how dang fast these guys are, we may all be pleasantly surprised with how quickly that comes together Smiley

dacoinminster
Legendary
*
Offline Offline

Activity: 1232
Merit: 1022


Rational Exuberance


View Profile WWW
September 16, 2013, 05:05:57 PM
 #935

Aw crap. I meant to update the spec to change how the sequence numbers worked. Thanks for catching that.
When I was writing the code for MasterCoin Adviser, it occurred to me that it might be easier to parse MasterCoin transactions if the first data packet had the first sequence number, then additional data packets following, and then the reference packet last, with the last sequence number. But I never went back and updated the spec to reflect that change. I made that change because I thought it might help if we ever had transactions with data but no reference address.
Won't that be a problem when the data chunk is bigger than what fits in one address (20 bytes)? I mean, we'll need more than 1 sequence number, besides the reference sequence number. The only solution I see is to number the data addresses decreasingly from n-1 (n is reference sequence, n-1 for the first data address, n-2 for the second data address, etc), which seems untidy.

Anyway, I hope the alternate methods for data storage will make sequence numbers obsolete Smiley


I had intended Test MasterCoins to be used so I didn't have to create a TestNet version at all, but I have no opposition to TestNet implementations if that is helpful, especially if that helps reduce block-chain bloat Smiley
So... let's agree on a testnet address and epoch so that developers can test on the same grounds. Are you all OK with using miKnddGDQfU6rRYpLp2dhRyttnxH1WUo21 as the testnet exodus address (proposed by Tachikoma) and 15-Sept-2014 as the testnet epoch?

Yeah, I was going to do something similar to that untidy method (although I was going to have the lowest sequence number be the first data address), but as you say, it's not clear how the new method of storing our data affects sequence numbers. If we continue to use them, I'll be sure to update the spec so it is correct.

Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
September 16, 2013, 05:22:01 PM
 #936

There are two types of multisig outputs available at the moment that are useful for us.

  • 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):



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 Smiley

First of all, I have to admit that I don't understand the inner working of bitcoin well enough yet to tell you if there is a problem with this method. (I'm working on it!) What you propose sounds reasonable to me, although I did receive this PM from a concerned party which seems to indicate there may be some hidden gotchas:

Quote
https://bitcointalk.org/index.php?topic=265488.msg3164831#msg3164831

I was reading the above post describing efforts to come up with a new Mastercoin tx scheme; there are a lot of issues with the above, in particular misconceptions about how Bitcoin works, as well as missed opportunities to add censorship resistance. In addition there are potential upcoming changes to Bitcoin that could seriously harm your protocol - changes that may end up getting more support than otherwise because they do exactly that.

I'd can create a complete specification taking all these issues into account, including explaining those issues are exactly and what trade-offs (and alternatives) were involved in coming up with the spec. In short I plan to answer the question "How do you implement a blockchain on top of Bitcoin in a robust, low-resource, and censor-proof way?"

If you are interested let me know and we can work out a set of concrete deliverables: specification document, design rational, and (optionally) example code written in Python with python-bitcoinlib implementing the proposed specification. Any contract would be fixed price, no-cure-no-pay, with a third party approved by both parties acting as escrow in a 2-of-3 multisig transaction deciding if I had in fact completed it successfully. Jeff Garzik has done work along these lines in the past (pybond) and may be able to take on that role.

I'm not revealing the source, since it was a PM, but it was someone who I believe to have a pretty good grasp of the inner workings - better than my own understanding at any rate. It's also someone who is not particularly enthusiastic about this project, so I imagine their price for the work described would be more than we would be willing to pay. I of course invited them to participate in the contest, but I doubt they will.

I suggest we give Tachikoma's method a shot and see what happens. It may be that we have to change our encoding method again if our skeptical friend is right and future bitcoin changes make this method unworkable. Of course, if anybody has a better idea, I'd love to hear it.

I'm sorry but this pisses me off beyond believe.

I've been spending a lot of my own free time, which I don't have much off, trying to help out this project. I am mostly trying to do this alone since nobody seems willing/able to give proper technical feedback to my theories. Now finally somebody steps forward who sees that something is wrong with my proposal but he wants to be paid in order to tell us what is wrong with it? Why not just specify what's wrong so we can work around it?

I won't be giving this any more energy if this is the way the community is going to respond to a group effort.

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

Activity: 1232
Merit: 1022


Rational Exuberance


View Profile WWW
September 16, 2013, 05:44:15 PM
 #937


I'm sorry but this pisses me off beyond believe.

I've been spending a lot of my own free time, which I don't have much off, trying to help out this project. I am mostly trying to do this alone since nobody seems willing/able to give proper technical feedback to my theories. Now finally somebody steps forward who sees that something is wrong with my proposal but he wants to be paid in order to tell us what is wrong with it? Why not just specify what's wrong so we can work around it?

I won't be giving this any more energy if this is the way the community is going to respond to a group effort.

Believe me, I know how you feel. This project has forced me to thicken up my skin - people can be very cruel, especially when they are not face-to-face with somebody they are criticizing. I tried not to show it publicly, but I was very discouraged by some of the feedback I got early on.

Let's just ignore it for now. I don't personally see anything wrong with your method, but I figured I'd post the PM in case anybody else knew what he was talking about.

And no, I don't plan on paying to find out whatever this problem is. Hopefully if there is a problem, somebody will recognize it and post it.

You are right that most of us are not able to offer technical feedback, myself included for the time being, and some of those who are able seem to be less than charitable towards us, and/or are opportunistically aiming to extract a bunch of cash from our project funds.

However, there are a bunch of smart people in the bitcoin community, and they aren't all like that. I'll PM some other smart people and see if I can get us some proper feedback.

edit: PMs asking for comments have been sent to Gavin Andresen, Jeff Garzik, Mike Hearn, Gregory Maxwell, Peter Wiulle, Luke Dashjr, Alan Reiner, and maaku.

Can you guys think of anybody else?

Luke-Jr said:
Quote
Ok, I'll take a look when I get a chance. Not sure it'll be this week, but I'll try to squeeze it in if I can Smiley


TomHirsch
Jr. Member
*
Offline Offline

Activity: 41
Merit: 0


View Profile
September 16, 2013, 06:30:41 PM
 #938

I'm sorry but this pisses me off beyond believe.
Believe me, I know how you feel. This project has forced me to thicken up my skin
Chill!  This is VERY explainable.  Some of these guys really know a ton about bitcoin and how it works.  They are all very seriously pissed that Mastercoin - albeit not perfectly elegant - is a damn cool idea that they didn't think about.  Further, and this is the very hard part - now Mastercoin is very well funded.  These guys think they are far above Mastercoin technically and they are furious that they didn't find a way to raise $500,000 to advance their concepts.  Rather than help Mastercoin, they are going to beat it down from every angle - and try to take money away while Mastercoin grows.  Open source projects get F'd everytime by ego. 
Press on.  You don't need them.  You'll find your way clear of these minor obstacles and very soon will be far passed all their pussy fussing.  You don't need their inputs.  Their inputs are corrupt. 

Smiley
Jealousy often means you've got something good going on.
dacoinminster
Legendary
*
Offline Offline

Activity: 1232
Merit: 1022


Rational Exuberance


View Profile WWW
September 16, 2013, 07:04:12 PM
 #939

Chill!  This is VERY explainable.  Some of these guys really know a ton about bitcoin and how it works.  They are all very seriously pissed that Mastercoin - albeit not perfectly elegant - is a damn cool idea that they didn't think about.  Further, and this is the very hard part - now Mastercoin is very well funded.  These guys think they are far above Mastercoin technically and they are furious that they didn't find a way to raise $500,000 to advance their concepts.  Rather than help Mastercoin, they are going to beat it down from every angle - and try to take money away while Mastercoin grows.  Open source projects get F'd everytime by ego. 
Press on.  You don't need them.  You'll find your way clear of these minor obstacles and very soon will be far passed all their pussy fussing.  You don't need their inputs.  Their inputs are corrupt. 

Smiley
Jealousy often means you've got something good going on.

So far we only have one or two people acting this way. I'm hopeful that we'll get some good feedback from friendlier smart people soon Smiley

dacoinminster
Legendary
*
Offline Offline

Activity: 1232
Merit: 1022


Rational Exuberance


View Profile WWW
September 16, 2013, 07:18:49 PM
 #940

Jeff Garzik's reply, from the other thread:

OP_RETURN is the current proposal that people have been using, for adding prune-able data to the blockchain.  Here is an example implementation for relaying such transactions https://github.com/bitcoin/bitcoin/pull/2738 and https://github.com/bitcoin/bitcoin/pull/2791 is the pruning piece.

alt-coins and similar schemes should at a minimum produce pruneable outputs or use inputs + P2SH.  The data remains available via blockchain, just not bloating the precise UTXO space.

CHECKMULTISIG schemes still bloat the UTXO space (unless they are P2SH).

This is another vote for using OP_RETURN. Tachikoma, I'm very interested in what you think about this approach!

edit:

It appears that this change to bitcoin hasn't actually been merged yet. I sent Jeff a follow-up question:

Thank you so much for the reply!

It appears that these changes haven't been merged yet? I'm a little worried about relying on features which haven't been officially approved. What will current bitcoin implementations do with transactions using OP_RETURN - hopefully not reject them?

His reply:

It appears that these changes haven't been merged yet?

The prune-unspendable is very likely to go in, and the general consensus is that OP_RETURN is the lesser of the various other more-bloat-producing solutions for timestamping data into the chain.  We did not want to put in OP_RETURN without having the prune-unspendable change in first.

Quote
I'm a little worried about relying on features which haven't been officially approved. What will current bitcoin implementations do with transactions using OP_RETURN - hopefully not reject them?

Most implementations today will not relay OP_RETURN transactions, meaning they will probably not be confirmed without a little extra legwork and patience.

All implementations will accept OP_RETURN in mined blocks, as it is a normal and supported opcode.

In practice, today, that means sending the transaction with appropriate fee attached to https://en.bitcoin.it/wiki/Free_transaction_relay_policy

After OP_RETURN is upstream, implementations will relay OP_RETURN transactions just like any other "standard" transaction.



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

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