Unless the miners have some special equipment that the computers a botnet infects do not have, then botnets will be able to have a lot of impact.

You might even be tougher against botnets by using ASICs, at least until the ASICs become so widespread that botnets are as likely to find machines equipped with them among their holdings as any other particular kind of special equipment.

-MarkM-

I don't recall Luke's majority of hashing power being broken, I thought he simply stopped the attack silently and unilaterally after he considered the attacked chain to be effectively dead.

As far as I know he still mines the chain, still with a majority of its hashing power, but does normal mining instead of attack mining - maybe not even all the time even, possibly he switches back and forth and the chain is dead enough still that no one notices? Basically if the chain ever does start to recover, Luke will hold a lot of coins, maybe a majority of the coins. So its possible he switched from attack mode simply because he felt the sheer number of coins he will hold will be enough for him to destroy the coin in the markets by dumping. Heck maybe he does dump them.

Supposedly he did lose a few users, but only a few. The main difference with pooler's pool attacking litecoins is there you are talking about attacking the very chain that the users are expecting to profit from. But still, if all pooler did was refuse blocks from others, some of his users might well see that as simple compeition, saying if other miners have a problem they should just come join the pool...

-MarkM-

I found the ones that can be merged-mined useful for testing mergedmining. I learned for example that the extremely short block time of GeistGeld was bad for merged mining along with all the other coins, so I had to drop GeistGeld from my merged-mining mix.

It would be handy to have more coins to try adding to the mix, however I expect that if they try to use block time as short as GeistGeld's they will prove unsuitable.

DeVCoin has been very useful for financing free open source stuff, which is its purpose.

I0coin has had problems, maybe once we get to the root of them there will be something to learn from them.

-MarkM-

If as it sounds it does not actually do anything yet, having a GUI for it seems premature; might as well first have it able to actually do at least one thing, so that a GUI will actually have something it can tell it to do.

DNS sounds good, then the GUI which, to have something to do (since there would be no point running the daemon if you didn't want to be able to look up .bit domains on the local machine), maybe make a GUI that will let you toggle whether to let other machines use that DNS, or even let you configure exactly which machines to permit to use it or something like that.

Maybe I misunderstood, but I got a definite impression the thing doesn't actually do anything yet but is just a framework ready to have something to actually do added, so to me it seemed hilarious how windows folks immediately jumped to the idea that most important thing to have would be a GUI that doesn't actually do anything.

("I know it doesn't actually *do* anything but the point is, it should not do things graphically instead of not doing things textually dammit!" )

-MarkM-

A widely used method of "investing" advertising / marketing / visitors / hits into websites is an approach known as an "affiliate program". Maybe google it and consider whether it might be a way to get "partners" who will provide what you are looking for in return for compensation computed on the basis of hits, visits, signups, sales, recurring sales or whatever you find most appropriate or easiest to add code for.

-MarkM-

Oh good, because if we are going to have an actual rule it might as well be a doozy, with built in funding for enforcement, like maybe require all donation addresses to be special script-addresses from which funds can only be released by outputting a certain percentage to the forum police fund or something.

-MarkM-

Gee I dunno. Why is Dwolla on the list, they explicitly announced in writing that they would not reverse charges...

-MarkM-

What would you like me to think? Register your vote by sending 0 for no, or a positive number for yes, to 1NZJmhfN3nGGGBbb8Lgi9t3L9puEZsX8Um



-MarkM-

The Open Transactions server thread fellowtraveler mentioned is at https://bitcointalk.org/index.php?topic=53329.0

I know this current thread I am posting to is old, but I deliberately went searching for threads about distributed stock exchanges to make sure that what seems to have turned out to be a major problem for various steps in such directions has been mentioned.

I see that it did receive one small mention toward the end of the thread, but hopefully it can bear more thought.

The problem is that even with the implementation of merged mining to make adding more blockchains to one's mix when mining relatively cheap, the reactions encountered by various chains have taught us that even with merged mining the miners demand an impractical percentage of the entire market cap of the issued securities / coins / tokens. In short, they want to own them all, one hundred percent of all issued assets! That is totally prohibitive and makes the entire concept of using blockchains for issues belonging to anyone other than miners pretty much ruled out from the get-go.

Then too, even beyond demanding 100% of the total worth of any blockchains they touch, miners also have shown a willingness, even a desire, to conspire to attack blockchains or, failing directly contributing themselves to the attack, at least a desire to have others perform such attacks so they can gleefully sit back and laugh. And let us be clear here, this is not how they treat chains that fail to hand over to them 100% of the chain's assets, oh no, this is how they treat even chains that do hand over 100% of their assets to the miners!

At least two corps (General Mining Corp and General Retirement Corp) issued what amounted to "preferred shares" in blockchain form, but, along with several other assets that once upon a time were implemented using blockchains, they have been forced to scrap the blockchain approach for now in favour of using Open Transactions.

Coins on a blockchain amount in practice pretty much to some form of share of the total economy of that asset. So far DeVCoin is the only blockchain predicated upon not giving 100% of its assets to miners that is still running in blockchain form instead of having switched over to using Open Transactions.

Really think about this. It is comically imbecilic, it would sound like fiction, so ridiculous as not to be believable, to anyone not familiar with the history of blockchain based assets that even when 100% of the assets were to be seized by the miners at the very moment and by the very method of their issuance, miners prefer to destroy all possible value of such assets. I am not sure if that is more worthy of Kafka or Monty Python or some Dadaist or what.

SInce the initial move of several assets that had been implemented as blockchains over to Open Transactions format and to trading on the Digitalis Open Transactions server, new assets have basically given up on the blockchain concept for now and have been starting out from inception on the Open Transactions server.

-MarkM-

FTFY.

-MarkM-

No one ever actually used any of the IRC bots, so one by one they have gone offline, I am not even sure exactly why since I didn't actually turn off their entries in the crontabs of the various usernames running them. I think eggdrop just tends to eventually corrupt its user file, as while I did care abou them I did have to restore the user files of several of them to keep them working. Quite likely since I stopped caring they have one by one corrupted their user files (which, since they have no users, mostly contains their entries about each other so they can network among themselves).

That corruption isn't a dealkiller since part of the purpose of their networking among themselves is to share their users, so as long as you can find one still running it should know about you thus let you transact exchanges between the various blockchain-based currencies.

However, I never did get the bot I tried to build OT's TCL API into to work. It has turned out in the intervening year that actually OT needed a lot of work, we found some deep problems and fixed them but by then the market had made it clear that IRCbot-mediated exchanges were not wanted/desired.

My focus has thus, in that intervening year, moved on to running an actual Open Transactions server, and the debugging and so on has been focussed on getting that, and a demo client demonstrating how one could talk to such a server, up and running and, recently, also able to be built using autotools and having windows binaries ready to download.

I have a thread in the projects section about my Digitalis Open transactions server which if nothing else may serve to chronicle some of what has been done during the last year or so.

User balances have survived admirably, they are very robust, the system works well in that respect. The last few months have mostly been focussed on implementing paranoid security so that a user's machine never lets the passphrase used to decrypt the user's private keys get written to disk. Right now custody of an intermediate key derived from the passphrase is in the process of being delegated to the "keyring" services of the various supported operating-systems so that even that keyring does not store the actual passphrase, just something derived from it that Open Transactions can use to decrypt the user's private keys for a configured number of seconds. It has taken a lot to get this far with that degree of paranoia, and all the constant testing implemented by automatically run scripts has halted ever since the paranoia reached a point where the scripts could no longer work unless a human actually "held their hand" every time they run, providing the passphrases over and over again at all times of day and night when the scripts got run by the scheduled-tasks service (cron, as I use Linux).

The IRC bots that actually worked did not use Open Transactions; they simply called shell scripts that communicated with *coin daemons, using the verified "nick" of the IRC user as the "account" name in the wallets controlled by the *coin daemons; and actually I do not really know whether they did really work as no one evidently ever managed to create an account on one, albeit only one or two attempts that I know of were claimed to have been made, in neither case persistently enough to proceed to an actual test/exploration to try to figure out what their problem had been.

-MarkM-

Uh, wait a sec there... I thought the theory about Keynsianism is that it does not represent an understanding of economics and how currency works. You seem to be trying to have it both ways...

-MarkM-

We are searching for solutions to the Alien Generals' Invasion Problem, a well known problem in military consensus-making among invading generals. Thus the more likely it becomes that we detect the alien generals' communications the more important it becomes that we have the technology to solve such problems the better to predict them...

-MarkM-

Financial sites don't actually send your password in cleartext in email, do they?

It seems pretty obvious that email is insecure, even if people ran their own mailservers in their own homes it would still need to be encrypted while in transit to be useable for things like passwords.

Even for things like sending you a one-time change-your-password session code that will expire five minutes after being sent it is insecure since anyone who sniffs it along the way can also quite likely slow it down to prevent you from even receiving it until the five minutes have already expired.

-MarkM-

Yeah but the payment processor takes care of that for the merchant. For the merchant it should be simply "do you want to accept the full range of currencies supported by the payment processor or tell the payment processor to refuse customers who certain currencies (and if so which supported currencies do you want the payment processor to reject?)

Basically you tell your payment processor how much of what currency you the merchant want for each item you are selling and as long as the payment processor gives you that what skin is it off your nose if they choose to accept cows or chickens or diamonds or lead or copper or gold or fiat or even solidcoins as long as you get the quantity you specified of the currency you specified?

-MarkM-

You keep seeming to say that when you pass coins from one block to another you have to adjust them for demurrage.

I think that creates complications that are not needed. Demurrage can be done just in the client, the blockchain does not need to do anything about it except to grdually increase the number of coins minted per block just enough to make up for the demurrage so that once the equilibrium amount of money is in circulation the slowly increasing number of coins minted per block keeps that number in circulation.

You basically only have to change the input and output display of numbers so that the same number in the blockchain displays as a lower and lower number over time and the numbers people type in as the actual at that moment value they want to talk about refers to a larger and larger number of blockchain-representation (epochal) coins as time goes by.

Basically if at the epoch I tell a client to send you 100, the blockchain representation will be 100. A year later though if I still say to send 100, of that day's coins, then on the blockchain it will show something more like 105 or so (100 * 1/0.95).

Similarly, if the genesis block mints 50 coins as represented in blockchain-notation (epochal coins) then when someone displays that amount in ten years or so it will be displayed as some 25 or thereabouts of that day coins.

The whole complication of changing the quantities as they go from one block to another just makes it all harder by not changing the values until they move. Since the values actually change whether they move or not it is best to have the demurrage - the change of value - take place constantly simply by having it happen in the display routines. At any time anyone can thus select a date as of which to display the values and look at any transactions or balances in the blockchain in terms of the actual value they did have, do have or will have at the specified point in time.

-MarkM-

I still don't see a need for the values used by the blackchain to change.

Only the disply and input interfaces need to adjust the numbers in accordance with whatever date+time is of interest. The blackchain can deal entirely with epochal coins. To keep the generation rate constant in terms of at moment block is made value, just apply the inverse of the demurrage rate to the number of coins generated.

That is, if the actual dcoin number/value of 50 epochal coins at some future block is 5 but that block is still meant to produce 50 that day coins, have it generate 500 epochal coins.

Eventually epochal coins will only be worth a that day satoshi each but that will be far in the future and the generation rate can still be climbing then.

For example if each block always generates 50 coins adjusted for demurrage to come out as 50 of that moment's coins in value, and coins fall in value 5% per year, eventually total quantity surviving will stabilise as the equilibrium between the minting and the demurrage. There should thus be no need to ever change how many (that day adjusted) coins are minted per block, but the number of epochal coins that many coins corresponds to will keep climbing as epoachl coins continue to fall in value.

-MarkM-

I just added the keys found on this last page of the thread as I didn't have them yet, but I am still seeing no connections.

My key is in the thread, anyone who doesn't want to publish their key in the thread is welcome to add me and PM me theirs.

-MarkM-

Do you have i2p, Tor and/or Freenet running?

If not I suggest just run them 24/7 for now, the worry about whether there is any point at all in adding RetroShare to the mix later.

-MarkM-

Trickles are fine for now, my amount of disposable funds being somewhat limited. And actually trickles will remain fine possibly until every coin to be minted has been minted, as I don't need vast sums of money to retire on for a while yet...

-MarkM-