You forgot to re-login, Garr.

I believe the only viable approach is to parse blokchain sequentially up from the first block which includes a mastercoin-relevant data, and to maintain state in a database of sorts, which notes how much each address holds now, etc.

Going from another end, i.e. backward scan, is pretty much impossible. While forward scan is almost trivial.

"Almost" because existing tools, like ABE and blockparse, are optimized for scanning whole blockchain rather than a part of it. But it's possible to deal with it by "throwing hardware at the problem". (Or another approach is to modify tools, or use ones which are better.)

My point is that we can associate performance requirements with block size rather than with UTXO set size.

If you think about it, it makes more sense: block size limit is the part of the protocol. It is something which can be controlled, and is being controlled now. But UTXO set size might be as high as 21*10^14, and controlling it is rather problematic and non-trivial.

So it is possible to design software in such a way that block size limit will dictate hardware requirements for full nodes. If there is a need to increase throughput, block size limit will be increased and hardware requirements will be adjusted accordingly.

So you can just tell full nodes maintainers which hardware they need to keep up with blockchain growth. It will give them peace of mind. Isn't that nice?


You can prioritize them by value. E.g. if size of 1 UTXO  in memory is 100 bytes, storing 21 million entries requires only 2.1 GB, and thus you can easily guarantee that all UTXOs which have at least 1 Bitcoin in them will never be flushed away.

If you have 1 MB block size limit and each input is approximately 250 bytes, you only have at most 4000 inputs per block.

Thus you only have to buy hardware which can do ~400 random reads per second if you want to spend no more than 10 seconds to verify a block.

I'm fairly certain you can do this with 4 ordinary HDDs if they can do reads in parallel.

Or you can buy a SSD, pretty much any device can do more than 10000 random reads per second.

As for inputs in transactions not included in blocks, you can just drop ones you cannot fetch in a reasonable time. There is nothing wrong with dropping transactions.

They say MasterCoin has an advantageover copycats; just like Bitcoin has advantages over "alt-coins".


MasterCoin and "colored coins" use different approaches and implement different features.

Within 'colored coins' approach we use Bitcoin transaction graph, and state changes are localized in the sense that one transaction cannot affect another transaction which doesn't depend on it.

MasterCoin's approach is different: there is a global state, and MasterCoin transactions are processed sequentially, in the order they appear in the blockchain, and the modify the global state. This is absolutely necessary because many MasterCoin features absolutely require global state.

J.R.W. believes that these features are very important, and for this reason colored coins are not suitable for what he is trying to do.

These features, their importance and possibility to accomplish same goals though other means are out of scope of this discussion. (I'll just note that it is possible to implement arbitrarily complex rules through 'oracle' or 'operator' of some sort, then the only concern is trustworthiness of that oracle and possibility of recovery from malfunction.)

Anyway, the MasterCoin's paradigm is: there is a list of messages (commands) which are reliably timestamped (i.e. all actors agree on their order) and carry authorization information (are signed with corresponding private key); messages are processed in order and each one affects the global state.

It's quite obvious that the Bitcoin blockchain is used for two things here:

1. Message timestamping, i.e. blockchain ensures that everybody sees these messages in same order.
2. Message storage and distribution.

It is possible to decouple these things: use Bitcoin blockchain for timestapming, but keep messages in some other place.

In the idea case (if our goal is to minimize the bloat) it's possible to keep only root hash in the Bitcoin blockchain (one hash per block), and messages themselves can go either to some alt-chain, or to DHT, or whatever.

Obviously, such a change will affect many aspects, so it won't be exactly same as the current form of MasterCoin, but all important features will be preserved.

I really doubt J.R. is willing to organize it in such a way, as he wants to make it possible to use ordinary Bitcoin client to send MasterCoin commands.

There is a quick and dirty way to modify it: move to some merged-mined alt-coin, as is. Most Bitcoin clients can be adapted to work with an alt-coin.

However, J.R. believes that MasterCoin is beneficial for Bitcoin, so there goes an opportunity...


Eh? How do colored coin clients know which outputs were the colored coins then? They sort of need it to show balance etc.

I believe no more than a couple of days of work, if you know what are you doing. Likely less than that for a person who is very familiar with the client codebase, data structures etc.

So, yes, it makes sense to do this from the start.

I guess you misunderstood me, it's not about buying Freicoins below market price, it is about bringing market price up to that level... One person cannot do that, but you bring investors' attention to it and explain how Freimarkets can make Freicoin much more useful than an average alt-coin, investors will be eager to invest into the next big thing...

Jorge mentioned that alt-coins can simply copy Freimarkets, but it's not so simple... It really matters which coin is endorsed by developers, as that one will, likely, get all the necessary maintenance, latest features, security fixes, etc.

Technically speaking, it could work without funding from Foundation, but we get a prisoners' dilemma-like situation. For each individual, it isn't rational to donate anything, even though if everybody donates a bit all would benefit from it. So you gotta depend on altruism... Or use a mechanism like Foundation, which you cannot use.

OK, this makes sense.

But I don't think that "binding" is the right word here. Perhaps you could describe such orders as 'autonomously executed' as they can be executed even if one who submitted them is offline. But "binding" implies that somebody is forced to stick to his order.

This is funny... Suppose Freicoin is wildly successful, and total monetary base is equivalent to 10 trillion 2013 US dollars.

Then miners get 500 billlion USD worth of Freicoins each year, and, due to the way mining economics works, they'll burn equivalent amount of energy (and pay for amortization of equipment). This is wasteful on epic scales.

On the other hand, Freicoins which Foundation gets now are worth pennies...

Do you see what I'm talking about? IMO it would make much more sense to give all created money to miners, but send 80% of demurrage money to Foundation.

This way you could redirect money miners are going to spend on electricity to charity... Potentially that might be a large sum each year.

But you did exactly the opposite...

Well, Freicoin economics in general looks completely alien to me. I guess it works in mysterious ways... Good luck with that.


Yes, but nobody have offered anything on scale of $100k so far... If they did, we could actually hire people and get it done. Instead, we have people who work in their free time... As you can guess, progress is kinda slow.

However, colored coins require much less work than Freimarkets.

Well, it would take a while for me to review this...

One the first glance, one thing I didn't like is "binding" orders. If they can be double-spent, they aren't really binding...

Mempool rules are not enforced, they depend on miners being good guys and running non-modified node software.

You know about replace-by-fee patch, right? https://bitcointalk.org/index.php?topic=179612.0

I don't think that mempool rules will be relevant in future, as they go against what game theory suggests.

Freicoin Foundation gets 80% of all mined Freicoins.

I thought it's supposed to finance further development of Freicoin, why are you looking for external donations then?

Is that because price of Freicoin is too low? (i.e. sum which  Freicoin Foundation is able to donate isn't enough for this development.)

Or is that the case that Freicoin Foundation cannot donate towards this?

If the former is the case, perhaps you can do fundraiser in a different way:

1. Suppose Freicoin Foundation agrees to donate 1 million FRC to this. (Which is only ~1.25% of all funds it will ever get.)
2. If your fundraiser goal is $125k, then it works when exchange rate is 1 FRC = $0.125 USD.
3. So you just ask investors to buy freicoins up to that point. Currently it is equivalent to FRC/BTC being 0.00125.  Which is not absolutely ridiculous because it was traded around that price when it was first introduced on vircurex.
4. Perhaps you can offer these investors a deal to sell them Freicoins for 0.00125 BTC each even if market is above that. (I.e. offer a forward or call option contract.)
5. Investors might see returns on their investments when Freimarkets are implemented.
6. I don't think it costs that much to bump FRC exchange rate upwards... Currently you need only 87 BTC to eat all asks below 0.00125 on vircurex... Of course, more asks might appear in process, so don't do that at home.
7. In any case, investors find buying something much more palatable than donating towards something. Even if investors need 5000 BTC to finance this endeavor this way, it is still easier than to collect 1250 BTC in donations.

HTH

EDIT: Disclosure: I bought some Freicoins, but I'm not going to donate them to you guys, sorry.

Wat?

There is a plenty of routers which work with OpenWRT, it really isn't a problem to buy one, and they cost about $100.


Routers supported by OpenWRT: http://wiki.openwrt.org/toh/start

Well, the general idea is that it is possible to install fairly normal Linux distro on the most of such devices, some people even managed to run Debian.

I.e. you aren't restricted to the version vendor provides if open source drivers exist, you can use whatever you want.


Yes, they have less memory and significantly slower CPU...

However, there are high-end models with 256 MIB of RAM, that should be enough for all networking-related things. And then you just need to avoid bloated software...

There are also business-class devices which are more powerful, e.g. D-Link DSR-250N has 1 GiB RAM on board, costs $200: http://www.newegg.com/Product/Product.aspx?Item=9SIA0AT0FS2746

I think Atom-based wifi spot makes sense if operator wants to host some additional services on it. Otherwise installation on COTS routers makes more sense.

This is cool, but I don't see a reason why it cannot be done with a regular wifi router (e.g. Asus RT-N66U) with customer firmware, which will be quite a bit cheaper.

People often say it like BASIC-MINING is the best investment ever, but I'm afraid they (and you, specifically) just do not understand Bitcoin mining economics;

Currently difficulty increases at a very fast pace, like 30% each 10 days. This is insane, you have to increase your hashrate 30% just to mine same amount of Bitcoins per day.

Of course, buying 30% more hashing power costs a lot. Currently BASIC-MINING has money to do this, but it cannot do it indefinitely.

E.g. suppose currently it costs 100 BTC to increase hashing power, in 10 days it would cost 120 BTC, and so on. If current reserves are 800 BTC, they will last no more than 80 days.

On the other hand, P/E suggest that investors assume that BASIC-MINING will be able to pay approximately same dividends at least for 4 years.

This means that share price is about 10x higher than it should be. But I'm afraid you people will only understand it in a couple of months when reserves will dry out.

Do you mean that full rescan of blockchain is needed after each reorg?

Bitcoin nodes handle reorgs much more efficiently.

The only reliable way to find all transactions which mention certain address is to scan all Bitcoin transactions.

So this doesn't buy you anything: you still need to read all transactions in block, parse them as Bitcoin transactions, checking whether they mention exodus address. If they don't you can skip further processing step.

This doesn't improve scalability. Maybe you'll have processing twice faster if you avoid "multipart" transactions, but processing time/download time is linear on number of transactions in blockchain.

You might be able to fetch only transactions which mention exodus address if you use centralized service like blockchain.info, but then you will depend on such service. For example, such service might omit a transaction to perform a double-spend on you.

---

If you only consider 'full node' clients (or ones using similar design), you should be concerned with what they need to keep in db and what changes they need to apply to it, not with number of transactions processed, since full node clients need to process all transactions anyway.

Say, what do you do in case of reorg, i.e. how do you unwind the state back to the point it was N blocks ago where fork happened?

One way to do this is to keep track of all changes to the state, but then you'll store the whole history...

This isn't related to Moore's law in any way. We simply know that a lot of ASIC mining devices are being manufactured, and many of them will be more efficient than the current generation.

Extrapolation simply gives you an idea how fast this process is.

We are talking about what it would be years from now.

Let's say difficulty increases 10% per week, in a year you'll have 142 difficulty increase. So if electricity costs are only 0.7% of mining revenue now, in a year they will be 100% of mining revenue, and it will be no longer profitable to mine. (Assuming Bitcoin price doesn't change.)

Now, the thing is, difficulty increases much faster than 10% per week now.

All in all, it is extremely likely we'll get there by the next reward halving.

I find it hilarious that you wrote "still" when we are at the very beginning of ASIC deployments and situation changes each week.

"Mining is no longer profitable" means that electricity costs are higher than what you get for Bitcoins it mines.

It is expected that future generations of ASIC chips will be much more energy-efficient.