maraoz



Offline



Activity: 56

Merit: 0









NewbieActivity: 56Merit: 0 Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 16, 2013, 12:18:08 AM #923 Quote from: dacoinminster on September 10, 2013, 02:58:44 PM 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





Quote from: dacoinminster on September 10, 2013, 02:58:44 PM

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 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 obsoleteSo... 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?

Tachikoma



Offline



Activity: 938

Merit: 1000









Hero MemberActivity: 938Merit: 1000 Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 16, 2013, 08:54:39 AM #927



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

Ola



Offline



Activity: 311

Merit: 250







Sr. MemberActivity: 311Merit: 250 Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 16, 2013, 10:39:14 AM #928 Quote from: Tachikoma on September 14, 2013, 08:56:06 AM

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;

}





It seems that maximum is m-of-20 in the current code base (where m<=20):Fount the answer in the bitcoind code.

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











Quote from: dacoinminster on September 14, 2013, 08:56:06 AM

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.





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



Offline



Activity: 30

Merit: 0







NewbieActivity: 30Merit: 0 Re: OFFICIAL LAUNCH: New Protocol Layer Starting From “The Exodus Address” September 16, 2013, 02:44:17 PM

Last edit: September 16, 2013, 03:32:37 PM by milkyman #929



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



Offline



Activity: 1260

Merit: 1024





Rational Exuberance







LegendaryActivity: 1260Merit: 1024Rational Exuberance Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 16, 2013, 04:02:37 PM #930 Quote from: Tachikoma on September 16, 2013, 08:54:39 AM



1-out-of-3

1-out-of-2

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



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



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



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



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



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



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







A complete tx could look something like this:



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

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

"out":[

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

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

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



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

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

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 ( 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.



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: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.

Check out my attempt at

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

dacoinminster



Offline



Activity: 1260

Merit: 1024





Rational Exuberance







LegendaryActivity: 1260Merit: 1024Rational Exuberance Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 16, 2013, 04:38:39 PM #933



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! 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:Elizabeth Ploshay:Trace Mayer:Meyer "Micky" Malka: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!

Check out my attempt at

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

dacoinminster



Offline



Activity: 1260

Merit: 1024





Rational Exuberance







LegendaryActivity: 1260Merit: 1024Rational Exuberance Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 16, 2013, 05:00:30 PM #934 Quote from: milkyman on September 16, 2013, 02:44:17 PM



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:

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 (



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

Check out my attempt at

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

Tachikoma



Offline



Activity: 938

Merit: 1000









Hero MemberActivity: 938Merit: 1000 Re: OFFICIAL LAUNCH: New Protocol Layer Starting From The Exodus Address September 16, 2013, 05:22:01 PM #936 Quote from: dacoinminster on September 16, 2013, 04:02:37 PM Quote from: Tachikoma on September 16, 2013, 08:54:39 AM



1-out-of-3

1-out-of-2

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



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



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



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



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



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



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







A complete tx could look something like this:



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

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

"out":[

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

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

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



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

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

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 ( 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.

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: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. 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



Offline



Activity: 1260

Merit: 1024





Rational Exuberance







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

Last edit: September 16, 2013, 07:37:03 PM by dacoinminster #937 Quote from: Tachikoma on September 16, 2013, 05:22:01 PM

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

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 whoable 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.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:

Check out my attempt at

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