Nice work! Implementing this sort of technology is the way forward.

ByteCoin

Is this the pybond project mentioned at the end of the State of the Coin 2012 slides?

I don't think the transferable bonds you described are realizable with the limited validation script currently in place. You have come to a different conclusion (that bonds can be implemented right away!), seemingly because of a subtle word-mincing mistake.



The issuer creates a bond, and is the first person to own it. The owner of a bond is stateful (time-dependent) since ownership changes after the issuer initially sells the bond, and changes again each time it's traded on a secondary market.


You have to trust the issuer of a bond to repay it, but you should not have to trust the previous (or any other) owner in any capacity. There are two ways to read your statement here:
   1) The "owner of a correctly-attributed bond key" means the issuer. You trust the issuer to repay the bond, so you also trust the issuer to authorize every ownership-transferring transaction - not just the initial transfer from [issuer]->[owner2], but also from [owner2]->[owner3] must be signed by the issuer as well. I don't think you intended for the issuer to be online/in-the-loop for every transfer. The main reason it's unsatisfactory is that the issuer could exercise influence by refusing or delaying to sign later transactions.
   2) The "owner of a correctly-attributed bond key" means the previous the owner. The previous owner signs a transaction transferring the bond over to a new owner. Bonds may be traded many times on secondary markets, without the issuer's intervention. But now the previous owner is not the person you trust to repay the bond, it's just someone you have an ephemeral interaction with. So this weak point is a bigger deal than you suggested.

The problem begins with the restriction you already pointed out, which is that the script can not enforce a relation between the inputs and the outputs.

I don't think there is a simple way of expressing this constraint without storing additional state. Here's the easiest way I can think of to create an 'overlay currency', a quantity that can be issued like a bond and where the conservation rule is explicitly validated by blockchain miners.
OP_BOND <hash of bond message> <quantity:int>   // valid in scriptpubkey only (yes this interferes with pruning)
Miners would need to keep an additional table to store the set of active bond IDs. The first time a hash-of-bond-message appears, it's treated as the Issuance, and added to the set. In all subsequent transactions, the rule is that the sum of the OP_BOND quantities (for a given bond-hash) in the scriptpubkeys must match the sum of the quantities in the inputs.

Im sorry but if you need to trust a human to pay a loan back its going to fail at the starting line. Just look at the devastation of the bitcoin loan market over the past month and see why.

The only way this is remotely feasible is with backing from physical collateral you can place a lien on.

Obviously in the "real world" people do pay back loans. The bitcoin forums may have a significant number of scammers, but hey, you're lending to random strangers over the internet. Nobody says that's the only way Bitcoin can be used though.


Smart property lets you do collateralized loans, at least in theory (it needs special kinds of property to work, which doesn't exist today):

https://en.bitcoin.it/wiki/Smart_Property

The difference between this and "ripplecoin" (which lacks a formal design and implementation) are the satoshi containers. In ripplecoin anyone can issue a bond that is stored in the chain just by signing its issuance. I first thought that transactions would need to be severely modified to support ripple but it turns out that with colored coins almost all the information can be out of the chain. Ripplecoin needed a host currency to pay miners anyway so the satoshi tokens aren't a huge cost and they could prevent DoS attacks. Fees would still be paid in hostcoins so I don't see the problem, but I'm interested to what the people here can say about that.

Ripplecoin would be implemented if instead of the satoshi counters the counters I the bitcoin protocol was changed like this:

- Any address can issue any quantity to another address. Each issuing address is a color.
- These "bondcoins" are counted separately not only from the real bitcoins but also between different colors.
- Bonds going back to their issuing addresses represent redemption.

Now the rules are enforced by the chain. Does it make any difference? People can make the chain enforce the accounting by representing their assets with the smallest unit. The scarcity of bitcoin is not an issue. Satoshis are abundant and potentially infinite.

It's just inconvenient for the issuers to require an underlying satoshi for each assets, because the divisibility of their issued assets and the maximum quantity of them that can issue depend directly on the divisibility of bitcoin itself. Doesn't seem so elegant to me.

I guess this would be a crazy fork and probably nobody wants something like this but me. But I would like to hear the reasons because maybe there's solutions to the potential problems.
I guess it will be DoS. Maybe a minimum fee for transactions that don't move bitcoins?
Maybe that's not fair and a minimum fee for all transactions is necessary for all miners to avoid attacks but we still don't know it?
I would like to hear your opinions.

Yes, this is exactly the point:


More than arguments in favor of this rule, which is more clear than what I posted before, I want problems that could emerge.
Being conservative about issuing sounds nice, but I want to know how the sky will fall if we don't follow it or something. A terrible attack we must defend against and I'm missing.


I'm not sure I understand this part. Does the protocol currently charge a fee to tiny amounts but not to null amounts?
What's wrong with fees as protection against DoS? If they're not enough maybe a satoshi won't save us anyway.


As you say, it is bond dependent. 100 satoshis could also represent a single bond. You're only interested in the number of bonds, why are you dealing with the number of shatoshis all the time?
What if there's a bond use case that requires bigger cardinality than bitcoin needs?
I don't know. The so waited micro-payments for bandwidth?
Nothing in use today comes to mind.
But since I think fees are enough to stop spam, this appears to me as an artificial and unnecessary limitation.
It's probable that I'm missing an important detail or something, so I ask.

I'm very glad that you're implementing this, the use cases are infinite. Thank you.
Do you have a document with all the rules of your colored coins design?

Here's a criteria explained with examples:
https://bt.irlbtc.com/view/106449.msg1169974#msg1169974

With that notation, my ripple example in the mailing list would become:

A 1 satoshi -> B 1 satoshi -> C 1 btc -> A

Inputs: [1 srcA, 1 srcB, 10^8 uncolored]
Outputs: [1 destB, 1 destC, 10^8 destA].

Or for a regular ripple payment (not in exchange of 1 bitcoin, but another ware) you could have

A -> B -> C

Inputs: [20000 srcA, 200 srcB, 1 uncolored]
Outputs: [20000 destB, 200 destC, 1 destA].

With the uncolored satoshi delivered to A representing the receipt of the payment. In this case, a receipt for a product that costs 200 usd.

A issues his credit as 1 satoshi = 1 cent of a dolar.
B prefers to issue her credit as 1 satoshi = 1 dolar as she's more bond conservative and doesn't buy cheap stuff anyway.
C is paying a satoshi to print a receipt.
Can empty inputs and outputs have zero values with the current bitcoin protocol?

There's going to be different units anyway (for credit fees, different currencies/bonds, etc), but it's a bit strange to use different bases for the same unit only because there's some intrinsic and indivisible units below the value represented.

OT's "untraceable" "cash" instrument also imposes this tipe of atomic token. But they have a very good reason: they cannot send two coins to the same address (nor divide them). That also imposes more anonymity by requiring people to use lots of different addresses for a single payment and forces minters to clean their logs of untraceable traces of the credit they issue.
I don't want to offend anyone, they're doing a great job and I definitely should study the potential of ricardian contracts which I'm not sure I understand. But I don't think that particular cash credit instrument will be very useful in the future.

In any case, the "atomic tokens" is not a feature by any means, it may be a defense, but I still don't know the attack.
Unless, of course, the exchange of crypto-assets that aren't related to bitcoin in exchange of bitcoin fees is considered an attack in itself, which is what I assumed when proposing a separate chain for ripplecoin. Hopefully I was wrong.

ECDSA keys provably demonstrate who owns what.  It uses the same technology as the rest of bitcoin.

See the rules for colored coins, linked above.