Fidelity bonds

[Karel Tuma]

Given the impending doom of order-based coloring thanks to UTXO dust spam filtering, I'd like to explore coloring algorithms which "workaround" such restrictions, retep's stuff in particular.

Has anyone got any pointers explaining it "like I am five" (ie actual examples with use cases, instead of mere wall of text)?

[Alex Mizrahi]

Given the impending doom of order-based coloring thanks to UTXO dust spam filtering, I'd like to explore coloring algorithms which "workaround" such restrictions, retep's stuff in particular.

Just use like 50000 satoshis per unit. I doubt  they will consider such amounts being spam.

[Karel Tuma]

Dne čtvrtek, 25. dubna 2013 13:39:02 UTC+2 Alex Mizrahi napsal(a):

Given the impending doom of order-based coloring thanks to UTXO dust spam filtering, I'd like to explore coloring algorithms which "workaround" such restrictions, retep's stuff in particular.

Just use like 50000 satoshis per unit. I doubt  they will consider such amounts being spam.

Sure assuming spam limits remain in line with USD valuation. Thats 8 US cents per unit issued. Am I the only one to find that teensy bit impractical?

[Alex Mizrahi]

Sure assuming spam limits remain in line with USD valuation. Thats 8 US cents per unit issued. Am I the only one to find that teensy bit impractical?

It depends on what you're doing...

If there is a problem, you can calculate value of a colored coin as 

   value of thing it represents + value of Bitcoins used to represent a share.

E.g. you're selling shares of your enterprise and price per share is 0.1 BTC. Then you should sell colored coins for 0.1005 BTC if one share is represented with 0.0005 BTC.

Issuance might be a  bit of a problem, but perhaps one should issue them in small batches if financing is a problem...

BTW, what's about "impeding doom", do you have a link to the latest talk?

[Cameron Stewart]

There's a better way of solving the dust problem without limiting the
minimum size of the outputs. Simply limit the increase in size of the
utxo per block.

Miners would then just charge a fair price for an increase in the
number of utxos and people would be rewarded for spending small
payments (in the form of no fees) such that the accumulation of them
would never be a problem.

It also means that the increase in utxo will be limited so miners do
not have to worry about ddos due to massive increase in utxo.

> --
> You received this message because you are subscribed to the Google Groups
> "Colored bitcoin - BitcoinX" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoinX+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Karel Tuma]

Argued that on forums/irc as well - it does not matter the amount, but how much coins are actually "splitted". For some unknown reason this is apparently not viable - i've been told utxo space does not matter, but space occupied by blocks is more pressing issue - but that discussion belongs to Bitcoin ml, not here.

Coin coloring should just account for the fact that network will be eventually hostile towards microtransactions, whether we like it or not.

Dne čtvrtek, 25. dubna 2013 15:02:03 UTC+2 canoon napsal(a):

[BlueMeanie]

 Dobré ráno,

  Just to be clear here you're saying that you can't ensure that all transactions will be carried by the network.

  This thread is simply reiterating the points I made earlier about the problem of transactions scaling to fees.  Are we now acknowledging that this is a problem?

  some background reading:

   http://www.mail-archive.com/bitcoin-d...@lists.sourceforge.net/msg01802.html

   https://github.com/bitcoin/bitcoin/pull/2100

 seems there is no consensus in this group re. Microtransactions.

 Karel: "network will be eventually hostile towards microtransactions"
 Cameron: "There's no inherent problems with microtransactions it's just its not economical"

 -bm

[Alex Mizrahi]

It isn't a "problem with microtransactions", it is a "war on UTXO set size".

The difference is that constant per-KB fee makes microtransactions uneconomical at some point,

while "war on UTXO set size" penalizes transactions which presumably affect UTXO set size.

I don't think it is a big problem... Once rules are set up, issuers will have options:

 * make units not-so-small

 * make them small and let users pay larger fees or have their transactions delayed

 * move on other networks

Market will decide =)

Don't forget that rules are not cast in stone, right now miners simply do not care because they have large subsidies. But, say, in 4 years subsidy will get cut and tx fees will play a bigger role, so miners will start looking for rules which maximize total fees paid.

[Karel Tuma]

Dne čtvrtek, 25. dubna 2013 19:11:07 UTC+2 Alex Mizrahi napsal(a):

It isn't a "problem with microtransactions", it is a "war on UTXO set size".

The difference is that constant per-KB fee makes microtransactions uneconomical at some point,

while "war on UTXO set size" penalizes transactions which presumably affect UTXO set size.

I'm talking about this:

https://github.com/bitcoin/bitcoin/pull/2351/files

Is not war on UTXO size, but outright ban of microtransactions ("if your tx makes no economic sense, no mempool for you").

[Tamas Blummer]

This is the reason the bits of proof color definition had unit size from the beginning.

[Karel Tuma]

I'm not sure I understand how that solves issue at hand - ban on txes below minimum fee affects all order-based coloring, no matter how you put it.

Dne pátek, 26. dubna 2013 7:44:51 UTC+2 Tamas Blummer napsal(a):

[Alex Mizrahi]

This is the reason the bits of proof color definition had unit size from the beginning.

ArmoryX has unit size from the beginning too...

I'm not sure I understand how that solves issue at hand - ban on txes below minimum fee affects all order-based coloring, no matter how you put it.

What's the problem with allocating 50000 satoshi per unit?

Say, if you're issuing USDcoins, you can make it so $1 USDcoin = 50000 satoshi.

Of course, users won't be able to transact an amount of less than $1 USD (if all miners apply retep's patch. Which I doubt. Probably transactions with small amounts will take more time.)

At current exchange rate, 50000 satoshi cost $0.07.

Is it a problem to pay $0.07 to issue $1?

E.g. to issue $10000 worth of vouchers/bonds you need $700 upfront.

If you aren't a 12 year old scammer, it's unlikely to be a problem.

What we absolutely need is an ability to issue more coins of a same kind.

But now Albert had this great idea to separate color and an asset definition...

I.e. asset can be defined to consist of coins of different colors, and individual colors won't get mixed.

We need to standardize this ASAP, it's crucial.

[Tamas Blummer]

On Friday, April 26, 2013 1:11:50 PM UTC+2, Alex Mizrahi wrote:

What we absolutely need is an ability to issue more coins of a same kind.

Same kind means having same terms then they are fungible.  This is why hash of terms,

unit and expiry is the name of the color in bits of proof.

 

But now Albert had this great idea to separate color and an asset definition...

I am not convinced this is a good idea. A color is meaningless if not uniquely assigned with the terms

it represents.

 

I.e. asset can be defined to consist of coins of different colors, and individual colors won't get mixed.

We need to standardize this ASAP, it's crucial.

Your example is not an example. What we need is proof of concept applications for real world problems

and not running ahead to mark claims with "standards"

 

[Alex Mizrahi]

 

But now Albert had this great idea to separate color and an asset definition...

I am not convinced this is a good idea. A color is meaningless if not uniquely assigned with the terms

it represents.

Sure. But we need to prevent mixing between multiple issues because such mixing creates problems.

(Basically, some clients won't be aware about additional issues, so they will interpret mixed outputs as invalid (uncolored), which has negative consequences.) 

 

Your example is not an example. What we need is proof of concept applications for real world problems

and not running ahead to mark claims with "standards"

We were discussing problems with mixing back in September, I think, with examples and everything...

[Karel Tuma]

Dne pátek, 26. dubna 2013 13:11:50 UTC+2 Alex Mizrahi napsal(a)

E.g. to issue $10000 worth of vouchers/bonds you need $700 upfront.

If you aren't a 12 year old scammer, it's unlikely to be a problem.

What we absolutely need is an ability to issue more coins of a same kind.

But now Albert had this great idea to separate color and an asset definition...

I.e. asset can be defined to consist of coins of different colors, and individual colors won't get mixed.

We need to standardize this ASAP, it's crucial.

Fair point. My argument stems from the fact that issued amount is fixed. This limits certain schemes of crowdfunding which are executed as IPO (ie there is very little initial capital, but the issuer is otherwise trusted and raised capital is going to be significant). If

it will be possible to issue more units as time goes on (that involves multiple genesis txes, does not it?), I have no further comments and 5 cent per asset unit indeed even offers protection from obvious low-life pump & dump scams.

[Karel Tuma]

Worst case scenario: The measure gets implemented (0.0005) minimum but spam goes on after a while anyway it starts endangering network integrity. Remedy becomes raising it to 0.01 -> poof everyone holding less than 10 assets is stuck with it for life, and trading is possible only in 10-sized lots.

Dne pátek, 26. dubna 2013 14:24:31 UTC+2 Karel Tuma napsal(a):

[BlueMeanie]

On Friday, April 26, 2013 7:11:50 AM UTC-4, Alex Mizrahi wrote:

What's the problem with allocating 50000 satoshi per unit?

Say, if you're issuing USDcoins, you can make it so $1 USDcoin = 50000 satoshi.

Of course, users won't be able to transact an amount of less than $1 USD (if all miners apply retep's patch. Which I doubt. Probably transactions with small amounts will take more time.)

At current exchange rate, 50000 satoshi cost $0.07.

Is it a problem to pay $0.07 to issue $1?

E.g. to issue $10000 worth of vouchers/bonds you need $700 upfront.

If you aren't a 12 year old scammer, it's unlikely to be a problem.

   Good Morning,

   I think you're generally right in this thinking.  It seems that BTC has some relationship to the basic processing power of the network, and obviously this is a resource that is required to carry the transaction.  No amount of recalibration of COIN_DUST is going to fix the problem permanently.

   Another way to address this problem is having Colored Transaction Fees, which offers incentive for miners that scale to the worth of the asset ie. low quality asset trading becomes uneconomical.

What we absolutely need is an ability to issue more coins of a same kind.

But now Albert had this great idea to separate color and an asset definition...

I.e. asset can be defined to consist of coins of different colors, and individual colors won't get mixed.

We need to standardize this ASAP, it's crucial.

  This is a key aspect here and it should get sufficient treatment.  Karel also makes some good point further on this thread.

  It's important to understand that users need not only technical performance, but they need clear and well defined ideas that are supported by the system.  Confidence is a very important factor in currency systems.  So we must be clear in our intentions.

  Many applications will require incremental issuance.  IMHO, it's extremely important that we dont suggest that it's possible to simply Issue more of a coin color.  One Issue = set number of coins of a given color.  Without this kind of fidelity, you disqualify the technology from many useful applications.

  How do you do it?

  In my earlier proposal I suggest the DNS system be used to identify a Color ie. Asset Class.  Not only does this basic mechanism offer many useful OoTB features, but it gives us yet another useful quality: Asset Taxonomies.

  So a coin is identified by a DNS name:  mybonds.bluemeanie.com .  They are traded, exchanged, valued, etc. like you would expect.  However there are many types of bonds that have different properties.  How do we manage this?  by using DNS!  it's simple.   issue1.mybonds.bluemeanie.com , zerocoupon.mybonds.bluemeanie.com , etc.

  Now the main advantage to all this is that I've got something like a class taxonomy you might recognize from OOP.  It's possible to construct a client that manages all these bonds in a generalized way, or I could also design a client to manage the specific properties of one particular bond type, zerocoupon.mybonds.bluemeanie.com.

  How does this work?  remember the Ricardian Contract from before?  Well the terms that all the bonds have in common is located in the document:

    http://mybonds.bluemeanie.com/rc.xml

  while each of the types themselves have their specialized terms ie.

   http://zerocoupon.mybonds.bluemeanie.com/rc.xml

  This also can solve the problem of incremental issuance simply by creating an asset class and issuing a number of asset types below it.

   commonshares.bluemeanie.com   ie. stock shares in MeanieCorp

  issue1.commonshares.bluemeanie.com
  issue2.commonshares.bluemeanie.com
  issue3.commonshares.bluemeanie.com

   etc...

  so in this system its very easy to make these assets APPEAR to be the same for the average low end user, however they are strictly distinct in terms of the protocol, and that is very important IMHO, because you must make it absolutely clear that dilution of an asset market is simply and plainly NOT POSSIBLE.

   -bm




   

 

[Alex Mizrahi]

Worst case scenario: The measure gets implemented (0.0005) minimum but spam goes on after a while anyway it starts endangering network integrity. Remedy becomes raising it to 0.01 -> poof everyone holding less than 10 assets is stuck with it for life, and trading is possible only in 10-sized lots.

There are threw ways to change rules:

1. Advisory, i.e. not enforced. (I'm not sure what is the official terminology.)

2. Soft-fork.

3. Hard-fork.

Right now people discuss only advisory-level changes. I think Gavin mentioned that if this ban will be made a hard rule,  there will be a huge backlash against it (although in a different context).

If ban stays on advisory level, people won't be "stuck with it for life". At least it is very unlikely: there will always be a miner who won't follow rules and will get such transactions into blocks. It will just take some time.

And I bet we'll get a warning way before that happens... And so there will be an opportunity to migrate.

There are three ways to migrate:

1. Swap transactions: issuer will either buy coins back, or exchange old coins for new coins. Obviously, works only if exchange happens on the same network... Unless cross-chain trade script is used.

2. Smart voucher mechanism: Colored coins are sent to issuer, and thus redeemed for new coins. Possible on a different network.

3. Voting mechanism: Issuer freezes ownership state at  block X, i.e. all transfers after that are not considered valid. People then send issuer messages with their new address (on a different network) and sign them with private keys which prove that they owned coins by block X.

    This is absolutely bulletproof, it works even if there is a hard ban and even if Bitcoin is totally dead. All you need is one copy of a blockchain.

So in the worst case issuer will just use "voting mechanism"-style migration...

Problems from users' perspective:

1. They  might need to install new software. (E.g. a client for a new network.)

2. Users who haven't heard that asset is frozen at block X might buy useless coins. 

3. There will be a temporary disruption on market when coins no longer work on Bitcoin network.

4. If old client and new client are separate pieces of software, they will have to follow instructions to complete migration. Like get address from new client and put it into a dialog in old client, click 'migrate' button

[Cameron Stewart]

> Another way to address this problem is having Colored Transaction Fees, which offers incentive for miners that scale to the worth of the asset ie. low quality asset trading becomes uneconomical.

Mind explaining this?

--

[BlueMeanie]

 Hi Cameron,

   I think the crux matter comes down to one question:  what is the intrinsic value of BTC?  Seems the answer to this question eludes just about everyone.  But people keep using it and exchanging it all the same.  It appears to have some basic relationship to the processing power of the network participants.  At this point we lack any strict formalisms for explaining this.

   So we face a specific problem here- we want to attribute a new value to a Bitcoin ie. 'color' it.  Problem is that if we do this, when we trade them, more than likely these trades will fall under the traditional bitcoin category of microtransactions.  Some appear to think that MTs are evil and we should have some law against them.  Others think that they should just be left alone to do what they will.  I think there is a very clear case for emergent abuse that could lead to some serious systemic problems.  So we are faced with the prospect that IF MTs are somehow illegalized, then perhaps our color transactions will also be illegalized.  I don't need to go into reasoning as to why that's a problem here.

   Miners need an incentive to process the blocks.  Those incentives will change over time as we reach new phases of BTC.  We don't really KNOW precisely what will happen then.  What is being assumed is that the incentive to process Color Coins transactions will be in terms of a BTC tx fee.  What we have not fully considered is, what if we offered incentive in terms of the asset itself, ie Colored Transaction Fees?  I do accept that perhaps TX fees are best priced in BTC because it appears to have a relationship to the resource we are using, that is processing power.  In this scenario, BTC does have an intrinsic value- it's the basic fuel that keeps the whole network running.  It's still an open question I think.

   thanks for your question... -bm

   "The first requisite of a sound monetary system is that it put the least possible power over the quantity or quality of money in the hands of the politicians." -Henry Hazlitt

[Stan Stalnaker]

honestly its demand, but you could argue the intrinsic value is derivative energy. 

Stan Stalnaker: Strategic

+447974156458

London. New York. Bermuda.

HubCulture.com: Humanizing Digital

VenCurrency.com: It's time for a new kind of money

[Alex Mizrahi]

  In my earlier proposal I suggest the DNS system be used to identify a Color ie. Asset Class.  Not only does this basic mechanism offer many useful OoTB features, but it gives us yet another useful quality: Asset Taxonomies.

  So a coin is identified by a DNS name:  mybonds.bluemeanie.com .  They are traded, exchanged, valued, etc. like you would expect.  However there are many types of bonds that have different properties.  How do we manage this?  by using DNS!  it's simple.   issue1.mybonds.bluemeanie.com , zerocoupon.mybonds.bluemeanie.com , etc.

Same can be done without DNS. DNS is like a fifth wheel here.

You know, information about issuance is just information, it can be contained in any kind of a document or a database.

 

   so in this system its very easy to make these assets APPEAR to be the same for the average low end user,

Well, it is entirely the matter of user interface.

[Jorge Timón]

I still don't understand the attack they're trying to prevent.

Can't "micro-outputs" be left in disk with the rest of the chain?

Can't the paging of the UTXO be made so that spending a micro-output
only causes a fail in the memory paging and you can relegate those
"economically non-sense" outputs to disk?

Is disk storage what they're optimizing or what?
You can put data into the miners disks, so what?
You're paying the fee for it. You shouldn't be able to put 10 GB in
the chain cheaply, period.
It's all about the UTXO then.
Miners shouldn't care much about disk.
There's also thin clients. They should only care about the subtree
from their holdings to their coinbases, and then through the spinal
hashchain to genesis. They only care about what they have in the UTXO,
no spam for them.

This change getting into the hard-fork level would clearly impact
negatively the colored coins protocol in my view. On the other hand I
think one satoshi per unit is already too much so what can I say about
this.

I'll push in the opposite direction, but before saying anything on
bitcoin-dev, seriously, guys, what am I missing?
It feels like it's something terribly obvious for everyone else.

On the parallel topic, "intrinsic value" is like saying "intrinsic
measure": something absurd.
The verb came first and later the noun.
Specially in the case of money, which is just a symbol of value. Money
is really a language, not a commodity.

A group value it first, then it has value for that economy.
Gold is really about anti-counterfeiting, like it's state paper. But now
we have hash chains that change everything and doesn't necessarily
have to be flawed in the same way those two are.

[Alex Mizrahi]

I still don't understand the attack they're trying to prevent.

Can't "micro-outputs" be left in disk with the rest of the chain?

Well, the idea is that UTXO set must be in RAM because you want might need to be able to verify large number of transactions per second. (For example, due to a DoS attack.)

One HDD can do at most 200 random reads per second, so if you keep UTXO set on disk you will easily get saturated.

( I believe it is possible to redesign how mining system is structured and/or redesign protocol in such a way that UTXO set size won't be a problem. (See here: https://bitcointalk.org/index.php?topic=153662.0). But it looks like devs find changes too scary, they just want to keep implementation as simple as possible. )

 

Can't the paging of the UTXO be made so that spending a micro-output
only causes a fail in the memory paging and you can relegate those
"economically non-sense" outputs to disk?

Well, you don't to get your mining system thrashing when you receive  a flood of transactions, do you?

 

You're paying the fee for it.

You're paying a fee to keep data on thousands of systems forever. What will be the price?

[Alex Mizrahi]

Well, the idea is that UTXO set must be in RAM because you want might need to be able to verify large number of transactions per second. (For example, due to a DoS attack.)

One HDD can do at most 200 random reads per second, so if you keep UTXO set on disk you will easily get saturated.

I totally botched that sentence...

Here's the situation miners do not want to get in:

1. They get flooded with a large number of transactions. (Possibly due to DoS attack.)

2. They need to fetch UTXO for each input.

3. If UTXOs are on disk, disk is saturated with I/O requests, so you cannot process transactions as they come.

4. Thus you have to drop incoming transactions.

Here's why I think it isn't a problem:

1. You can really ignore all transactions which have inputs not in UTXO set you have cached in RAM. Nobody says that each node needs to process all transactions.

2. You need to verify all transactions which are included into a block. But at that point DoS is already ruled out (because it would be too expensive), so you can just take time and fetch missing UTXOs from disk. Number of transactions in block is finite so you're guaranteed to finish verification in a finite time.

3. In theory, if some asshole will mine a block which consists solely of dust, so it would saturate I/O capabilities of most miners, that block will just take too much time to get verified, and will likely get orphaned. So there is an incentive to include only small amounts of dust into your blocks.

[Jorge Timón]

On 4/27/13, Alex Mizrahi <alex.m...@gmail.com> wrote:
>> You're paying the fee for it.
>
>
> You're paying a fee to keep data on thousands of systems forever. What will
> be the price?

Transactions that "make economic sense" will also be stored in the
chain for life. Fees are the only anti-spam tool available.
If miners chose not to charge enough, an attacker may make them
process a thousand ping pong coins moving perpetually between two
accounts and only using transactions that "make economic sense".

On 4/27/13, Alex Mizrahi <alex.m...@gmail.com> wrote:
> 1. You can really ignore all transactions which have inputs not in UTXO set
> you have cached in RAM. Nobody says that each node needs to process all
> transactions.
> 2. You need to verify all transactions which are included into a block. But
> at that point DoS is already ruled out (because it would be too expensive),
> so you can just take time and fetch missing UTXOs from disk. Number of
> transactions in block is finite so you're guaranteed to finish verification
> in a finite time.
> 3. In theory, if some asshole will mine a block which consists solely of
> dust, so it would saturate I/O capabilities of most miners, that block will
> just take too much time to get verified, and will likely get orphaned. So
> there is an incentive to include only small amounts of dust into your
> blocks.

Ok, so basically you would additionally need to ignore the fails in
the RAM UTXO during a DoS, but I'm not crazy.

I would say there's no real change required in the protocol, only
miners need to improve their clients. Although a fork could be made to
improve the storage, in a way that the part of the UTXO that's not in
RAM doesn't have to be duplicated on disk and can still be efficiently
accessed. With content addressable storage I would say you just need
to make the outputs and inputs the leafs of the merkle tree. That
would be also good for thin clients.
Currently leafs are transactions, right?

[BlueMeanie]

 Hi Stan,

  I think the best working model we have is 'desire to transact'.  From that basic commodity, BTC's value is derived.

 -bm

[BlueMeanie]

On Saturday, April 27, 2013 2:40:42 AM UTC-4, Alex Mizrahi wrote:

 

  In my earlier proposal I suggest the DNS system be used to identify a Color ie. Asset Class.  Not only does this basic mechanism offer many useful OoTB features, but it gives us yet another useful quality: Asset Taxonomies.

  So a coin is identified by a DNS name:  mybonds.bluemeanie.com .  They are traded, exchanged, valued, etc. like you would expect.  However there are many types of bonds that have different properties.  How do we manage this?  by using DNS!  it's simple.   issue1.mybonds.bluemeanie.com , zerocoupon.mybonds.bluemeanie.com , etc.

Same can be done without DNS. DNS is like a fifth wheel here.

You know, information about issuance is just information, it can be contained in any kind of a document or a database.

  Yes, you've mentioned this 'registry', have you given any thought as to how this would work?  is there a link?
 

 

   so in this system its very easy to make these assets APPEAR to be the same for the average low end user,

Well, it is entirely the matter of user interface.

  true, much of this standard lives in the GUI and does not interfere with the basic color coins protocol.  Different protocols could even work independently of one another without much destructive interference.

 -bm