No DNS option. I have an addnode to an IP, probably some long term node like bitparking that I added when having trouble finding connections.

Speaking of connections. IS THERE ANYONE OUT THERE?!?! I am not finding connections...

-MarkM-

Why is it the only coin that keeps dying from some attempt to use boost to do DNS lookups?:


It takes a LONG time to scan its chain when I start if again after such a crash (re-scanning to make sure chain is intact not damaged in the crash). So it tends to be down a long time each time this stupid crash happens.

-MarkM-

It took something like 12 hours to get machine upgraded to Fedora 17 from Fedora 16.

Whenever using pools you should always have "failover": backup pools your miner(s) switch too during downtimes of main pool(s).

Sorry about that but now I have three machines here upgraded to Fedora 17 and can start to look into splitting stuff up across multiple machines so not everything will have to go down at once when the current single main server machine goes down for maintenance upgrades etc.

Actually the machine itself was not down 12 hours, but the latest bitcoin from github switched over to a new type of database for its blockchain and for some reason or lack of reason decided to download the whole blockchain from peers instead of grabbing it from the old-stype-database copy that was already present.

Thus the pool as unusable for many more hours than the rest of the stuff on that server.

I do not know why bitcoin does not convert over the old blockchain when it upgrades like that but oh well it has a new format blockchain now so should be okay now despite constantly spewing warnings about being an experimental version. (It is that new, right from top of the github repo.)

All of the coin daemons had to be recompiled too before they would work with all the new libraries that came with the new version of the operating-system.

-MarkM-

DeVCoins go to people who develop free open source stuff.

For example various bitcoin developers and bitcoin-related-program developers receive DeVCoins.

Developers of Open Transactions also receive DeVCoins.

The coins are not limited to developers of devcoin itself. They are for free open source things in general, including free open source hardware such as block coolers for mining hardware, three-dimensional printers and gosh knows what other kinds of free open source stuff.

-MarkM-

Lets get specific.

Look at Zookeeper: http://zookeeper.apache.org/doc/trunk/zookeeperAdmin.html#sc_zkMulitServerSetup

Up to 255 machines can be on one "quorum" of servers/nodes.

We could use Zookeeper itself to ensure all 255 nodes in the quorum all have the exact same information as to who exactly are the current 255 nodes currently (at a given moment) forming that quorum.

Based on their node number within the quorum, each can publish offers.

Each can see the same overall state of all offers all nodes currently have open.

We would need to set watches that will change the list of nodes when a node leaves, and provide some kind of enrollment system whereby machines can apply for a spot as a node in a quorum.

Initially we can start with 255 permanent nodes, 255 people who are committed to engaging in this 24/7. Once all works smoothly with that fixed set of nodes, and of demand is sufficient, we can proceed onward to enrollment interfaces.

It actually does not matter if machines of a quorum are offline, as long as at least three machines of that quorum are still online. So we can assign new people to a not yet full quorum and just leave them there, no need to keep enrolling and un-enrolling.

Once there is more than one quorum up and running, we can start adding gateway nodes that pass on the data in one quorum to another quorum.

-MarkM-

I guess I do not understand what you mean by a decentralised market.

Decentralised exchange, atomic secure exchange, fine.

But is there even any actual need for all the participants in a bazaar or market to all reach unanimous agreement about exactly which is the best price and exactly which is the top of the queue offer against which it should be executed?

Before everyone can agree as to the exact total orderbook, they each need to have an exact total orderbook of their own.

Even if no new orders are published, it will take time for everyone (possibly thousands of people) to all compare their order-books to check that they all have the exact same order-book.

Even if they do all agree on one global orderbook across one entire "market" or "bazaar", it will very likely be out of date by the time they all agree that it is correct and that they all have the exact same contents and sequence in it. Because meanwhile anyone who sees they are not at the top of the queue can go behind the order book's back to contact someone else who might also not be at the top of the queue, and exacute an order directly between themselves, accomplish an exchange directly between themselves, and even choose not to waste time telling the distributed order book that they changed their minds, instead that could simply not bother to answer if or when the distributed order book finally gets around to matching their order (which is now obsolete as they found a partner to exchange with faster by simply doing a p2p exchange with someone else who didn't mind not waiting around for some global distributed order book to match them up with someone.

It seems like what you mean by a market is an order book with associated matching of orders, and it also seems like such a thing is ultimately just one view of what the current offers are that are out there in the bazaar. Thus you basically first have a bazzer, then you have one or more agents trying to put together possibly different order books that try to provide some sense of what the best offers are that are available in the bazaar at a given moment.

Is do not really see what you gain even if you do manage to all agree on one order-book's contents. I do think that forcing any offers shown in such an order book to still be available by the time an attempt is made at matching them probably goes beyond what many people think decentralising is all about. Because it basically centralises matching, even if it is centralising it into an insanely  possible complex form of distributed consensus like the way bitcoin decentralises one one global centralised consensus across many distributed machines.

Isn't being forced to have my funds locked up by some global central consensus system until such a system finally (if ever) gests around to matching them up with a counteroffer going to be seen as being against the whole point of decentralisation from many/most people's view? Why create a massive decentralised Big Brother if the point is to avoid having a Big Brother at all?

-MarkM-

That is crazy low price, how about 25 million DVC for 461.62790697 BTC ?

Or since it is a large purchase, you can maybe get 5% off so 438.54651162 BTC ?

If someone is willing to give you a 10% discount at such volume, maybe 415.46511627 ?

( See conversion rate tables at http://galaxies.mygamesonline.org/digitalisassets.html )

-MarkM-

Agreed. The Travian-etc chap has obviously not continued such games beyond the point where he conquered the entire world yet would not really have anything to show for it if he couldn't keep the other players from quitting the game.

It is more like running such games. Notice how the game companies run them now: they kill the server just at the moment when the game starts to get interesting, because unfortunately the way the "winner" plays is not conducive to keeping hordes of players playing and a constant influx of new players joining in generation after generation.

They are tiny little oneshot games, and the winners win by the "default the prisoner's dilemma" method on each single "shot". The games teach people that you need to slaughter all other intelligent beings in their mothers' wombs or failing that in their cradles, and scorched earth their entire civilisations if need be.

They end with an entirely unnihabitable world, so uninhabitable they don't even leave it running for people to explore "what happens next".

-MarkM-

You can decentralise the order-book simply by spamming offers anywhere you can spam anything.

Throw enough offers on the wall and some will stick kind of idea.

You can look as long as you like at as many spam-piles as you like looking for what you thing is a good enough price for you.

So "matching offers" is not important.

Thus it seems like all you absolutely need is atomic exchange, which can already be done on a single block chain and when currently-disabled feature(s) of bitcoin are re-enabled will be possible between chains too.

Another idea is maybe crptography can do some sort of blind XOR type of operation. You can exchange the contents of two variables without needing a third variable by means of XOR operations. A crypto version of XOR if such a thing could exist would similarly switch the bits of two contracts, your contract becoming the other guy's while his becomes yours. Similarly private keys, maybe the contents of two private key storage areas can be swapped one bit at a time or something.

Maybe you could even indicate what price you want for the contents of an address by generating the next address in a predictable/deterministic series of addresses, like the extended ideas beyond deterministic wallets speak of. Anyone can compute what the next address would be, even though they don't know your private key, supposedly. So for any given address anyone could compute its "price address" and look there to see what the contents of the coloured coin address are being offered for sale for, in bitcoins or satishis or heck, maybe even in some other colour of coins.

For markets, your requirement that no one know all the machines involved in their currently selected market seems to maybe rule out using Zookeeper unless we use Zookeeper over i2p and/or Tor so that althrough they all know all of them that form one cluster, they really do not "know" them in a send police to smash in their doors sense, they merely know the current Tor or i2p address of each participant.

But the thing about Tor and i2p comes back somewhat to your question of why would anyone bother.

None of the people going on about how much they need a distributed anonymous market seem to actually have Tor and i2p up and running, I often feel like well gee guys, you are shooting your own idea down by not even being on any of the networks on which such things could be deployed. Maybe the standard response should be "cool idea, bu why are you even talking about it out on the non p2p, non anonymous net" and "great idea, I always like to discover new nodes of the anonymous networks, give me your Freenet email address so we can discuss it" and "great, lets chat about it, what is your Torchat ID" and suchlike.

Basically if these people are incapable of even joining the networks on which the things they want would reasonably be expected to run, what makes them even think the thing they want doesn't already exist? Thousands of people could be anonymously trading right now and these here folk cannot even get off their asses to join the network let alone run an app on it.

We could deliver a servlet and/or applet for Jetty to run in your eepsite, or even a plugin for i2p to run such a thing alongside Jetty as a separate service from their eepsite, but these people don't even have eepsites yet!

So hey maybe lets start from the basics: get your eepsites running, publish your Torchat IDs on them, maybe even run a forum on your eepsite where we can discuss this stuff. The distributed forum system for i2p could be useful too, though that could do with some work. Maybe if people actually used p2p anonymous networks all this stuff people keep complaining about needing would already exist. But instead they seem to keep on pretty much implying that even if what they keep complaining about not having did exist they would not actually use it.

Back again to the cost. If you offer people money to do some sneaking clever stuff to avoid big brother, you will attract sneaky clever people who want to steal your money or defraud you out of your money. People who actually want a thing don't need to paid to have the thing they want, they in fact are the demand side of a market, they are willing to pay to get what they want. For example, programmers who are willing to pay hours and hours of work to get what they want programmed, or anonymous net traders who are willing to pay bandwidth for an anonymous net so they can trade, and so on.

One nice thing about i2p is that unlike Tor is is not designed for random non-contributors to pop in grab what they want and leave. Rather, you tend to get crappy speed until your node has been online long enough, passing along other people's traffic enough, to have established itself as a good reliable node that contributes good bandwidth and does not shut down and so on...

-MarkM-

Do you actually think Silk Road will not simply vanish with all the loot it can some day?

There was a gold based currency on anonymous net too years ago, great reputation, worked well etc.

But when time comes to retire or whatever, why not take the loot?

-MarkM-

As has been said over and over not just here but all over the place, the initial distribution is pretty much unimportant.

If all the gold on the entire planet had been handed to Adam and Eve in one swell foop it would still work pretty much as it has always worked. The ores we find would be from things like Vesuvius eruptings or something, gold melted band oxidised or whatever, and we'd find larger nuggets such as chests of bars in sunken pirate galleons, there still could well have been gold rushes as people discovered far lands where Cain and Abel each took a big chunk of their parents' hoard and so on, but that is all trivial detail.

-MarkM-

Ahhh, https://bitcointalk.org/index.php?topic=34586.msg889087#msg889087

Thanks for the link.

Well I suppose if backups are hoped not to have to be used maybe an IP is okay but I do suggest we not put IP addresses in the real files.

Since DeVCoin addresses are identical to BiTCoin addresses, that Drupal module should be trivially easy to modify since all that should need to change is the port number to connect to and the name of the currency.

The port number possibly would already be configurable in whatever kind of admin config system it uses, so maybe the name of the currency should also be configurable then it should work for any altcoin that has the RPC calls that it uses.

-MarkM-

It looks like one can centralise stock markets pretty easily starting by eliminating the central market and having the brokerages talk to each other directly.

The back end of Marketcetera is an order router to which all your clients (your night traders, your day traders, your evening traders, your financial offer, your compliance officer, basically all your staff that need access to trading) connect and to which you also connect strategy engines and, - here comes decentralisation - the order routers of other brokerages.

The client GUI looks quite nice, take a look at http://www.marketcetera.org/confluence/display/PN/Photon

It talks FIX protocol, which is pretty much standard trading protocol. FIX is also what the brokerages use to talk to each other.

Explore Marketcetera's site, fire up the router and client yourself and try it out, and you'll see that the default setup has you talking to their "stock market simulator". Dig down into the nitty gritty of your strategy engine capabilities (the Photon client includes strategy tools) and it should become clear to you that about the only service a centralised "stock market" would add would be co-ordinating everyone's views of how much of what is for sale at what price and who wants it.

Most of the that the brokerages can get directly from each other, and they can also co-ordinate their views too if they want by using tools such as http://zookeeper.apache.org/doc/trunk/zookeeperStarted.html

To scale up - that is, to become even more distributed, handling more than just the hundreds of brokerages that zookeeper might reasonably suffice to provide synchronised views to, message buses can be set up on which many many such clusters of brokerages can communicate, using things like http://incubator.apache.org/kafka/design.html and http://www.mulesoft.org/what-esb

It is important to notice that Marketcetera does not assume that brokerages just talk to stock exchanges and to end-users but to each other. That is key, as it is clear when you look closer that ultimately the stock is exchange is basically just the biggest broker on the block. If a few hundred brokers synchronised a view well that is what the stock exchange once was, wasn't it? Just hundreds of brokers all communicating with each other at once.

We can go farther with this though, because modern personal computers can run this stuff. So even small brokerages can run it, heck even a power user individual broker could run the whole system in his back room office at home.

-MarkM-

I still do not understand what we are intended to do with that IP address. Is it intended that it be recorded somewhere? Is it intended that it will have DNS mapped to it and it will be kept online 24/7 pretty mcuh "forever" as one of the places (of which an odd number are needed because a majority must always be able to be computed) that will be listed in the devcoin system's files as a go-to place to check for consensus about the contents of the receiver files? Is it going to also have downloads of the actual software?

I just do not understand what it is supposed to be.

-MarkM-

It would be interesting and useful to get some actual quotes / commitments from miners on how much exactly they would charge to merged mine how many chains (or a chain that will be their X-many'th chain, if they charge less per additional chain).

That way a realistic budget can be worked out and actually "backed" coins such as USDcoin and so on could be deployed, knowing how much the backers to whom the initial and total number of coins ever to be issued were issued need to budget for paying miners to secure their chain.

About game companies messing with the number of their coins, minting more on demand, have you not read anything about bitcoin? They have as much ability to do that as Gavin has to do it with bitcoin, maybe slightly easier is less users out there already using it.

What keeps Gavin from doubling the number of bitcoins minted, for example?

-MarkM-

I still do not understand the puroose.

If it is to serve as a receiver file repository it should have a DNS name, putting IP addresses into the files that people will be using for years to come to look up the historical repositories of receiver files is not a good idea.

Even putting a host that was on DNS turned out badly because the guy flew by night within I think less than even a single year.

If it is not intended to serve as one of the repositories the clients consult to reach a consensus as to who receives how many shares of which blocks, then I do not understand why we even need to know about it.

-MarkM-

The premining controversy is easily solved, just use bitcoins for bounties like Unthinkingbit to get DeVCoin built.

This seems like more work than DeVCoin but still a few hundred bitcoins might well get the interest of a coder or two.

-MarkM-

All those things are what we try to simulate.

Maybe the word "simulation" might make the concept more understandable to you than the word "game".

You kind of sound a bit like a Private who refuses to take part in "field exercise" / "field training" on the grounds that there is no point "playing wargames".

Real world forces actually do "play games" as much as they can afford to, so that they can know whether their tools, equipment and people are ready for "the real thing".

Millions of dollars have already been lost due to people insisting on "going live" before their systems and people have been proven in "simulation".

It is not easy to get lots of people to spend hours and hours each doing testing; making a "game" out of it lets them at least get some kind of satisfaction/reward out of it.

-MarkM-

IP? Have you heard of DNS? What are we supposed to do with that IP number?

The whole point of DNS is so the number can be changed and everything still "just works".

If it changes often then dynamic DNS comes into play.

What is this so called "server" supposed to be, anyway?

I see you have receiver files there, the last thing we need is another fly by night receiver-file "server", people still keep having problems because we already had one of those way back when...

-MarkM-

An investment professional who can't do accounting-math. Just what we need more of around here, congratulations.

What university was it you learned this stuff in, again?

-MarkM-