Bitcoin Forum

Do you believe that "Bitcoin" cares about how people use it?
Bitcoin scalability is a definite challenge. We should tackle that challenge as early as possible, instead of nicely asking people to only use it in specific ways.

Willet is open to discuss better, more efficient ways to encode Mastercoin transactions into the blockchain.

gmaxwell, do you belong to the school of thinking that categorizes SatoshiDice as spam?

instead of nicely asking people

Do you believe that "Bitcoin" cares about how people use it?

Willet is open to discuss better, more efficient ways to encode Mastercoin transactions into the blockchain.

How we solve THAT problem?

Unfortunately not everybody will be willing to use the Bitcoin blockchain as we/the devs would like. If someone creates something that bloats the UTXO set, they might just do not care about what the devs think about it.

How we solve THAT problem?

How we solve THAT problem?

Given Mastercoin is an additional layer of functionality that sits on top of Bitcoin, it therefore needs Bitcoin to succeed and as such it would make no sense to make design choices that negatively impact Bitcoin.

Shame to see the hostility (I've always found collaborating to be much more rewarding) but I'm sure with the quarter million plus $ raised the project will be able to engage the right minds to find the best implementation.

@dacoinminster, if you're still intending to give me those 3 BTC for pointing out that problem with your proposal, could you please send them to 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB

@gmaxwell, thanks for your efforts.

Frankly, I don't know how hard this will be yet. I believe Gavin when he says there are multiple ways to do it, but I don't know what all of them are or which way is best.

I do plan to use bounty money to encourage innovation in this area early on.

The most important thing to me is not to be dependent on the charity and goodwill of people running the higher protocol layer. They are great people, but I don't want to give them a lever to turn off MasterCoin, however well-intentioned they may be.

Frankly, I don't know how hard this will be yet.

I believe no more than a couple of days of work, if you know what are you doing. Likely less than that for a person who is very familiar with the client codebase, data structures etc.

So, yes, it makes sense to do this from the start.

JR, put OP_RETURN in front of the data script. That can't take more than a few seconds to change, and a few minutes to communicate. You may even be able to use dust/empty outputs in this case (you should, but not sure if the client supports it yet).

I think you are assuming that we have code which directly sends MasterCoin transactions, which we do not. Sends are currently accomplished using standard unmodified bitcoin clients (bitcoin-qt, blockchain.info, etc)

Given how much money you've raised it'd be quite easy to pay someone to add support for OP_RETURN to those clients, among other things.

Hey Peter! Thanks for checking out the project! (Peter and I met at the conference in San Jose, and had some interesting discussions there, and he is a tireless advocate for keeping bitcoin awesome, as you can see from his sig)

I completely agree. We seem to have a rather formidable war-chest :)

Being a good block-chain citizen is a matter of survival for MasterCoin. If we don't, we'll face competition from a clone that says "We're like MasterCoin, but with less impact on the blockchain"

With any luck you'll face competition from clones that realize the entire idea is just dumb. Are you planning to release the sourcecode to MasterCoin? Because if you don't, we'll all just say how it's probably got hidden backdoors that are going to steal all your (master)coins, and if you do release it, we can just take that code and remove the silly requirement for the exodus address/MasterCoins. Or just stick with, who was it, TierNolan and co's colored coins stuff?

Also, even if you want to use the colored coins paradigm, you actually don't need any data in the blockchain at all beyond what appear to be bog-standard pubkeys. Even better, is that you can design your protocol to really make it censorproof by allowing the colored coins to be included in standard CoinJoin transactions in such a way that anyone looking at the blockchain data will have no way of knowing what outputs were the colored coins.

Frankly the only clever thing you've done is you've taken the same colored coins/side-chains ideas everyone else has and found a way to get Bitcoin users to shovel money at you for it. Too bad really - I guess the rest of us couldn't imagine how you didn't even need to write any code to separate $300k worth of Bitcoins from the idiots who used to own them. (We forgot about The Pirate already!) Hopefully that's not actually true, and it's actually your own money and not many people are getting scammed here.

Anyway, I have better things to do than waste my time talking about ideas sufficiently stupid to be indistinguishable from scams for free, so don't bother replying unless you've got a paying contract. (1.5BTC/hr, escrow required for you)

I will say though, you're so close to doing something useful for me: showing the world how little protection we actually have against the UTXO set being bloated other than the blocksize limit. Do me a favor and keep your stupid protocol just the way it is.

With any luck you'll face competition from clones that realize the entire idea is just dumb. Are you planning to release the sourcecode to MasterCoin? Because if you don't, we'll all just say how it's probably got hidden backdoors that are going to steal all your (master)coins, and if you do release it, we can just take that code and remove the silly requirement for the exodus address/MasterCoins.

Or just stick with, who was it, TierNolan and co's colored coins stuff?

Also, even if you want to use the colored coins paradigm, you actually don't need any data in the blockchain at all beyond what appear to be bog-standard pubkeys.

Even better, is that you can design your protocol to really make it censorproof by allowing the colored coins to be included in standard CoinJoin transactions in such a way that anyone looking at the blockchain data will have no way of knowing what outputs were the colored coins.

Thanks for saying what many are thinking. Even if it isn't a scam, the system simply can't work. It shows complete lack of understanding about how markets and asset pricing actually work. Gold assets not backed by gold, but by MasterCoins (which will clearly appreciate faster than dumb old gold)... It's so obvious... Why didn't the people who started GLD think of that?  They'd be so much richer!

As a full blockchain node operator I really want to see some kind of solution to the blockchain bloat problem, preferably with some fees so I can turn this into a business rather than a non-profit. Miners verify transactions and get compensation for it, but nobody pays for the transaction's storage once it gets verified and this will eventually shrink full-nodes numbers and further strengthen the oligopoly of Bitcoin miners.

The advantage of storage is that you can verify more transactions.  However, that is not much good if other miners drop your block because they dropped the UTXO.

If you have 1 MB block size limit and each input is approximately 250 bytes, you only have at most 4000 inputs per block.

As for inputs in transactions not included in blocks, you can just drop ones you cannot fetch in a reasonable time. There is nothing wrong with dropping transactions.

Well, the size limit (at least the 1MB version) is not likely to last indefinitely.

However, it does reduce the overall performance of the system.
If it is harder to spend "old" transaction outputs, then that weakens the ability of the system to act as a long term store of value.

/sigh @ how many times supposedly intelligent people have thrown around the term 'scam' in this thread - get over yourselves.

Criticize the design to your hearts content, healthy debate is fine but don't go after a guy who has simply solicited investment for an idea - his personal identity is well known (I understand some of you have met him) and he has done nothing to warrant calling scam.

I wonder how economic development would have progressed historically if everyone thought onboarding investors was such a tangible evil.

Maybe this has already been addressed I am not sure, what if we could prove that a output in the blockchain is unspendable (a transaction to a valid but unusable address) if we know for certain that the coin is unspendable could they not be removed in the future when we start compressing the blockchain?

It would make sense that coins that can not move and this is known to be true are simply removed and those addresses removed too. Because they are no longer spendable Bitcoins. You could even claim these coins after they have sat in their addresses for x amount of time and move them as tx fees into the next block to be mined.

Of course this can only be done for addresses that are proven to have no possible private key access.

There are plenty of ways to accomplish that, the easiest of which that works today would be to stuff data into unused public keys of an OP_CHECKMULTISIG transaction.

I'm totally cool with stuffing the data in alternate places once we have our own client. I see using unspendable transactions as a "crutch" so that the protocol works until we get to that point. For instance, right now none of the existing bitcoin clients has functionality that will let an average user hide data in OP_CHECKMULTISIG.

It is inevitable that in the future, bit coin does prevent the permanent storage of arbitrary data in the blockchain. If you rely on such features now, there could be colossal consequences later. #bitcoin wont care about you or your bitcoin-bloat. BE WARE, YOU HAVE BEEN WARNED.

MasterCoin hopes to be symbiotic with bitcoin, not parasitic, and we plan to morph and change to whatever degree is needed as bitcoin morphs and changes. If our old data gets pruned out of the block-chain used by most bitcoin clients, our clients will have to be modified to keep different parts of the block chain, and use different pruning techniques. Nothing I can foresee leaves MasterCoin completely stranded or unusable.

I won't be surprised. Parasites always morph and change as the host evolves.

Yes, that's something like what I have in mind, although long-term, we hope to be mitochondria, not tape worms :)

Willet, what I really don't understand about you is that CLEARLY, a separate block-chain would be best for your project, but you are just ADAMANT, just for the sake of it, to use the bitcoin blockchain. Why on earth is that? To be honest, the BEST way would be to do what Namecoin does, merged mining. It's the perfect solution. Why don't you want to do it? "Just because you are attached to Bitcoin". it's a stupid reasoning.

Assumptions

Our claims are built on the following assumptions:

•   Alternate block chains compete with bitcoins financially, confuse our message to the world, and dilute our efforts. These barriers interfere with the adoption momentum of bitcoin and the adoption momentum of alternate currencies as well, regardless of how well-conceived their rules may be.
•   New protocol layers on top of the bitcoin protocol will increase bitcoin values, consolidate our message to the world, and concentrate our efforts, while still allowing individuals and groups to issue new currencies with experimental new rules. The success of any experimental currency protocol layer will enhance the value and success of the foundational bitcoin protocol.
•   Getting consensus and widespread adoption from the bitcoin community is not needed to add protocol layers, since no changes to the foundational bitcoin protocol are required.
•   Tiny bitcoin transactions can be encoded into the block chain to support and represent transactions in higher protocol layers.
•   A protocol can pay for its own software development, “bootstrapping” itself into existence, utilizing a trusted entity to hold funds and hire developers.
•   It is possible to create tools to allow end users to create currency protocol layers which have a stable value, pegged to an external currency or commodity. In this way, users of these currencies can own stabilized virtual currency tied to U.S. Dollars, Euros, ounces of gold, barrels of oil, etc.
•   It is possible for users of these new currencies to exchange between currencies with each other using simple rules and no central exchange.

One reason I didn't mention in the paper is that this method of accomplishing my goals is way, way easier and faster than building an alt coin. Building on bitcoin significantly reduces the technical risk of my project.

Not doing something like merged mining which relies on 100% Bitcoin is the biggest risk. The days of bitcoin bloatware are numbered. Your funeral, and the funeral of all the poor suckers who gave you money already when it finally happens. You're probably safe until Bitcoin 0.9, but by 1.0, it'll be game over.

I expect MasterCoin will have to change and implement it's own custom pruning solution at some point, but I'm not expecting any funerals :)

Your arrogance can only be compared to corporate slime who adapt their tax-evasion with the passing of every new law, and gloat about it.

I have a proposal for alternative Mastercoin encoding ready and I wanted to discuss the feasibility of my solution. We are going to use a OP_CHECKMULTISIG script with three (or more) public keys to encode the data.

Because we will be using public keys to encapsulate the data we now have 64 bytes to encode data (65 minus one byte for the 04 marker). In order to not polute the blockchain we will always supply a publickey that the sender owns as first signature this way the output can always be redeemed. The other signatures we supply will be data-addresses; these transactions won't be able to be converted to addresses since they are not technically ECDSA x/y coordinates but they should be relayed and mined just fine.

I've created a test transaction on testnet3 (http://test.webbtc.com/tx/4bbef8adce4009bf8e24ec90f652f78c5ed2f5863414362ad551f3f78f969d9e.json) (raw (http://test.webbtc.com/tx/4bbef8adce4009bf8e24ec90f652f78c5ed2f5863414362ad551f3f78f969d9e.json)) to test this functionality.

miKnddGDQfU6rRYpLp2dhRyttnxH1WUo21 is the exodus that I use on Testnet. I'm sending the coins to myself (miDyBpL3TeeJRbtwdFUsw9mUWUEhN6FyXf) in this example so I send both the change amount and 0.00006 transaction to this address. I also use this address as the first signature for the multisg output so I can redeem this later. If you check the raw transaction you will see that there are two more keys supplied. If you decode these using the encoding standard from the whitepaper (but instead pad with zeros until you have 65 bytes) you will see that I'm doing two transaction for 1 test Mastercoin each.

In theory you could do multiple Mastercoin transactions in one multisig output but I would like to propose to keep it simple and only one transaction per output. If you want to send multiple Mastercoin transactions in one Bitcoin transaction you can create multiple multisig outputs.

Since all current ideas of the whitepaper fit within 126 bytes (2 signatures) and signatures are in fixed order we might not need to add sequences to all signatures but for now let's continue doing it.

I know there are a lot of users with more knowledge of Bitcoin lurking so please let me know if this approach would work within the rules set out by the reference implementation. I'm especially interested in if we can use 1 out of 5 multisig transactions. I tried to make one; and it relayed; but I'm not sure it's actually a valid transaction type.

Please let me know your thoughts so we can continue building cool things on top of Mastercoin :)

It just happens that I'm the first one to actually take a crack at it.

I have better things to do with my time than to provide free consulting for altcoins who've just raised hundreds of thousands of dollars

don't non-consensually consume the resources of people who are disinterested— even opposed— to your system...

...the entire idea is just dumb.

Anyway, I have better things to do than waste my time talking about ideas sufficiently stupid to be indistinguishable from scams for free, so don't bother replying unless you've got a paying contract. (1.5BTC/hr, escrow required for you)

Do me a favor and keep your stupid protocol just the way it is.

GMaxwell, I hope you enjoy your 3 BTC I sent you, courtesy of d'aniel.

$450 to a dick?  We need to save the funds better than this.  I hope his contribution was valuable.  Just because the projects wallet is fat, doesn't mean you have to throw the money around unnecessarily.

Did you know that people consume about 20% more shampoo when their shampoo bottle is full?  No need sending BTC to dicks unless their help was a good improvement for the project.

Where can I find some more background reading about these topics: utxos and pruning, etc.

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.

Seems like what I wrote in the main mastercoin discussion thread fits better into this thread:

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

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

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?

There have been several well known bitcoiners that tried to convince J.R.Willet to move Mastercoin to an altchain, instead of using the bitcoin blockchain. Willet's opinion is that Mastercoin should stay on the blockchain, and I fully concur. Here is my reasoning:

It is easier to implement Mastercoin on the blockchain. The entire concept of mining "vanishes", or actually is satisfied by Bitcoin miners. This means the security of Mastercoin is on par with Bitcoin (up to potential bugs) ... there is no way to 51% attack it.

The same could be implemented using merged mining, but no matter how you look at it, merged mining is technically a more complicated solution, because it requires an entirely new blockchain one needs to reason about. You need to think about the hashrate of this separate blockchain and to encourage miners to merge-mine it, things that are just not needed when you directly encode things into the Bitcoin blockchain. As far as software development goes, I'm super lazy - I do not like to do something complicated if I can do something simple that serves the same purpose.

Now, it is true that this "burdens" the blockchain ... in the same way that Satoshi Dice does.
However, this burdening is something that Bitcoin users and developers will just have to live with. Nobody is the boss of Bitcoin, and any standard Bitcoin transaction (like Mastercoin transactions are) are legitimate transactions that Bitcoin simply has to learn to deal with. There is just no feasible way that I see that Bitcoin developers could ban such transactions (please enlighten me if I'm wrong).

Bitcoin is the future of finance, resistant to hacking, government censorship and regulation. Do you really want to base that future on asking other people to pretty please "not abuse it for you own purposes"? This is not the answer. Bitcoin has to be made scalable enough to meet its role as the one major, global, world currency.

Mastercoin developers have no intention of disrupting Bitcoin, and will gladly adapt to any friendly encoding that the brilliant minds of these forums will propose (https://bitcointalk.org/index.php?topic=284178.0), as long as it doesn't harm Mastercoin (using non-standard transactions that are relayed more slowly is not an option at the moment). The Bitcoin blockchain must and will remain neutral, and if Willet hadn't come up with Mastercoin encoding, someone else would have created something similar sooner or later.