Bitcoin Forum
June 20, 2024, 12:35:58 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Distributed bond markets and pay-to-policy outputs  (Read 8540 times)
jtimon
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002


View Profile WWW
September 25, 2012, 09:11:06 AM
 #21

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.

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.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
markm
Legendary
*
Offline Offline

Activity: 2940
Merit: 1090



View Profile WWW
September 29, 2012, 11:11:10 PM
 #22

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

That is one distributed bond effort, yes.

There is no Official Blessed Distributed Bond effort; each developer just scratches their own itch.  In pybond's case, I am writing a basic distributed bond implementation, with no pay-to-policy stuff, just to prove the basics work.


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

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1596
Merit: 1091


View Profile
September 29, 2012, 11:46:41 PM
 #23

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

That is one distributed bond effort, yes.

There is no Official Blessed Distributed Bond effort; each developer just scratches their own itch.  In pybond's case, I am writing a basic distributed bond implementation, with no pay-to-policy stuff, just to prove the basics work.


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

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.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
killerstorm
Legendary
*
Offline Offline

Activity: 1022
Merit: 1033



View Profile
September 30, 2012, 12:33:21 PM
 #24

I guess this would be a crazy fork and probably nobody wants something like this but me.

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...

Chromia: a better dapp platform
jtimon
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002


View Profile WWW
October 08, 2012, 10:51:34 PM
Last edit: October 09, 2012, 09:57:11 AM by jtimon
 #25

I guess this would be a crazy fork and probably nobody wants something like this but me.

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?

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://bitcointalk.org/index.php?topic=3557.0
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

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...

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.

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...

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.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile WWW
October 09, 2012, 03:03:10 AM
 #26

Cool ideas!

becoin
Legendary
*
Offline Offline

Activity: 3431
Merit: 1233



View Profile
October 10, 2012, 07:40:03 PM
 #27

But can we go further and design p2p low-trust replacements for other parts of the financial system?
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.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1596
Merit: 1091


View Profile
October 13, 2012, 05:13:30 PM
 #28

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.

Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!