Would it not be a good idea for dacoinminster to create a Testnet Exodus address? Surely it should be under his control, or that of the oversight board.
I'm totally fine with someone else doing it - it's the sort of thing that if we run into a snag we can always start a new one. If you guys really want me to I can, but the consequences of making a mistake on testnet are pretty small, and possibly the benefits of such a mistake would be worth the trouble - we might learn something valuable that will help keep the funds at the real Exodus Address safer. |
|
|
|
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. 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: {"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  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: https://bitcointalk.org/index.php?topic=265488.msg3164831#msg3164831I 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. |
|
|
|
Ok. So who determines the outcome of the wager? If it is the layer, what stops them not paying out?
Everyone parsing Mastercoin recognizes the winner as the new owner of the coins. There is no action required to pay out - everyone knows who won, and only the winner can validly spend those coins. |
|
|
|
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. d'aniel earned a bounty very early on for describing a potential attack vector on underfunded escrows. His contribution was very valuable, and led to some changes in the most recent rev of the spec. The fact that he is a detractor doesn't diminish his contribution. d'aniel asked me to send his bounty to GMaxwell, so I did. That bounty was approved by the MasterCoin Foundation board (which was two people, not including myself, at that time). If we do everything we can to be good block-chain citizens, and if the protocol is successful, some detractors will eventually become advocates. People here can be very passionate and opinionated, but most of them can also be swayed by sound arguments, especially if the argument is in the form of code which is proving useful to lots of people and making bitcoin more valuable. |
|
|
|
Peter is a nice guy in person. He's also very passionate about the health of the bitcoin network - more than anybody I know. In retrospect, maybe I shouldn't have expected a continuation of the friendly dialog we started at the conference, given MasterCoin's potential to rapidly expand the block chain (even more than it already is expanding). That's probably a sensitive issue. Also, while I doubt anybody stole his coins, he may have just been having a really bad day. I try to give people a little grace and understanding in situations like this. GMaxwell, I think I remember when tonal bitcoin came out. Gosh, that seems like a long time ago. I should probably just claim to be the first to create a new protocol layer that actually adds new functionality (as opposed to an alternate display)? Also, I hope you enjoy your 3 BTC I sent you, courtesy of d'aniel. I believe I have actually sent more money to detractors than boosters at this point! That should change soon |
|
|
|
People concerned about MasterCoin bloating the bitcoin block-chain will be pleased to hear that we now have proof-of-concept for at least one alternate way of storing our data without creating unspendable outputs: 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 ( raw) 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 |
|
|
|
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 guess if my choices are between building yet another alt chain and "arrogance", I choose arrogance. The possibility of building a new protocol layer on top of bitcoin has always been there, and someone was bound to do it sooner or later. It just happens that I'm the first one to actually take a crack at it. |
|
|
|
It's helpful to try to imagine the uphill battle a clone would face. Who would launch it? The number of people who have the reputation to launch something like this isn't huge. Would anybody take them seriously? If you were an investor, would you send money to a cloned project with it's own Exodus Address? Well, without meaning to be rude, they sent money to you, didn't they? Yes, but I mean to point out that not many people would have sent me money if I was blatantly copying something that already existed. I think most of the money was raised because people recognized that this project is breaking new ground. That said, a really compelling competitor is pretty high on the list of things that could go wrong. Our best bet is to keep up the current breakneck speed |
|
|
|
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 |
|
|
|
Note that in the MasterCoin project thread Tachicoma said he tested this code and verified that it agrees 100% with his own parsing code. Great job! |
|
|
|
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.
I describe my reasoning for this in the "Assumptions" section of my whitepaper (see the link in my sig): 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. |
|
|
|
Here's an email I got from somebody worried about MasterCoin clones: On Thu, Sep 12, 2013 at 4:28 PM, John ----- wrote:
Hi JR,
I just listened to your talk with the bitangles and am concerned with your current protection against being "forked", which is probably the wrong word choice, but provides a nice pun for what could happen with the introduction of alt-MasterCoins.
Bitcoin would not have the same first mover advantage if an alt-coin was created two months after Bitcoin. The moment someone sees any value to Mastercoin, then they will either consider buying Mastercoin on the open market, or copy the source code and create their own Exodus address.
Thoughts???
John ----- MasterCoin is vulnerable to clones, although the problem fades as the MasterCoin project continues to gain momentum. It's helpful to try to imagine the uphill battle a clone would face. Who would launch it? The number of people who have the reputation to launch something like this isn't huge. Would anybody take them seriously? If you were an investor, would you send money to a cloned project with it's own Exodus Address? A clone would have to offer some MAJOR innovations, and they would have to move very fast. In all likelihood, we would blatantly steal any innovations we saw in somebody else's clone, which I have said multiple times, in an attempt to discourage people from trying it |
|
|
|
Does the spec enforce that the seller actually has the coins they are offering to sell?
If not, any malicious actor can poison the market by repeatedly making offers they have no intent to fullfill, causing potential buyers to repeatedly lose transaction fees as they attempt to purchase.
This all seems pretty unattractive compared to existing exchanges like Cryptsy, where ownership of the coins is enforced, and fees are only charged on completed transactions.
Yeah, anybody parsing MasterCoin transactions would not display sell orders from people who don't own the coins. And of course, we don't have this problem with the distributed exchange between MasterCoin and its child currencies. The burden of these fees falls on the buyer, who is using bitcoins which are not subject to MasterCoin rules. |
|
|
|
I'm not sure how this resolves the issue of having to refund a payment if all transactions happen in the same block.
Well, the buyer is supposed to wait until they are confirmed as the first to broadcast the intention to buy those coins. If they send payment too soon, then yes, they would lose their money unless the seller decided to be nice. From your earlier message: Buying MasterCoins with bitcoins on the distributed exchange is actually a two-step process:
1) Signal your intent to buy, paying a transaction fee specified by the seller to prove you are serious
2) If you are recorded in the block chain as the first one to signal your intent to buy, THEN you send payment within the specified time window of your signal Now you have to refund the transaction fees, if two or more people bid. You haven't solved the problem, simply shifted it to the original transaction fee, rather than the full amount. Unless the seller gets to keep all the transaction fees? Sorry - I think we both posted at the same time. See my message right before yours Fees currently go to the bitcoin miner, and are not recoverable under the current spec. |
|
|
|
I'm not sure how this resolves the issue of having to refund a payment if all transactions happen in the same block.
Well, the buyer is supposed to wait until they are confirmed as the first to broadcast the intention to buy those coins. If they send payment too soon, then yes, they would lose their money unless the seller decided to be nice. The problem now becomes how to refund the initial transaction fee of the failed bids.
You haven't removed the problem, you've just made the amounts concerned smaller.
And you have doubled the bitcoin transaction fees you need to pay.
And every Mastercoin transaction has to pay a small amount to you (the Exodus address) for the privilege?
So each transfer has to pay Bitcoin fees*2 plus a small Exodus fee?
(Actually Bitcoin fees*3 , as the seller presumably needs another transaction to actually move the Mastercoins.)
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 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. |
|
|
|
Here's a PM I got this morning with some questions: Hi JR, Great job on mastercoin and thanks for the 10 mastercoin reward for my efforts in giveaway thread. I am Red from China and working as translaton currently in a JV. Caught the btc virus in April!  As the mods of investment subforums in several leading btc forums in China, I feel obliged to pass the information out about the progress of mastercoin so I translated the encoding contest into chinese and posted in the my weibo, blogs and forums: http://www.btcpie.com/blog_2013/09/http://8btc.com/forum.php?mod=viewthread&tid=781&page=1#pid1457http://blog.sina.com.cn/s/blog_d3b90b760101cflx.htmlFrom the response I got, few people really understand what mastercoin is and its capability, including me. I got some questions: 1. what is the difference between test mastercoin and regular mastercoin? 2. what if we couldn't find a new way to store mastercoin transaction data? 3. The total amount of mastercoin will be around 500k? Cheers, Red Hey Red, Great questions. I've posted your questions here so that everyone can see the responses: 1. Test MasterCoins and regular MasterCoins have identical capability, but Test MasterCoins are intended to be used for testing new features before people use them with real MasterCoins 2. I am very confident at this point that we will find a better way. If we couldn't find a way, we could keep using the current method (and the bitcoin core devs would probably hire someone to kill me) 3. The total amount purchased can be seen at http://mastercoin-explorer.com/ (Total bought via Exodus MSC 563,162.36), and an additional 10% will be released slowly to the Exodus Address over the coming years, to be used similar to other Exodus Address funds to pay for expenses related to this project. Thanks! |
|
|
|
I simply can't express how awesome this is that you guys are making such fast progress. I need to do some investigation (and learning) into the proposed methods for storing our data in alternate ways. What I've seen so far looks very promising. All indications are that Tachicoma has a well-deserved big payday coming, and grazcoin has earned some non-trivial cash too The next month should be very interesting. |
|
|
|
I've also had a question about "Purchasing a Currency Offered For Sale" that has been bothering me.
I put an offer out there to sell 100 coins for 5 BTC.
User A and User B both send me 5BTC wanting to buy those 100 coins. User B's transactions gets added above User A's transaction in the block so he receives the Mastercoins.
What happens to the 5BTC from user A that he send to the address?
First of all don't sell 100 coins for 5 BTC. Let's say you sell 100 coins for 50 BTC ;-) The BTC from A land also on the seller's address, so according to the current spec, the seller should refund it, which is indeed a problem. Solutions: - If the payment would have been done using some mastercoin-derived-currency (even with BTC face value), the protocol could have automatically handle the refund.
- Using multisig based escrow - the funds are sent by the buyer to 2-of-3 address (buyer,seller,escrow) + marker output. If the buyer sees that he is the only buyer (e.g. after 6 confirmations), he signs the tx and the seller signs it, and the protocol interpret it as a closed deal. In this case any later buyers could get their funds back by seller or escrow signature. If there is some disagreement, the escrow signs the needed tx (refund to buyer or funds to seller).
For this we need:
- trusted escrow address (it cannot steal the funds, just decide to which side the funds go to)
- everyone's public key which may be a problem (not anyone like to share their public key)
- some communication channel to transfer the half-signed tx.
Buying MasterCoins with bitcoins on the distributed exchange is actually a two-step process: 1) Signal your intent to buy, paying a transaction fee specified by the seller to prove you are serious 2) If you are recorded in the block chain as the first one to signal your intent to buy, THEN you send payment within the specified time window of your signal If you don't send payment within the time window, the MasterCoins become available for sale again. In this way, you don't risk sending payment and not being first. This is the current logic in the spec, but I probably wasn't clear enough. Here's the actual wording from the spec, with certain bits relevant to this question highlighted: Selling MasterCoins for Bitcoins
Say you want to publish an offer to sell 1.5 MasterCoins for 1000 bitcoins. Doing this takes 33 bytes, which fits into two data payments:
1. Transaction type = 20 for currency trade offer for bitcoins (32-bit unsigned integer, 4 bytes)
2. Currency identifier for sale = 1 for MasterCoin (32-bit unsigned integer, 4 bytes)
3. Amount for sale = 150,000,000 (1.50000000 MasterCoins) (64-bit unsigned integer, 8 bytes, should not exceed the number owned, but if it does, assume the user is selling all of them)
4. Amount of bitcoins desired = 100,000,000,000 (1000.00000000 bitcoins) (64-bit unsigned integer, 8 bytes)
5. Time limit = 10 (10 blocks in which to send payment after counter-party accepts these terms) (8-bit unsigned integer, 1 byte)
6. Minimum bitcoin transaction fee = 10,000,000 (require that the buyer pay a hefty 0.1 BTC transaction fee to the miner, discouraging fake offers) (64-bit unsigned integer, 8 bytes)
Selling MasterCoins for Other MasterCoin-Derived Currencies
Say you want to publish an offer to sell 2.5 MasterCoins for 50 GoldCoins (coins which each represent one ounce of gold, derived from MasterCoins and described later in this document). For the sake of example, we'll assume that GoldCoins have currency identifier 3. Doing this takes 28 bytes, which fits into two data payments:
1. Transaction type = 21 for currency trade offer for another MasterCoin-derived currency (32-bit unsigned integer, 4 bytes)
2. Currency identifier for sale = 1 for MasterCoin (32-bit unsigned integer, 4 bytes)
3. Amount for sale = 250,000,000 (2.50000000 MasterCoins) (64-bit unsigned integer, 8 bytes, should not exceed the number owned, but if it does, assume the user is selling all of them)
4. Currency identifier desired = 3 for GoldCoin (32-bit unsigned integer, 4 bytes)
5. Amount of GoldCoins desired = 5,000,000,000 (50.00000000 GoldCoins) (64-bit unsigned integer, 8 bytes)
Changing an Offer
Say you decide you want to change the number of coins you are offering for sale, or change the asking price. Simply re-send the offer with the new details. If your change gets into the block chain before someone accepts your old offer, your offer has been updated.
If you decide you want to cancel an offer, simply send the offer again, but enter the number of coins for sale as zero.
Purchasing a Currency Offered For Sale
Say you see an offer such as those listed above, and wish to accept it. Doing so takes 16 bytes, which fits into 1 data payment:
1. Transaction type = 22 for accepting currency trade offer (32-bit unsigned integer, 4 bytes)
2. Currency identifier you are purchasing = 1 for MasterCoin (32-bit unsigned integer, 4 bytes)
3. Amount you are purchasing = 130,000,000 (1.30000000 MasterCoins) (64-bit unsigned integer, 8 bytes, should not exceed number available for sale, but if it does, assume buyer is purchasing all of them)
The reference address should point to the seller's address, to identify whose offer you are accepting.
If you are purchasing with bitcoins, make sure your total expenditures on bitcoin transaction fees while accepting the purchase meet the minimum fee requested!
You will need to send the appropriate amount of bitcoins before the time limit expires to complete the purchase. Note that you must send the bitcoins from the same address which initiated the purchase. If you send less than the correct amount of bitcoins, your purchase will be for that amount. Update 9/8/2013: In order to make parsing MasterCoin transactions easier, you must also include an output to the Exodus Address when sending the bitcoins to complete a purchase of MasterCoins. The output can be for any amount, but should be above the dust threshold.
If you are purchasing with MasterCoin or a MasterCoin-derived currency such as GoldCoins, your purchase is complete as soon as you accept the offer (assuming you are recorded in the block chain as the first to accept the offer). If you have less than the correct amount on hand, your purchase will be for that amount.
Note that when only some coins are purchased, the rest are still for sale with the same terms.
If you guys have any ideas about how to make the spec more clear on these points, I'd love to hear them. Thanks! |
|
|
|
I added some sidebar links to our subreddit: http://www.reddit.com/r/mastercoin/If I missed anything important, please let me know. I can't offer a bounty for it, but if somebody wants to take a crack at a reddit-style logo for MasterCoin, that would be fun to have. Usually such a logo would have the reddit alien in it. Maybe the reddit alien getting irradiated by MasterCoin, since our logo looks kind of like the radiation symbol  Maybe that's too unprofessional. I dunno . . .  if anyone comes up with anything better, definitely replace it. but this can be a good placeholder for now That is AWESOME. Thanks Mich! I put it up. |
|
|
|
|
Show Posts
