Topic: Distributed bond markets and pay-to-policy outputs (Read 8569 times)

pybond has been renamed to smartcoin, as it will support more smart property and colored coins, than just bonds.  Github URL: https://github.com/jgarzik/smartcoin

That is all.

It would be a mistake trying to mimic current financial system in its entirety. 3/4 of it is just parasitic add-on built on top of fiat currency system. I'm pretty sure that future perception for bitcoin will change from currency to a broader meaning of transaction vehicle for all financial instruments. The idea for colored satoshis is good one.

Cool ideas!

First of all, sorry for taking so long to answer.
The first time we talked about implementing ripple on top of bitcoin was here:
https://bitcointalksearch.org/topic/bitcoin-like-implementation-of-ripple-3557
http://groups.google.com/group/rippleusers/browse_thread/thread/eac0505ca4e5b839

But maybe you mean the previous discussion about the atomic swapping in the bitcoin mailing list


Actually colored coins are also an implementation of ripple on top of bitcoin. My crazy fork, ripplecoin, is about removing the need to use satoshis as tokens. Let anyone issue as much as they like and separate the accounting of that issued credit (be it bonds, fiat deposits or e-gold) from the "hostcoin" accounting. Jgarzik argues that requiring satoshis is not a disadvantage but a good measure to avoid spaming, but I can't see why fees should fail.


Your proposal sounds pretty much like the current main design for distributed ripple. A two-phase approach in which "registries" (or timestampers) provide the atomicity. The current design is very flexible and allows various commit methods. Here's the main protocol:

http://ripple-project.org/Protocol/Protocol

There's also a blockchain commit method.

But the same concept of transitive atomic trades of credit tokens is also possible with colored coins. The A -> B -> C example I used before is a simple Ripple transaction, for the generic one you just substitute the number of arrows, 2 for n.
I don't see any impediment to do it with the rules you have described, it's just about creating the transaction that includes the credit path and all participants signing it.

My only disagreement here is...why credit units need to contain satoshis at all? Why not making the accounting for the credit currencies inside the blockchain (enforced by the protocol) for free when the expensive stuff is hashing and fees must be paid in the host cash anyway?

It's great to have an implementation that doesn't require a fork though.

Um, I actually find this fairly interesting. It looks like you're continuing some mailing list discussion here, can you please point me to original discussion so I can learn more?

I believe that a ripple-like thing can be potentially more awesome that "colored bitcoins", but it would be much easier to get "colored bitcoins" up and running so that's what I'm doing now. But I want to return to ripple ideas later...

I have a sketch of a simple distributed ripple implementation which is based  on message timestamping. It isn't designed to be compatible with blockchain in any way other than blockchain can be used to timestamp messages to get them into order.

But it looks like you've found some way to make it based on Bitcoin implementation, which might have some advantages, I guess, so I want to learn more...

They will be able to soon, yes.  "am writing"  Right now the P2P network and DHT framework are being debugged.  Once that works, it will be easy to hook up the rest.

So does it work? People willing to use command-line python script(s) can now issue bonds to each other and such?

-MarkM-

Yes. The smart car just looks in the chain to know its owner. That's why this use case cannot be implemented with the conventional ripple protocol, where the current owner is only known by the issuer (the car producer). But other smart property cases can i. e. bonds. It has the advantages and disadvantages mentioned before. I think both systems will be used for different purposes and users.

Even without a convention for which input/output is used, the car knows the last transaction that transferred ownership, so it knows which input/output to look at.

See the rules for colored coins, linked above.

Maybe I am missing something.

Two people want to exchange cars, Alice owns Honda CRV and Bob owns Toyota RAV4.
Honda CRV represented by 1 satoshi at 1qwe...
Toyota RAV4 represented by 1 satoshi at 1rty...

Bob and Alice construct single transaction to exchange cars:
Inputs:
1 satoshi from 1qwe...
1 satoshi from 1rty...
Ouputs:
1 satoshi to 1asd... (address owned by Alice)
1 satoshi to 1fgh... (address owned by Bob)

Is it possible to know what car owned by Alice, or did I misunderstand the statement that exchanged items has to be a part of the same transaction?

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

But what if a person wants to exchange one car for another, and both of them represented by the same amount of bitcoins lets say 1 satoshi, creating single transaction would make it impossible to tell who owns what.

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://bitcointalksearch.org/topic/m.1169974

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.

Speaking as someone who is implementing this right now...  it is very elegant.

One of the rules that will be encoded into pybond is

• A bond (a colored coin / smartcoin) is never zero-value (nValue==0 in CTxOut)

Thus the value is intentionally dependent on bitcoin.  It raises the cost of creating each bond above zero, thereby creating an incentive to be conservative with your bond / smart property issuance.  It also serves as a fee signal (it is required to pay a fee to transfer tiny amounts of bitcoins), further discouraging spam and flooding, and encouraging efficiency.

1000 bonds requires a minimum of 1000 satoshis.  A value of 3 satoshis may mean (this is bond-dependent) that the holder carries 3 bonds.

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.

Yep, SIGHASH_ALL was the bit I was missing.  Looks 100% possible to do this, indeed.

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

I think you guys are mixing up a few different things here.


The paragraph you quote is about the case where a pay-to-policy outputs are being claimed for the first time. At this time, the money is being claimed by the issuer. Later when the bond moves on the secondary market no trust is required.



They are done as part of the same transaction. P2P bonds are based on smart property, this page has detailed protocol descriptions that may make things clearer:

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

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.