Bitcoin Forum
December 08, 2016, 10:10:06 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Distributed bond markets and pay-to-policy outputs  (Read 7652 times)
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
July 09, 2012, 03:53:25 PM
 #1

I've moved the contents of this post to the wiki:

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

and linked it from a re-organized Contracts page.
1481235006
Hero Member
*
Offline Offline

Posts: 1481235006

View Profile Personal Message (Offline)

Ignore
1481235006
Reply with quote  #2

1481235006
Report to moderator
1481235006
Hero Member
*
Offline Offline

Posts: 1481235006

View Profile Personal Message (Offline)

Ignore
1481235006
Reply with quote  #2

1481235006
Report to moderator
1481235006
Hero Member
*
Offline Offline

Posts: 1481235006

View Profile Personal Message (Offline)

Ignore
1481235006
Reply with quote  #2

1481235006
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Sukrim
Legendary
*
Offline Offline

Activity: 1848


View Profile
July 09, 2012, 09:15:17 PM
 #2

Wow, thanks a lot for that term (CP-ABE), very insteresting stuff indeed!

Paper:
http://www.cs.utexas.edu/~bwaters/publications/papers/cp-abe.pdf

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
July 09, 2012, 10:49:01 PM
 #3


Sahai-Waters CP-ABE is a recent advance based on pairing-based encryption.

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

ByteCoin
galambo
Sr. Member
****
Offline Offline

Activity: 390



View Profile
July 24, 2012, 02:09:21 AM
 #4

What a fun read!

Unfortunately, most readers do not understand the asset, unless mining is involved.

And for that usage they are probably correct in thinking that GLBSE is adequate, for now.
keystroke
Hero Member
*****
Offline Offline

Activity: 824


advocate of a cryptographic attack on the globe


View Profile
September 18, 2012, 12:15:44 AM
 #5

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

"The difference between a castle and a prison is only a question of who holds the keys."
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
September 18, 2012, 12:57:05 AM
 #6

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.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
socrates1024
Full Member
***
Offline Offline

Activity: 125


Andrew Miller


View Profile
September 22, 2012, 04:36:04 AM
 #7

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 bond, being an asset like any other, is transferable - if you get tired of receiving the repayments you can sell the bond to somebody else.

This output tracks the current owner of the bond. The owner receives the repayments and any accrued interest. Of course a newly issued bond is special, it starts out being owned by the issuer.
If the bond owner wishes to sell the bond, a sale message is broadcast on the exchange p2p network:
....
By scanning the block chain for payments to the current owner of the bond, and checking them against the repayment schedule, the software can automatically calculate which bonds are delinquent and which are mature. Issuers of delinquent bonds would show up in the UI as in debt until sufficient sums were paid to the owners pubkey.


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.

There is one weak point here: you have to trust that the owner of a correctly-attributed bond key will actually construct a valid (protocol wise) bond transaction that transfers control to the owner_pubkey you requested. Given that you're also trusting this person to repay the bond, this is not necessarily a big deal, but it'd be nice to require it.

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.
The second problem is that script cannot contain signatures over anything other than transactions, and only limited forms at that. So you cannot have numeric assertions in outputs because you have no way to verify the inputs are legitimate.

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.

amiller on freenode / 19G6VFcV1qZJxe3Swn28xz3F8gDKTznwEM
[my twitter] [research@umd]
I study Merkle trees, credit networks, and Byzantine Consensus algorithms.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
September 22, 2012, 07:31:25 AM
 #8

There is one weak point here: you have to trust that the owner of a correctly-attributed bond key will actually construct a valid (protocol wise) bond transaction that transfers control to the owner_pubkey you requested. Given that you're also trusting this person to repay the bond, this is not necessarily a big deal, but it'd be nice to require it.

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.

This seems like a fair criticism.  There are two parts to a typical bond transfer,

1) Owner #10 must create and sign a well formed BOND message to Owner #11
2) Owner #11 must create and sign bitcoins to Owner #10

Each party is holding something of value, and wants to trade for the other thing.  What does game theory say?  Smiley  Each party's action may be instantly validated, but who goes first?

At this juncture, perhaps some readers may be directed to the just-created Atomic Coin Swapping thread, if they have helpful ideas.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Bitcoin Oz
Hero Member
*****
Offline Offline

Activity: 700


Wat


View Profile WWW
September 22, 2012, 09:20:22 AM
 #9

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.

Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
September 22, 2012, 11:48:22 AM
 #10

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

There is one weak point here: you have to trust that the owner of a correctly-attributed bond key will actually construct a valid (protocol wise) bond transaction that transfers control to the owner_pubkey you requested. Given that you're also trusting this person to repay the bond, this is not necessarily a big deal, but it'd be nice to require it.

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.

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.


This seems like a fair criticism.  There are two parts to a typical bond transfer,

1) Owner #10 must create and sign a well formed BOND message to Owner #11
2) Owner #11 must create and sign bitcoins to Owner #10

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
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
September 22, 2012, 11:55:29 AM
 #11

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.

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.

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

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
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
September 22, 2012, 05:26:21 PM
 #12

This seems like a fair criticism.  There are two parts to a typical bond transfer,

1) Owner #10 must create and sign a well formed BOND message to Owner #11
2) Owner #11 must create and sign bitcoins to Owner #10

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

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


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
September 23, 2012, 05:24:27 PM
 #13

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.

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

Activity: 1470


View Profile
September 23, 2012, 06:26:41 PM
 #14

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.

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.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
September 24, 2012, 08:43:24 PM
 #15

Yes, this is exactly the point:

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)

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.

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.

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.

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.

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

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

Activity: 269


View Profile
September 25, 2012, 12:44:42 AM
 #16

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

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.

jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
September 25, 2012, 12:56:22 AM
 #17

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

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.

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




Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Serith
Sr. Member
****
Offline Offline

Activity: 269


View Profile
September 25, 2012, 01:12:05 AM
 #18

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

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.

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

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?

They are done as part of the same transaction.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
September 25, 2012, 02:55:10 AM
 #19

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?

They are done as part of the same transaction.

See the rules for colored coins, linked above.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
September 25, 2012, 08:41:26 AM
 #20

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.
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!