November 21, 2017, 04:06:42 am

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - barisser

Pages: [1]
Coinprism API / Parsing Metadata with variable length fields
« on: May 28, 2014, 07:21:00 am »
I'm referring closely to

The asset quantities are variable length leb128 encoded. OK.

The metadata is also variable length.

When I parse metadata in OP_RETURNs, how do I know where the asset quantity field ended and the metdata began?  I'm having trouble with this.


General Discussion / Re: Backscanning
« on: May 27, 2014, 07:47:17 am »
Great, these are the answers I was hoping for.

Coinprism API / Re: Metadata OA protocol
« on: May 23, 2014, 06:08:31 am »
The protocol document doesn't say anything about what the metadata ought to contain.

"Possible formats for the metadata field are outside of scope of this protocol, and may be described in separate protocol specifications building on top of this one."

General Discussion / Re: Backscanning
« on: May 23, 2014, 06:05:59 am »
I realize this.

But what if I write a transaction with the correct metadata, marker output, etc, claiming to have colored coins that a particular address does not actually have?

There needs to be a process to check whether those colored coins were real or not, or whether they were double spent, or not.  Bitcoin inherently prevents double-spending.  But Bitcoin was designed for Bitcoin, not for a layer abstracted on top of it.   

My understanding is that you would back-scan the sender's colored coins to the correct issuing address of that colored coin type.

As for double-spending, I would assume that you leverage the 'unspent inputs' of regular Bitcoin to harness Bitcoin's defense against double-spending.  This would also explain why you warn against color unaware wallets uncoloring coins.  Using unspent inputs that were colored in an uncolored transaction, while not spending colored coins, removes them from the unspent pool.  Does that sound right?

Coinprism API / Metadata OA protocol
« on: May 17, 2014, 08:44:30 pm »
I'm looking at the marker output OP_RETURN data in these colored coin transactions.

I'm sending DETHKOINS from address A to address B.  In some cases, the metadata consists of a link to a site describing DETHKOINS: ''

In other instances I get weird metadata without the link. 

Here are some example OP_RETURN fields hex decoded for DETHKOIN transactions:

txhash: f3c1607e176ae8550c20601d8076cdddabcbc97e65928022a5d7bd604c25396e

txhash: b7d239c487c05bf2543ba5894cc40aed10aa5acaaf03a7f40c0a728116fb7e26

txhash: 0f0169b34fe25f3ae76342c1f3b865f0d920b823daf891693830057aa90bef32

Notice that the metadata is different in all 3 examples, even though these are all DETHKOINS.  Can someone explain this?

How do I know what color a colored coin transaction is?  Is it through the metadata?  Or is it through backscanning to the issuing address?


General Discussion / Pushing OP_RETURN Transactions
« on: May 14, 2014, 04:46:18 pm »
How are you pushing OP_RETURN transactions?  Is there an online way to do this?  Or are you running Bitcoind and pushing them directly to nodes yourselves?

Could you open up a web-api to push 0.9.1 bitcoind OP_RETURN transactions?


General Discussion / Backscanning
« on: May 14, 2014, 04:44:56 pm »
How does backscanning work with this protocol?  How do I ascertain the colored coin content of a particular address?  How do I know whether a given 'colored coin' transaction was legitimate?

Also a more specific question, does backscanning rely on unspent Bitcoin inputs to trace back to the issuing address?  Because if that were so, colored coins could be uncolored by simply using that unspent bitcoin in a non-colored coin transaction.  In which case, your address would be net X colored coins, but unable to spend them.

I just want to understand the implementation.  Great job with the site.

Pages: [1]