Topic: Innovation in the alt chains (Read 6176 times)

That has been the plan of many groups. If and only if merged mining does prove to work as a way of securing additional chains is there any point in exploring the potential of such secured chains. It is all pie in the sky if in fact merged mining is not an effective approach. Some other method, possibly such as sticking to a centralised system until transaction volumes generate enough fees to make the huge expense of mining start to seem budgetable, will have to be found if merged mining cannot do the job.

-MarkM-

I think _making_merged_mining_possible is much easier than innovation.

Do _merged_mining firstly !

I don't like the pump-and-dump actually. One of the key problems of creating value in blockchains is the mining of coins by miners problem, which is what leads to the dumping. It puts the thing you are hoping to use as value in the hands of those who basically seem to do their best to devalue it, which is kind of counter-productive.

-MarkM-

People who didn't do their work in secret have been told that simply going merged had these kinds of risks.  It is not everyone elses fault that you didn't talk to people or realize this for yourself.

Merged mining namecoin has worked out really well, because namecoin already had value— the economics were different.

You could achieve acceptable security in a new merged mining chain at its valuless birth in quite a few ways... off the top of my head:

* Pre-announce it and build excitement well in advance, convince people of its values, make sure it scratches their itches— and then when it switches on there will be a lot of people supporting it and it will be well decentralized.  (Litecoin did a bit of this, but it could be better done than that)

— but doing this will require some real value from the start.  Beating the bitcoin developers out of the gate in deploying new functionality they invented and coded probably won't cut it.

* Start with an initially high difficulty, so that the system doesn't do much (and thus can't be attacked much) until it has a reasonable amount of decentralization.   (bitcoin itself did this, though it could have done more of it— while diff 1 sounds low today, computers and esp. software of _a lot_ faster, though the big MMed hash concentrations make this harder)

* Reduce decentralization initially— program it require frequent signed checkpoints (or something like SC2's alternative blocks) _until_ the system has a high enough difficulty to stand on its own (enough is easy to figure out for a merged chain, since you know how much hash power is out there), or until a certain number of blocks pass.

or

* Raise some BTC and pay existing miners on the merged chain to cooperate, until your chain is big enough and worthwhile enough to survive on its own merits—  setting up a new merged chain has a cost, a fairly high one right now because the support is not well integrated. Your own system didn't work with a lot of popular software. You can't expect disinterested parties to just mine your coin because its easy to do so, — hell, for most pools mining it requires writing new code. So you get only the interested parties and with that comes good and bad.

The last is probably the most interesting, simply because for any decenteralized system which doesn't claim to be a deflationary (or at least effectively deflationary for early adopters in the short-medium term) currency, externally paying miners to support it is probably the only way to bootstrap.

Though, you may note that all of these tactics reduce the ability to pump and dump new clone-coins.  I consider this a ecological feature, rather than a bug.

(To be clear— I don't have reason to think _you_ were trying to build a pump and dump altcoin scam, I don't know what you thought you were doing— but _other_ people in the altcoin community were super eager to participate in one, and I think the evidence is basically clear enough on that. It just turns out that they care so little about doing so, or are so greedy about it, that they won't put in the resources to undo the attack against coiledcoin)

It looks like it is premature to waste time "innovating", we should first just clone as many identical chains as merged mining can practically handle, get them all up to difficulty matching bitcoin's and only *then* worry about which ones to make which changes to to develop various innovations or changes.

Until we actually have a whole string of secure chains to innovate with, speculation as to what innovations might prove good is kind of moot. First lets actually secure some chains. If we can do that, fine, we can look into varying them from each other. If we can't its a doomed route anyway.

Most of the people who were looking forward to merged mining as a proof that innovation might have some chance of having a point or usefulness are seeing so far that, sorry, merged mining is no help, any attempt to innovate is going to have to wait until some other way of solving the terrorist / religious fanatic / mad bomber attack scenarios before there is any point wasting thought on it.

-MarkM-

This, in spades.


That sounds like an arbitrary size payload for a decentralized wallet. The data volume would probably be unwieldy, though.

What I've noticed so far is a singular focus on monetary and technical aspects. That's all well and good, just somewhat limiting in regard to applicability of the whole concept.

The Bitcoin community seems to have finally come down from its honeymoon high and is regaining credibility. Awareness is the first hurdle, then a thorough understanding of what the blockchain is. Finally, the ideas start flying as to how it can be applied elsewhere. The real power, when abstracted to the blockchain's raw potential, is the system's capability of self-management.

I think innovation will come when either academia takes notice and/or when private, commercial interests pick up the ball and run with it (which seems to be the situation with maaku). That does seem to be picking up, two-guys-in-a-garage style, but still mostly focused on financial aspects. The concept can be made general, like the wheel - it just has to build up that gradually-accelerating adoption cycle.

Namecoin appears to be the most innovative so far, although there are plenty of applications involving resource management that could be handled by a blockchain system. I've been pushing the potential for blockchains effectively being applied as decision machines, similar to the threshold trigger of an action potential. That could form the foundation of a machine memory/intelligence at a larger scale and in a completely different class than existing paradigms. Difficulties in starting that lie with incentive for participation and logistic overhead - feasible at experimental scales but not workable in the global setting that Bitcoin can support yet (due to financial incentive).

The more freedoms and privacy are eradicated by central authorities, the greater the incentive to explore other options. It's only a matter of time before further dots are connected - 2012 will be more impressive than the last couple of years, I'm sure.

It'd be more fun if you'd assume the latter so that I can ask this question: if an incompetent programmer writes a piece of software in which "entire classes of security bugs are missing" (according to Kaminsky) then what does that say about your conception of programming competency?  Or, is it the case that Gavin et al crushed whole classes of security bugs that were in Satoshi's early clients?

Indeed, I understand it can be troublesome later, but at least it prevents BTC from being headless like NMC...

The tight coupling is "bad" but acceptable for a proof of concept.  However IMHO today the daemon and client should be two completely different projects.  Sadly the legacy of that tight coupling is w/ us today and it increases the innovation and development cost.

I was working on a high security smartcard key manager (private keys would never exist outside of smart card).  The tight coupling between the satoshi client and the daemon would have required massive rewrites to accommodate a wallet w/o private keys.  Far more than I was capable of willing to do.  Not only the work now but any breaking change to the daemon or wallet would require never ending modification.  No thanks.

I have recently revived the idea using electrum.  Since the "server" (essentially just a remote copy of daemon) can be completely decoupled from the client I can write a custom client which talks to electrum server.  This server could be running locally to provide "fat client" functionality.  It is a step in the right direction but results in a lot of work duplication.

ArtForz hits my main complaints. As I said, either very rushed or not very competent. Given that we don't know the facts I'll be polite and assume it was the former. Maybe he really rushed to meet that new years deadline three years ago.

Tight coupling between UI and core (somewhat reduced with 0.5), Horrible OO design in parts, data members being public in lots of places instead of having accessors, sometimes outright WTF-worthy approaches to doing things. I wouldn't say incompetent, just lazy/messy.

What does "not a very competent programmer by industry standards" mean?

a) So you solved it.  Don't change addresses.

    1VayNert3x1KzbpzMGt2qdqrAThiRovi8: 36.226

    1VayNert3x1KzbpzMGt2qdqrAThiRovi8: 32.226
    1FBtYpdAm4YhEFW4Upb3LE2wVRHVMEbZZs: 4
  
As long as you send it back to address, no fee charged.  Fee above would be 0.08

b) The fees will be large and growing.  BTC might be $15 by now resulting in 10x the transactions.  A CPU algorithm would spread the mining around.  Possibly even pool-less share based mining to protect network to prevent it being concentrated.

c) You are still going to have to pay 38% income tax even with bitcoin.  Those are federal/state/country laws.  With a 2% tax, 1% is given back to the public as deflation.

d) A definition of inflation is the increase in money supply.  All national debt has a dollar behind it.  When the postal worker received his check was that real money?  There is a reason why M3 closely follows the national debt.  Price inflation if you compare the Year over Year change in revenues at Walmart and Exxon-Mobil you come to over 8%.  If you subtract out population growth and productivity gains you might have 5% price inflation.   However, you must also consider without subtracting those out we could have 5% price deflation.   Many economist use a 18 month lag in M1 as a predictor of inflation.  The zero month lag in m1 is about 18%, and the 12 month lag is about 8%, and the 18 month lag is about 5%.  

The numbers result from the current subsidy equivalent to a 7-10% tax on each send. These fees are not sustainable and thus the current numbers are irrelevant.

Instead of going over these red herrings again, let me discuss the substantive issue.

Like you say, capture of a large share of currency value through double spends is implausible. The value of the currency would plummet shortly after network control passed to the attacker. Most of the network value would be destroyed rather than passed to the attacker.

However, this statement has nothing to say about f''(x) at all. Really the point you are making with this statement is that a txn network does not need to be very secure in general. Size is not relevant to this argument. I have no idea why you think the ratio between 'viable double-spend targets' to network value would decrease as the network grows. The lack of a need for security against double spends might hold just as much for a small network as for a large network (in fact I expect this is the case). For example, one year ago, there would have been very few attractive places to double-spend. Now there are people selling gold bars and such. I agree you couldn't make much doublespending these places, but you could not of made anything at all double spending one year ago. Are you sure that the ratio of double-spend opportunities to network value has gone down?

More importantly, I strongly doubt that any attack would be motivated by double spending profit. In other financial markets, it is possible to take short positions with valuations larger than those of the underlying asset (via derivatives). Why are you sure that an attack won't be motivated by a speculative play like this? Furthermore, an attack might be carried out by the owner of a competing txn technology. Paypal, for example. A competitor's motivation to attack the network would likely be directly proportional to the amount of txn business captured by bitcoin, i.e. f''(x)=0.

You might be right about f''(x). It is really an empirical question. However, the confidence you express with statements like "Really?" and "Seriously?" is rooted in ignorance and bluster rather than logical reasoning.

I tire of this discussion, see you in other threads.

Really?  How large of an economic impact do you think a double spender could make.  The only way that is true is that as the network gets larger the economic value of any double spend grows perfectly with the size of the network. 

Network today is $150M in annual transactions,  $10M in cost to perform 51% attack.  There is a 15:1 multiple between annual transaction volume and cost of an attack.

At the multi-million dollar scale, there is a finite amount of double spend targets.  Even if the annual transaction volume was $1.5B a year and cost to perform a 51% attack was "only" $50M (30:1 ratio instead of 15:1) how many places do you think one could perform a double spend to cover your costs ($50M).  To cover $50M in costs would require $100M in double spend value ($50M in attack cost + $50M in capital to "double").

Just because the network is that large doesn't mean the economical attack space is that large.

There are very few areas one could economically attack the network at that scale.  One would need
a) irreversible goods
b) untraceable goods
c) convertible goods (doubt someone wants $51M in alpaca socks)

Finding >$100M in targets would be much harder than finding $10M in targets.  Remember the window of attack is relatively small.  One can't slowly attack the network over the course of a year.  Finding sufficient "target goods" to cover the cost becomes increasingly difficult despite the economy growing.  So as long as the "viable double spend targets" grow at a smaller rate than overall economy the capacity necessary to make 51% attack uneconomical will shrink as a % of transaction volume.

This is only place where you discuss incentives to perform an attack. Again, you are saying f''(x)<0. I'm saying that there is no reason to be so sure. It could be f''(x)=0 

The other stuff is irrelavant.

That's silly.  Transaction fees (and subsidy currently) buy the network we have today.   

Imagine today there was no subsidy and thus all transactions had a 7% fee.   Annual transaction volume is ~40 mil BTC ($160 mil USD).  7% of today's transaction volume is ~$10M.  $10M annual revenue buys us the ~10TH network.   It doesn't matter if it is $10M in subsidies or $10M in transaction fees or a mix of both.  Now the nominal value of the network isn't that important.   In 3 years $10M in annual revenue will likely buy a 30TH network (due to Moore's law) but it won't be any stronger than today.  In today's dollars (and today's computing hardware) it costs about $1M in annual fees to rent 1TH of hashing power.

Now imagine the transaction volume increased by a factor of 10.  Transaction volume is now $1.5B.  To pay for the same 10TH network would require only $10M / $1500M = 0.7% not 7%.

Alternate method (transaction volume in transactions)
It is entirely possible the network will ignore transaction size (because due to the anonymous nature it is impossible to know the intended size of any transaction).  Instead the network would require a fee only on transaction physical size (kb).  For simplisity sake we will look at the cost for average transaction.

Today the network has roughly 0.1 tps that is ~3 mil transactions annually.  To support a network costing $10M would require a per transaction fee of $3.33 with smaller (physically smaller) transactions paying less (maybe down to half price) and larger transactions paying more. 

The same $10M results in a falling transaction fee as volume increases
0.1 tps (3 mil annually) - ~$3.33
1.0 tps (31 mil annually) - $0.33
10 tps (310 mil annually) - $0.04
100 tps (3 bil annually) - 0.4 cents (roughly paypal network sized)
4000 tps (126 bil annually) - 0.01 cents (roughly VISA network sized)
 
Now one can argue a larger network is necessary to protect a larger transaction volume.  While that is true there are a couple points to consider.
1) The network today is significantly oversized.  10TH is very powerful distributed network.  It is the larger and most powerful computing network in the world.

2) There is a non-linear relationship between transaction value and network necessary to provide security.  If the network was 40,000 times larger (in terms of transaction value) we would hope the network would be stronger but it is unlikely it needs to be 40,000 stronger.


I agree a hybrid of proof of work & stake would be more efficient however Bitcoin has first mover advantage.  It doesn't have to be superior to newer alternatives simply "good enough".   Good enough w/ sufficient critical mass has won out over technically superior a multitude of times.

Let f(x) be the reward from an attack as a function of network value x.
It should be obvious to anyone that f'(x)>0. However, the second derivative of x is not so obvious.
Death&Taxes argument depends on this second derivative.

He assumes that f''(x) < 0, so that attack rewards are a concave function of network value. f''(x)<0 implies that the network security - txn fee relationship becomes more favorable as the network grows. However, I have not seen any empirical evidence or cogent theory supporting the claim that f''(x)<0. If f''(x)=0 (a linear function seems probable to me), then the size of the network does not affect the network security-txn fee relationship at all. In this case, a 7% txn fee (or something similar) will be necessary forever.

If f''(x) >=0, proof-of-work is a poor choice of technology. In this case, proof-of-work will eventually be supplanted by either pure proof-of-stake or a proof-of-work/proof-of-stake hybrid.

Anyone implementing an alternate chain should consider this carefully.  

I can't code at all, so don't tell me to put up or shut up. Off-hand rejection of the views of outsiders is idiotic.

OP_EVAL will probably be coming to DeVCoin (and GRouPcoin) along with the update to the current bitcoin codebase.

-MarkM-

Orly? That'd be interesting to see.