Such questions are why I ended up liking the simplicity of just counting the stake actually input into the coinbase transaction, combined with the "(coins * age)*0.8 + (hashes to some fractional power)*0.2" formula Cunicula mentioned in some thread somewhere (I haven't been able to find it again though so don't know where).

Compared to the vast majority of the material in the related or vaguely related threads, it seemed wonderfully simple.

-MarkM-

Depends... How many Alices, exactly, is he in contact with and how much each are they willing to pay for such a product and does Bob have to service the customers himself or will Alice pay them separately?

Lets call the Customer-service department organiser/business Charlie.

Who wants to be Charlie?

-MarkM-

Okay well if coinbase transactions are allowed to have at least one input other than the coins that come from nowhere then a simple way to accomplish this "signing with a stake" would be to take inputs. Just like you can output to umpteen addresses, maybe you could also input from umpteen addresses. People could thus pool together to contribute a stake, and they could even each be returned their stake (their input) among the outputs.

In fact, the actual miner need not provide any of the stake at all, it could all be provided by stakeholders, the miner might not actually even own any coins at all. They could simply be some computation-for-hire service who neither knows nor cares what their computing power is actually being used for. (Like Eligius's miners, maybe, and those who gang up on proportional pools by way of proxy pools?)

If nefarious pools can so simply get miners to send them hashes, maybe they can also get miners to send them stakes? Make payouts proprtional not only to hashes sent but also stake sent?

-MarkM-

So you pick an address whose balance you want to use as stake for the block you are mining, and sign the block with that address's signature to prove it is your stake not someone else's?

-MarkM-

Thanks! Which is the one block every ten seconds one? If that is GeistGeld that would be why I never bothered with it.

Those that used multicoin either directly or as base code put their actual default ports in the default .conf file they include, so I should also have grep'd for the values in the config files. Basically it looks that is the ones that didn't need to change it i nthe code because multicoin uses the config file to put all the unique to each chain data in so one executable can execute any of the supported chains.

At a glance it looks like the only 18333 : 8333 's in the greap that aren't multicoin-based are my newcoin and prgcoin things that aren't actually coins yet just templates to work on / work from.

-MarkM-

Plunk it down on what, exactly? CPUs? GPUs? FPGAs? ASICs?

Or will they cover the bases, so that moving our own wealth out of bitcoins into oh lets pick litecoins out of our asses to start with and see if someone is a criminal deliberately attempting to disrupt other people's networking and data recording - a computing or data crime of some sort maybe in some jurisdictions - or an honest investor honestly interested in helping us achieve the objectives of our many and various branches of the cryptocurrency movement by supporting and enhancing the value and security of everyon'es cryptocurrency holdings won't help us elude their grasping grasp?

-MarkM-

I guess stakeholder's don't want to prove their stake by holding it in the form of mining rigs, let alone also actually running those rigs, because then the larger their stake the more electricity they will burn until they get to be the monopolist who supposedly can turn off most of his rigs as long as he continues to visibly continue to aquire more and to keep up with the latest improvments in rig technology.

They would much rather offload the costs of being rich, since if it costs a rich person a larger percent of their riches to remain rich than it costs a borderline-poverty person to stay above the poverty-line well that is hardly fair is it? Rich people ought to be able to pay a lower percent, surely? Otherwise they might end up on an asymptotic climb instead of an exponential one and find they cannot afford to buy all the poor folk completely totally and finally or some such disaster.

-MarkM-

P.S. Quite likely the whole story about how the monopoly ends up taking control applies to any particular money too anyway, so that no matter what we use for money someday someone will "win" and we should then basically say okay that was fun, challenging game that was, now lets put that game away and start a new one. We all aknowledge the guy who owns 51% of the wealth as the winner, write them into the history books as the great winners of the that kind of currency period of history, and start over with some other convenient scorecard/scoreboard...

Bitcoin-qt was fine when John Smith wrote it, having it absorbed into the main bitcoin bundle just serves as a potential distraction from the important part, which is bitcoind.

I can understand that it was probably easier to pull it into bitcoin because it was so inextricably entwined into the internals that probably ought to be bitcoind's business only and not concern clients whatsoever, but still, bitcoind - the actual core protocol code - is what the core team should be working on and allowing the GUI GU GUI oh shiny wah wah where's my GUI I can't read nor write I gotta click click click crowd divert attention from the core stuff happens too darn often in too many things.

Maybe when Armory takes off qt can be deprecated until someone unravels it from bitcoind so it can run separately as a front end using an API to interface with the actual protocol.

-MarkM-

P.S: When I run stuff as another username in text mode, it cannot read my keyboard, scrape my screen, track my mouse movements and so on, as far as I am aware. Whereas if I let it have access to Xwindows (my GUI), it can do all those things, last I heard... Thus encouraging people to use a GUI for mission-critical financial applications seems a bad idea. (No wonder they get their wallets stolen? Their passwords are visible to any trojan they allow to access their GUI system? Does that apply to Windows GUI also?)

Probably just an example really. I want to add more and more chains to my merged mining to see just how many chains one actually could merged-mine all at once, so I need to whip up a bunch of them anyway.

Pretty much all the altcoins have more changes from bitcoin than just their name, port and IRC channel; even RUcoin that claimed to be an outright clone actually turned out to have changed the block rewards (giving out two million coins in block number one) so to make one whose only changes are those that any altcoin will need to make, without any that are specific to any particular altcoin, I need to make up a new one.

So actually even if I do end up making one with progressively increasing rewards I guess I will first just keep one that doesn't have even that much actual difference. Since the first goal is to make a diff showing the absolute bare essentials. In fact I probably will only change the name of the default directrory at first and not even worry abotu the purely cosmetic occurences of the name.

Where I am eventually headed with it probably is an altcoin kit that instead of having you put all the changes into a config file to be loaded at runtime has them in the make process so they are built into the executable. This is to make it easier to apply patches/pulls from bitcoin going forward, as making enough changes to basically create a new version multicoin might increase the chances of patches not applying cleanly. Though hey maybe I will end up just making another multicoin. I really don't know yet, I just want more things to merged mine to see how merged mining works out with more and more and more chains added to it and to update the existing altcoins to more-recent code.

-MarkM-

Are there any consumer-electronics devices or at least "used in large numbers" devices using ASICs that are comparable in complexity to the ASIC offering that currently costs $30,000?

Also, what about once ASIC devices not as large as those come out, how much for a little thing that only uses one ASIC chip and maybe is about the size of a IDE hard drive or a walkman?

How much does a cash-register cost? I recall monocrome computer-terminals being widely sold for $4500 or so (Canadian) once upon a time (aka when CAD was worth a lot more probably than it is now), maybe cash-registers cost quite a bit even now? (I wonder because maybe putting a mining ASIC in every cash register might not actually look all that crazy in a decade or two or maybe even less than a decade... just a few years?)

(Remember when "numeric co-processors" were crazy-expensive rare cutting-edge items? How much are they now? Oh wait, are they on-chip with the CPU already?)

-MarkM-

How did you get it to compile?

-MarkM-

The payment processors will have incentive to pay fees and maybe also to hold very rapidly exercisable "latest top of the line ASIC mining rig" options.

The latter in order to be ready to rapidly jump to the support of the chain in case of attack or just to enter the mining biz. (Merely paying higher fees might not suffice if a monopolist is secretly setting up top of the line ASIC rigs in co-hosting sites all over the world as you'd be paying the monopolist more and more the closer they got to taking control of the network.)

If you can make over 300 dollars a block just processing payments, a current top of the line ASIC rig would only take what, half a day or less to pay for?

-MarkM-

We have to download it using our IRC clients?

-MarkM-

Bitcoin only has the code for being the PRIMARY chain in merged mining.

In order to be an AUXILIARY chain, you need more code, which bitcoin itself doesn't seem to want to have, presumably due to a desire never to play second fiddle to some other chain(s).

To update an altcoin to be based on the latest bitcoin code, or to start a new altcoin based on latest bitcoin code, this patch is useful if you want to be able to merged-min your altcoin as an aux chain. If you base it on bitcoin code without adding this, like RUcoin did, you have to be the primary chain, which means you will not be able to include bitcoin itself into your merged mining mix.

I made this patch because there are many altcoins that could use an upgrade to the latest bitcoin code but that people mine as aux chains.

So basically I plan to take ths "newcoin" template and use it to make an updated, fully merged-mine-able altcoin, and then make another patch showing exactly what has to be changed when turning a bitcoin that has the above patch applied into an actual different coinchain.

Ny example actual different coin chain will probably be "PRGcoin", short for "PRoGressivecoin", which will be a coin whose block reward starts at one coin per block then increases by one every [some number of blocks].

That will give me a diff showing all the places where changes have to be made when making a minally different from bitcoin altcoin.

I will then be able to fairly rapidly make updates for all the altcoins that are basically hardly any different from bitcoin.

-MarkM-

Maybe a website is not a good medium to use for something like this.

It is not only hard to secure but also horribly exposed. Random members of the public could arrive there if some search engine spider has ever happened upon it, or someone could let slip its existence to a bunch of internet crazies who like to hack sites or report unlicensed investments to authorities or gosh knows what.

Maybe it would be better to use encrypted email to communicate with your investors, possibly via a mixnet even?

Processing emails for specific commands like tell me my balance or herewith is the private key to a bitcoin address that has more money I want to invest might be a lot more secure than letting people put inputs into HTML/PHP forms that end up interacting with MySQL databases.

Plus, even Chrome browser is not secure, so requiring your investors to use a browser at all might not be such a great idea...

I am dubious even of using Tor for something like this because simply by correlating uptime to powercuts in various regions it could maybe get tracked down... Thus the idea of email or freenet Sones or something like that where the exact times you come online or go offline is not so easy to discover seems like it might be a good idea.

-MarkM-

In order to actually do this, we first need to test whether we can even actually get enough hashing power merged-mining a new chain to actually secure the chain.

There isn't much point starting to issue coins until the chain they are to be issued on has attained a secure level of hashing.

Miners could in fact "vote" for the idea of a pegged-to-fiat chain by merged-mining it in advance of the issuance of any actual coins on it.

-MarkM-

I thought altcoin makers would also find it useful to know which ports various coins already use so here is what I have so far:


-MarkM-

I have applied merged-mining patches to very recent bitcoin-git, in order to have a modern version of bitcoin upon which to base auxchains.

Maybe someone who uses something other than unix / Fedora can fix up the other makefiles as I only did makefile.fedora15 (which I still use even though I now run Fedora16) and makefile.unix

Also the stuff for qt maybe needs to be told about auxpow.h and auxpow.cpp too, I don't know as I only run daemons.

It is at https://sourceforge.net/projects/galacticmilieu/files/

as the gile merged-mining,patch

It is the output of

patch -c -r bitcoin-git newcoin

Where bitcoin-git is pulled from Gavin's git repo a day or two ago and newcoin is the same other than having had merged mining patches applied and conflicts in apply thing resolved (as best I could... if someone could check them that would be great...)

-MarkM-

Actually I still do not think it is best to use bitcoin to back some token that is intended to actually represent, or be pegged to, fiat.

For one thing, doing it that way is most of the reason why you need multiple reserve instead of full reserve.

If you kept most of your reserves in the form of the actual fiat the token is intended to represent or be pegged to then your reserves enjoy the same increases or decreases in value as the tokens they are backing. That seems to me to eliminate most of the volatility problem as regards your reserves getting out of sync with the liabilities your coins/tokens represent.

Basically I would only issue USDcoins equal to the number of actual USD that I have hidden securely somewhere, possibly in the form of actual physical specie rather than as electronic deposits at banks susceptible to gosh knows what freezing of accounts, confiscation of funds and so on and so on.

I would probably need to have a friend to friend network of friends who are willing to buy the coins from people using various things along the lines of MtGox USD credits, PayPal, Pecunix, Liberty Reserve, Dwolla or whatever. They would do so because they trust me to actually go dig up the actual physical specie if necessary in the case of a run on the reserves. They could be connected to me via i2p or Tor or via Sone messages on Freenet or using RetroShare or maybe even by none of those specific programs since I am known to run all of those so maybe they might prefer to use some "none of the above" methods.

Trust would be just a matter of time, eventually people will notice that provided you allow for a modicum of profit on the behalf of the buyer you can always find someone who will buy as many USDcoins as you have at close to a dollar each. Since no more exist than I have issued, you cannot have more than can be bought back from you.

Really all that is necessary for any cryptocoin to maintain a stable value is to keep it from being issued by miners who have no interest in actually buying it back at close to the price they sold it for.

-MarkM-

I remember that thread. Basically you suggest multiple, as opposed to fractional, reserve.

That might well require vast assets in order to accomplish it with a very wide aperture of how much value can pass through it per transaction, but it seems to me that the total amount of reserves on hand really only limit the aperture: the transaction size.

I wanted to go through an example of someone wanting to exchange, for example consider someone wishing to sell some NMC for some USD.

They buy some USDcoins from someone using a secure two-blockchain transaction in which both parties get the coins they bargained for or the transaction is invalid. (I think methods of doing that have already been worked out in some thread somewhere?)

However maybe NMC is a poor choice for an example if MtGox does go ahead and add NMC to its choices, since one could then go directly to MtGox instead of getting involved in this whole intermediary USDcoin stuff.

So lets pick some coin that currently has no established exchange that trades it directly for fiat, lets say bitNicKeLs for example

The person wants to exchange NKL for USD. So they buy some USDcoin with their NKL.

Now how do they turn their USDcoin into actual fiat USD? Presumably since this is decentralised there is no fixed publicly known exchange that will do that for them?

So as a potential issuer of some kind of "USDcoin", in order to avoid having a public exchange that is easily targetted, I will want to have market-makers or something? A bunch of partners who will appear on the p2p exchange-network as just another user, but who will happen to be willing to give someone some MtGox USD in return for USDcoins?

The more limited the actual USD reserves of the issuer(s)/backer(s) of the USDcoins the less tolerant the system will be of hoarding, due to the necessity of keeping multiple-reserve reserves instead of merely full or fractional reserves. For example if I commit to having two actual USD banked in an insured-deposit bank somewhere per each USDcoin I issue, there will be no more USDcoins available than half my USD reserves. This system has to make me at least 2 USD before I can legitimately issue another USDcoin.

So if anyone hoards any of the coins instead of hurrying them along their path back to me, the supply will dry up. All it takes is a number of hoarders equal to half the reciprocal of (the amount they each hoard divided by my USD reserves).

So even if I start the system up with a trillion dollars somehow divvied up among enough deposits at banks to somehow keep it all insured, I can only issue five hundred billion USDcoins which means only one billion "hoarders" hoarding on average five hundred coins each would freeze the whole supply. A mere hundred million hoarders hoarding only five thousand coins each same thing. One million hoarders hoarding only fifty thousand each, same thing.

Now obviously if the entire 500 billion does get issued, I could increase my reserves by half that, so I could issue another 250 billion. But basically no matter how large my reserves there is some point at which any agglomeration of people out there controlling only three quarters as much as my reserves or thereabouts can dry up the whole system if hoarding is tolerated.

So maybe the coins would have to come with an expiration date, to make them "hot potatoes" (like the dollars they represent maybe only maybe more so), to force them to have to come back to me in a reasonable timeframe so the timespan over which I am liable for a coin once having issued it is limited?

If it all came back to me in a matter of minutes or hours, or even seconds, then the amount of reserves needed could be limited to that aperture, and it would be only a means of exchange not a store of value.

-MarkM-