I really appreciate the answer. I am happy that even though you are probably not a big supporter of Mastercoin you still take the time to answer a question that is in essence a Bitcoin question.

Before deciding on a spec I think we should exhaust every option presented to us. I will see if I can find a way of doing it via P2SH if that really is the best way to prevent any type of bloat. If that is indeed not possible I suggest we switch to multisig encryption until OP_RETURN becomes available at what time we can switch back to using address encoded data.     

A topic you are watching has been split into two or more topics by grue.

View what remains of this topic at: https://bitcointalk.org/index.php?topic=287145.new;topicseen#new

Unsubscribe to this topic by clicking here: https://bitcointalk.org/index.php?action=notify;topic=287145.0

J.R. - I don't think you have a good read on these people.  They are all going to be fairly compensated.  Their compensation comes in producing fine results on a very interesting project.  Probably very few people are in this for the money.  

Don't spend another second being 'so sad that...' - your efforts to keep the project healthy and going down a good path are all they need as compensation to work hard.  Your organization of the project assures their efforts are not wasted.  It is a perfect synergy.  Forget about $$$, BTC, or MSC.  Building something cool is far more rewarding than having a pocket full of money.
However, hot chicks tend not to agree with that I suspect.

The way I understand it is that the UTXO space can only bloat when an output is not-redeemable. Since the suggest multisig implementation uses a real/existing publickey it can always be redeemed. This holds true as long as my understanding of multisig outputs is correct. Since people are still worried about bloat I can only come to the conclusion that my understanding is wrong.

Question 1:
Having a valid public key in a 1-3 multisig is not enough to redeem said output and thus prevent UTXO bloat?


What I (think) to know about OP_RETURN is that it basically creates an unspendable output but at least we know it's unspendable. This is basically a way to destroy coins. Is this correct? And if so is this preferable to having increased UTXO space (if I indeed misunderstand spending multisigs).

Sorry - I'm just trying to manage expectations. If silicon-valley programmers join the effort thinking of it as a job motivated by money alone, they will be disappointed, and I'm trying to avoid that.

I thought I should make a post and detail what I'm working on

I'm currently attempting a build of a web wallet and block explorer - 'Masterchest'.  Some notes:

* Ground-up build (though bitcoind still used to return raw tx info over JSON-RPC)
* Hosted at masterchest.info
* Everything will be open sourced - I think this is in the best interests of a web wallet so the community can peer review for weaknesses etc
* The web wallet has simplicity in mind and will only manage MSC, not MSC & BTC.  This lowers risk and complexity.  You'll instead be able to simply buy 'transactions' (eg 20 for 0.01BTC - whatever it works out to be - I'll fund first 5 transactions myself for all users).  This allows the system to simply hold a count of each users available transactions rather than attempt to handle bitcoin funds too.
* Tools to lookup addresses and transactions (block explorer)
* Initial support will be simple send only
* There will definitely be restrictions on how many MSC you can store (probably <100MSC per account), especially during development

I have a family and a full-time job so time is already a luxury for me! but I bought some Mastercoins and I'd like to contribute to the project - doing my best to find time to work on this!  If by some miracle I complete all the functions I'll happily jump in to try and get my head around the storage issue to contribute, though I think brighter minds than mine are already hard at work on this.

At present I'm in the middle of finishing the parsing engine (decoding the raw transactions where Exodus is an output and warehousing them in a format that facilitates easy data retrieval) - I have a semi-working implementation but I'm not willing to open it up just yet. I'll post updates here as I (hopefully) progress.  

Edit: Pictures help so quick teaser screenshot

Wow, it's becoming harder and harder to stay up to date with Mastercoin.
First off, Tachikoma thank you for all your work. You've contributed far more than anyone else to Mastercoin. I'm sad to hear you are demotivated by the way some community members react.


Back to the new data method proposal: I can't see any error in the details of what you said. That transaction does contain the data, and the bitcoins are redeemable via the actual public key. Nevertheless, the mysterious PM dacoinminister cited got me thinking more broadly about the method. I think there might be a more general  problem in the concept of storing data in the blockchain using multisig txs. For mastercoin to work we need mastercoin transactions to be stored in a decentralized, permanent way (like bitcoin transactions are). Using multisig transactions and then taking the bitcoin away with the other key may cause the transaction to be pruned from the blockchain by future bitcoin clients (why would you need to store transactions which have all its outputs spent?). In fact, the same should happen with ANY method which doesn't bloat the UTXO. If a transaction can be pruned for whatever reason (multisig, op_return), it means bitcoin clients could potentially delete that transaction, thus deleting mastercoin data?

Clearly my technical knowledge of the bitcoin protocol is below most of the people reading/writing here, so I'm sorry if what I'm saying is stupid.

CHECKMULTISIG works right now (as far as I know), and arguments against it are largely theoretical: it does bloat UTXO space, but currently it isn't a limiting factor.

It is important that CHECKMULTISIG doesn't do permanent damage, unlike your current approach which does permanent damage.

So my advice would be:

1. switch to CHECKMULTISIG ASAP
2. make it possible to use OP_RETURN approach

That is, you can write code to parse both CHECKMULTISIG and OP_RETURN, and test in on the testnet.

Code which creates transactions will use only CHECKMULTISIG now.

If at some point OP_RETURN will be viable, a new version of client can start using it: and old versions will be able to recognize such transactions too.

Now as CHECKMULTISIG adds more bloat to UTXO space, developers have an incentive to approve OP_RETURN.

I think everybody can agree that CHECKMULTISIG is definitely better than what you're doing now, so there are no reasons not to upgrade. (I mean, aside from desire to piggyback on existing clients.) Use of OP_RETURN is a separate issue.

Passive-aggressive strategy like you mentioned can work too, but it will create some junk in process, and, sadly, that junk will stay in UTXO set forever, which is kinda sad.

Yeah, it's between that and using OP_RETURN (opcode which may soon be supported), though most of the bitcoin core devs seem to favor OP_RETURN.

I completely understand busy - let me know if you have an opinion I can add to the mix

Thanks!

Thanks for your reply!

Making another alt-coin isn't really interesting to me, merged-mined or not. Frankly, I wouldn't have raised much money at all if I were trying to make another alt coin. I'm very committed to making a new protocol layer on top of bitcoin, but I want to do it in the most friendly way possible

Thanks Mike. I definitely understand your concerns, and I partially agree with your reasoning (partially, because I don't expect I would have any trouble making an alt chain, if my interests were in that direction). I can understand your frustration with wanting to have more features in bitcoin, balanced against the fear that people will abuse them.

I appreciate that it would be better for you (and perhaps lots of other people) if I stopped what I am doing and approached the matter from a different angle. However, I think it's much more constructive to recognize that people are going to try to do things like this, and try to minimize the impact on the block chain. Even if I did exactly as you suggest, someone else would try it, possibly even someone more foolish than myself, if you can imagine that

I understand that my approach may result in changes to bitcoin which might not be favorable to my project, but I spent quite a bit of time contemplating how to make sure my transactions didn't get banned from bitcoin, and I don't plan on relying on any mechanism that would allow that. Frankly, I simply can't conceive of anything that would shut MasterCoin out of the block chain permanently. Perhaps I just lack imagination.

You can predict my future actions with perfect accuracy if you simply assume that "J.R. will do what he thinks is best for the owners of MasterCoins", which of course includes myself. If I thought that a complete reboot of my project was in the best interests of my investors, I would do it in a heartbeat. Any argument attempting to get me to change direction must appeal to that motivation, not my compassion for whatever projects of yours that my project may be hindering, or my concern for the bitcoin economy in general, or . . . anything else at all. If it's not in the best interest of my investors, I won't do it. Period.

I really do appreciate your feedback though, and I highly respect your views on this matter. One thing that is in the interest of my investors is to make our project as bitcoin-friendly as possible, since if we don't, someone else will gain a competitive advantage over us by being better block-chain citizens.

Perhaps the end result will be that someone will create an alt-coin using merged mining which is more in line with what you would like to see, and that coin will win out by its inherent superiority. Perhaps you yourself might create it? If so, I sincerely wish you luck - I might even buy some!

-J.R.

The tiny outputs which reference the exodus address are not intended as a way to raise money, but merely as a convenience for finding our data in the block chain. We could switch to a different reference address at any time if for some reason bitcoin clients started looking for that address.

I think that's exactly the direction we are heading (using OP_RETURN once it becomes possible to do so). I DO want to minimize the toxic waste being dumped in the river, and thankfully I believe it is in the best interests of my investors to do so

I personally think that the river-polluting example is a pretty strong argument against an-cap world-views, but that is a different conversation  . . .

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

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

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?

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.


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.

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. 


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

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.

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

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

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


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?

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

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.

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.  

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.

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

OK, I guess I'll start posting more frequently then! I'm building a desktop mastercoin client. It currently requires a bitcoin-qt client running on the same machine to operate, because it uses the bitcoin-RPC server to broadcast transactions.

The code is here: https://github.com/maraoz/pymastercoin
and I'll post any updates here. Technical discussion will remain on the Mastercoin original thread.


Right now I'm working on data storage methods, because it seems like we should first define that and then build over it. I'm looking to create a simple GUI for a PC wallet. The goal is to be able to see the current Mastercoin balance for your bitcoin addresses and create simplesend transactions. I'm also looking to update the client to support advanced features when they become specified and reviewed.

I think the project will be useful because it'll allow desktop users (who normally don't want to trust web wallets) to fully use Mastercoin on their own machines.
Cheers!