Thanks for pointing me to OT, it looks promising, at least in the purely asset-backed sense of the proposed GoldCoin.  I'll think about how attached I am to the idea/fantasy that the new currency's Bitcoin-like properties might come to dominate its value and render its gold backing obsolete.

Cross-posted, modulo a few changes: https://bitcoin.org.uk/forums/topic/306-ideas-for-goldcommodity-backed-cryptocurrency/

Cool!

Further elaboration of the GoldCoin / {Insert Commodity}Coin idea in this thread: https://bitcointalk.org/index.php?topic=24714.msg523685#msg523685

It'd be nice if GoldMoney sponsored a block-chain currency with units backed by gold.  They'd control the issuance (no block solution rewards--only transaction fees for mining) and promise to buy the currency at a certain rate of gold.  (The rate would decrease slowly over time--or the chain would need demurrage--in proportion to the gold storage costs.)

If I were to do this, I'd design the GoldCoin chain with a shared proof-of-work system (merged mining) from the outset to defend against 51% attacks.  The currency would not be decentralised the way Bitcoin is, but if successful, it might rise in value enough to dwarf the underlying asset and become de facto decentralised.  The gold backing will have been be just a bootstrapping technique, an advancement over Bitcoin's 50 BTC block generation reward.  To compensate for the cost of mining (low due to shared proof) during the early stage, the gold holder would simply pay miners, perhaps via a mechanism much like block rewards.

The software would recognise some special keys as belonging to the GoldCoin issuer.  We'd need an incentive for miners to include messages signed by them, such as new issuance transactions.  (GoldCoin units would be created only upon transfer of the corresponding amount of gold-backed currency to the issuer's dedicated account.)  I'd write the software so as to regard a block containing an issuer message as "higher" than one without it, thus expressing users' desire to receive the messages.  Other official messages might include price quotes, software or protocol upgrades, news, etc.

Exchange between the digital gold currency (DGC) and the cryptocurrency could be fully automatic.  Transfer your DGC to the official account with your address in the memo, and the GoldCoin issuer promises to issue new currency to that address.  Send your GoldCoin to a specially formatted address, which encodes your DGC account number, and the issuer promises to deposit DGC at the current official rate.  If the GoldCoin issuer and the DGC issuer are one and the same, there is no additional trust issue beyond trusting each currency.

GoldMoney won't do this or allow anyone to do it with their DGCs due to regulatory concerns.  Perhaps one of its competitors will.  Pecunix?  Liberty Reserve?  I post this partly in the fear that GoldMoney will patent the system and prevent its implementation for 20 years.  Of course, the same system could work with commodities other than gold: silver, cash, baskets of commodities, etc.

Abe is designed to record it, though it currently lacks a web interface to quickly look for chain splits.  The slow way is to look for blocks with more than one "next block" and follow the "next" links.  Anyway, I look forward to some nice test suite material.


I'm scratching my head over this conclusion.  If you publish a block 19200, merged mining happens, and very likely the whole network overpowers the attackers.  So you must plan on indefinitely preventing the chain of greatest work from having over 19200 blocks.  Perhaps by messing with the difficulty, shoot it up high for a low-numbered range, so high that the new chain has greater work than the current one, so you push the current block number back a few thousand.  Then stop mining the tip and let the public network dither (as it's currently doing) while you prepare your next "longest chain" at an even lower block height.  Etc.

Still a lot of ongoing work and expense, though admittedly, I have to read up on the ArtForz exploit you mentioned.  And if the Namecoin developers come up with a fix (even something as simple as checkpoints or MM start block tweaks) you will declare victory and move on, right?

I don't think it's a bad attack.  Thanks for giving everybody the heads-up.

Yes, on to merged mining please..

Monitoring this thread as I build a g++ capable of building libbitcoin.

Meditating on "block-chain verifier subsystem."

Backpedaling... log showed 90% of requests from Googlebot.  I'm attempting to solve this with robots.txt.  Site is up for now.


It wasn't getting a lot of hits, roughly 4 address or tx requests per minute.  The VPS's swap space was chronically all used, though, causing the kernel to kill processes roughly once per hour, despite my cron job that bounced Apache and bitcoind every hour.  So it was thrashing, and Postgres must have had to read from disk for most queries.

There's certainly room for optimization in the schema, especially if you have plenty of disk, which I don't.  But before I go that route, I'd like to know what's possible with a server with 1GB+ RAM.

By the way, if you want to hide the "empty" currencies from the homepage, you could delete the respective rows from the chain table or upgrade to the latest 0.7pre.

If you set up an instance with BTC, at least one alt chain, and better uptime than mine, and if you are willing, I will advertise it as the demo site.

Yes, the samples I looked at reused the 0.01 coins.

I've taken down abe.john-edwin-tobey.org due to heavy load.  Email me or post here if you have server space and want help setting up!

Can you cite a source for this assertion?  It looks to me as if the attack cost less than 1SC in transaction fees and exchange fees.  A transaction (2cd9782cc39ab8b55...) took a 50sc input and divided it into 2,000 0.01sc and one 29.99sc outputs plus a 0.01 fee.  Later, a few dozen transactions moved about 2,000 inputs to 2,000 outputs, each of 0.01sc, and a 0.01 fee per transaction.  Am I missing something?  Abe query for large transactions: http://john-edwin-tobey.org/scbig.txt

Great.  Let me know if you try the Windows installer how it goes: http://pypi.python.org/pypi/Abe/0.6

PGP key: https://raw.github.com/jtobey/bitcoin-abe/master/doc/jtobey.pubkey
Key fingerprint: 413D 2920 B776 08D1 A867  232A 3CB0 B139 6A71 5348

Provided it does not complicate the core stuff.  Are you thinking of working on this?  You could do it at a high level of abstraction ("squid") or a very low level (store compressed pages in db, add "last modified" columns to tx, pubkey, and block records) or in between, perhaps some WSGI middleware.  If you are going for low level, some refactoring might be in order beforehand.

To get cache headers on static content, I simply use FastCGI and configure static-path to something Apache can serve directly as described in README-FASTCGI.txt.

Yes, I'm pretty sure you could mine Namecoin and SC this way.  (By the way, it appears VinceD is pushing for Namecoin MM to begin sooner, at block 19,200.)

But if Bitcoin and SolidCoin are to be mined together, something has got to give.

SIGH!     Why the FUD?

Everybody, if you haven't already, please read this simple description of merged mining (MM).  See also the design that it's based on.

No, you get only BTC.  You base much of your argument on this misapprehension.  Please go read up on MM and tell me if you still think I'm wrong.

I don't know where you get your numbers, but I can't see how a code change to accept MM would lead to a generation rate increase any more dramatic than what SC has already experienced.  It would take a while before most of the BTC network adds SC.  As CoinHunter is quick to point out, SC has handled hash rate swings well thus far.  Without merged mining, though, I can promise that SC will experience Namecoin-like hash rate swings based on price/difficulty versus BTC.  StableCoin's improved retargeting algorithm would help, but I predict 95-99% hash rate decreases in a matter of minutes, much greater than the "400%" mentioned so often by CoinHunter.

Price has to do with perception, so it is not an easy call.  But if you mean that MM would flood the market with SC, then I don't think so.  Fortunately, Namecoin is set to test the question, if it ever reaches block 24,000, so we'll see who is right.

I'm not sure what difference you see that makes MM right for one and not the other.  If you mean SC should let Namecoin be the guinea pig, I see some wisdom in conservatism, yes.  But long-term, there will be MM currencies, and the market will choose MM or non-MM, leaving the losing side to convert or wither.

No, merged mining does not link difficulties.  It's quite clever.  I'll wait while you read up on it. 

Exactly, but backwards.  In the absence of merged mining, as is happening to Namecoin, many miners will hop from currency to currency based on fluctuating price/difficulty ratios.  This hurts both currencies by increasing opportunities for 51% attacks and messing with block generation rates--albeit less so thanks to SC's innovation in that area.  With merged mining, miner configurations remain stable (as in StableCoin) and all currencies benefit from greater security.

Quite so.

Yup, just that.  No need to read SC source code to figure out magic number and address version byte, no need to touch Python code.  Just pass "--datadir ~/.solidcoin".

Btw, I've cut the stuff down a bit:

1. Merged mining.
2. Merged mining.
3. Alert user if nethash drops by c. 50%... oops! this happened already.  See #1.
4. Merged mining.
5. Tighten timestamp accuracy requirement.  Make miners run ntpd.
6. Design a new getwork/pool protocol that gives clients/members control of policy.
7. Alert user if a reorg with many hidden or old blocks occurs.

Pardon me if SC already does any of these.

Version 0.6 highlights:

• Python packaging; abe.py moved; run as "python -m Abe.abe".
• Big speed improvements (c. 10x) for MySQL and SQLite.
• ODBC tested successfully.
• IBM DB2 tested successfully.
• HTTP API functions: getreceivedbyaddress getsentbyaddress.
• Verify transaction Merkle roots on block import.
• Show Namecoin-style network fees and name transaction outputs.
• Adjust coins outstanding and coin-days destroyed for Namecoin-style network fees.
• Native SolidCoin support.
• Suppress display of empty chains on home page.
• Show the search form on /chain/CHAIN pages.
• Many minor improvements; see the Git log.

Next up are a couple of bug fixes and the test suite.  When the test suite passes, it is 1.0.

Relaying information:

I guess I'm a big proponent of merged mining, having contributed a section to Mike's seminal article.  Tightly entwined with Bitcoin?  I have about 0.1% of my wealth in BTC and have worked actively to support alternative chains.  I wrote the software behind SolidCoin's version of Block Explorer without knowledge of SolidCoin's existence.

I believe that merged mining would be good for SolidCoin and disagree that it involves "chaining" oneself to another currency.  It involves a few extra bytes per merged block header and nothing per "normal" block header.  No need to keep the whole Bitcoin chain around or ascribe meaning to the extra bytes.  They merely serve as input to the proof-of-work verification: a big nonce.