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