Hi killerstorm and the rest of the colored coin team:

I have a particular application in mind for assets backed by cryptocurrencies.  So far, using colored coins seems to be my best bet, but I'm wondering if certain things are possible:

1.  Can an issuer color coins that don't belong to him?  For instance, I sell 1 satoshi colored as a "Lump of Coal"  Now, later, the person who owns the lump of coal contacts me and we decide that the lump of coal should be on fire.  I'd like to be able to add the color "Burning Coal" to the satoshi even though I don't own it (or perhaps the owner could color it.  but it needs my signature on it).  It would be very inconvenient for the other person to have to return the coal to me in order for me to light it on fire.

2.  How long can a moniker be, and do I need to worry about spamming the blockchain if I make 10,000 different colors?  For instance, it might be useful to me if I could write a lot of details about this particular piece of coal on it, but that might be a 300 character long moniker, and it might potentially mean a separate color for each and every of the 10,000 different pieces of coal in my application.  (Of course, this destroys fungibility, so it would make setting up an exchange very difficult.  But in principle, I might still want to do something like this)

3.  Is it possible for me to determine the order that colors were added to a satoshi?  For instance, if we later add the color "Burnt Coal" to the example satoshi, it now has 3 different colors "Lump of Coal", "Burning Coal", "Burnt Coal".  I need to know that "Burnt Coal" is a newer color than the other 2.

Additionally, bitcoin's transaction fee is currently way too expensive for my application.  I can't justify selling pieces of coal that only have uses inside my application at 0.0001 btc each when the transaction fee is another 0.0001 btc.  This would be easily fixed by my using a cryptocurrency with a cheaper fee.  Are there any plans to develop a version of ChromaWallet that can work with other cryptocurrencies?

Thanks for your time

Aviv & Yonatan:  Could GHOST work in the situation that transaction & block propagation across the whole network happens much slower than block generation?  For instance, in inter-planetary distances?  We'd expect blocks to be made on Mars every few seconds but each would not make it to Earth for a few minutes.

 OK.  This works for me.

class CBlockIndex has pointers pprev and pnext that point to the parent block and the child along the main chain.  The main chain can be traversed forward and backward, but the entirety of the tree cannot.  I see no reason why this can't be changed.

Yes, this would also need to be done in order to implement your proof-of-work difficulty-adjustment algorithm, right?  But it's not required for GHOST?  I have not started looking into how to implement this.  I am worried about the bloat that this would cause if the entire tree must be stored though.  Have you looked into how your algorithm would fare if we ignored off-chain blocks for difficulty-adjustment?


I was originally under the impression that the parts of the blocktree that are not on the main chain get deleted from memory, but now I see that what I was looking at was code to invalidate blocks if the header is not correct.  I am not sure if the entire tree is kept in memory or if parts are eventually discarded.

By the way, I'm waiting to hear back from my friends before I email you back.

I've been reading through the bitcoin source code.  I'm interested in working with anyone who tries to implement this.  Here's what I've found:

All the relevant code seems to be in main.cpp and main.h.

As currently implemented, we can traverse the blocktree from leaves->root, but Aviv and Yonatan's algorithm requires us to be able to traverse the blocktree from root->leaves.  The first thing that needs to be done is that we need to rewrite the tree to make it traversable in both directions.

After this, the code to determine which block is the "BestBlock" to append a new child block to needs to be pretty much completely rewritten.  The code currently computes the ChainWork (the amount of work needed to compute the current block and all blocks above the current block on the tree) of each block in the tree.  It then searches through the entirety of (the still valid parts of) the tree for the block that has the largest ChainWork, and it assigns this block as the BestBlock.  Instead, we need to traverse the tree from root->leaves, and compare the work in each subtree whenever we come to a fork.

Also, the code to invalidate and discard blocks on the tree needs to be rewritten.  I'm lost on how this works and how it should be rewritten.

I'd buy an emptied 1BTC coin for 0.05BTC, but I'm not touching a full one.  They seem a bit unsafe.

Ah OK

But does this mean that anyone can see that all of the addresses in my wallet belong to one person?  If you know one of my wallet's addresses, can you find the rest of my wallet's addresses?

Edit: Nevermind, I found a description of how it works here: https://en.bitcoin.it/wiki/Deterministic_Wallet  I see that depending on the algorithm used to generate key-pairs, it can be difficult to find the root key & chain code from a given public key.

Actually, I'm very impressed by this.  I was under the impression that I needed to print a new paper wallet each and every time I created a new key-pair, but now I see that my root key and chain code never change, so I only ever need 1 paper wallet.

I was told that a paper wallet contains unencrypted copies of your public and private keys.

However, I don't understand how this is possible since the Armory paper wallets contain less than 100B of data, while my wallet can be arbitrarily large.

What's really going on here?

Ah thank you Vitalik.  That's exactly what I was looking for.

But most of this is not yet implemented?  That is sad

There is currently support for threshold multi-signature transactions where, for instance, 2 of 3 people must sign a transaction before it is valid.

Will there ever be support for hierarchy among the signers of a transaction?  A google search of "hierarchy secret sharing" shows that some hierarchies can be implemented.

Is this an assurance contract?  Do I get my money back if you never raise enough?

Because I don't think you'll raise enough, and I don't want to donate money to your beer fund.

I made an account in 2011 because that's when I heard of bitcoin, but I only made 1 or 2 posts back then.  Then I made a few more so I could get the XRP giveaway.

It's a slight variant.  A non-miner could be caught by the store because his double spend would be broadcast on the network.  The miner doesn't need to broadcast his double spend.

Yes.  The spend transaction is relayed through the nodes, but it is not yet included in the blockchain.

Is there a solution to the following method of stealing something from retail (groceries, coffee, a TV, etc)?

The owner of BTCGuild walks into a store and selects something.  He goes to the cashier who accepts bitcoin.  He hits send, the cashier sees the transaction (the "spend transaction") and says "thank you", and the miner walks away.

Now, there have been no confirmations on that transaction yet.  As this is retail, the cashier can't have the customer waiting around for a block or 3 to get written.

The miner kept a log of the spend transaction and knows exactly which bitcoin he spent at the store.  When he logs into the pool operating software, he attempts to write a different transaction (the "steal transaction") to send this bitcoin instead to a different address (a double spend).  Since this is the owner of BTCGuild, he's able to write the next block 30% of the time and successfully steal from the store.

The best part about this is that in the 70% of the times when some other miner writes a block, and the spend transaction is written to the blockchain before the steal transaction can be written, no one knows that a theft was attempted.  The steal transaction never gets propagated on the network until it gets written to the blockchain.

Someone knowledgeable please tell me there is a solution to this.  How could retail trust bitcoin if miners could sometimes steal from them?

I agree that speed isn't an issue for large transactions.  However, for small transactions, I still don't want to accept 0 confirmation transactions.  It's super easy to post a fake transaction that will never be confirmed.  I want at least 1 confirmation before I give away any merchandise.

Rather than quick blocks, can't we have large blocks?

What is the main limitation on confirmation speed?

The way I understand it, miners add transactions to the blockchain in exchange for a fee and for newly minted coins.  The rate of newly minted coins was determined by the early adopters of bitcoin and cannot be changed unless 51% of the miners decide to fork the blockchain.

If this is correct, then in theory, a cryptocurrency can be made with the inflation rate determined by the number of transactions included in a new block.  If many people adopted this currency, it would achieve transaction speeds far greater than any other cryptocurrency.

I believe that such a currency, made for fast trading rather than holding value, could be a good complement to Bitcoin.  It isn't feasible to buy a cup of coffee with bitcoin and wait see to confirmations of the transaction before you drink the coffee -- however, this would be entirely possible with Fastcoin.

rGU8DKkrBhCtvCiqrqrcXhP2j8YxjKiae2

-Transactions/confirmation of payment can be made quicker

I think this is a big one.  In finance, they make tons of transactions per second.  If a cryptocurrency were made that was suited for finance, it could take that part of the market.