Ripple does not place the barriers, even if they be only psychological, to entry of massive capital that Bitcoin does.

People looking to be able to conveniently move billions around might wonder whether Bitcoin is big enough for them yet, given that every billion they put into it enriches any of their competitors who already own bitcoins. Why, they might ask themselves, would I want to make my competitor a whole bunch of money "out of thin air" by driving up the exchange rate of a currency he owns maybe thousands of times more of than I currently own. Assuming I even own any at all yet.

But with Ripple, they can issue a few billions of their own IOUs and their competitor's IOUs do not magically jump in exchange rate as a consequence. So it provides a more-level playing-field for new entrants.

-MarkM-

There are some people who seem to think bitcoin cannot tolerate any "competition", somehow being such a delicate flower, its own growth so unsure, that it needs a total vacuum around it, nothing similar on the horizon, in order to have any chance at all itself. All of which is just silly.

I do not want to spend bitcoins until they get to where they are going, which should certainly be hundreds of dollars per coin and hopefully more like thousands per coin by the time they reach any kind of reasonable plateau. Thus it makes a lot of sense to me to have other coins so one one has something to spend that doesn't involve selling off any of one's currently insanely-undervalued bitcoins.

Some people have found altcoins particularly useful as things they can borrow, using their bitcoins as collateral, to buy more bitcoins. Though actually lenders often find it better to implement such loans using options contracts than to get the whole "debt" concept involved, so that they don't get stuck with fiat instead of the actual coins they want in return for the collateral.

(e.g. "For 100 BTC, I will sell you an option to buy 100 BTC for X altcoin, plus a lump sum of Y altcoin" type of constructs.)

-MarkM-

SImply run the client yourself on your own local machine. It does not actually need to be on someone else's webserver at all, you can browse it locally as a file:/// type of URL

-MarkM-

Bitcoin has been rallying so fast lately that people have tended to cash out altcoins for bitcoins to get a ride on the faster growth-of-value curve. When altcoins are going up in value faster than bitcoin the reverse happens. A lot of the changes are "reactive", people reacting to what already happened, maybe even too late, and magnifying the original change that motivated them to make a move.

Litecoins are, as previous post shows, way up over six months or more. If you're looking for all time lows to buy in at, DeVCoin might look better right now as it actually is ridiculously low. But all the altcoins that I actually have enough of to consider selling are so low right now compared to bitcoin I haven't used any to buy bitcoins with lately because buying bitcoin near its all time high using altcoins near their all time low doesn't seem all that brilliant an idea.

(I don't have enough litecoin to bother selling, that, not it being anywhere near an all time low, is why I have not sold litecoins to buy bitcoins.)

-MarkM-

Litecoin also has four one-megabyte blocks per ten minutes, doesn't it?

So already offers four times as much transaction-space as bitcoin?

I am also not convinced that "one world currency" constitutes "decentralisation" of the world's financial systems.

Possibly it is better to be able to move elsewhere each time the powers that be grab control of some huge majority of the money in any particular system, maybe even go for agility where they are constantly on a treadmill trying to grab a majority of more and more and more new systems until maybe in some distant era they will realise no matter how much they want to control everyone, some people will (one maybe hopes?) find some way to retain some freedom despite them.

-MarkM-

Damn, forgot about the speed of light. We're doomed whatever we do, at least the pony express produced fertilizer, not sure these discussions are all that fertile anymore...

How could God have been so short-sighted? A hard limit, srsly? What was she thinking?

-MarkM-

So not until then will we see whether transactions are so worthless that the only application that can afford to pay for them is an application that amounts to a "throw away money" game? No legitimate use can possibly make better use of the space we already have than Satoshi Dice does?

If that is the case we seem to have been throwing away money all along on building the worlds most useless, albeit most powerful, distributed system, thus maybe should rather shut the experiment down than throw even more money at providing unwanted blockchain space that transactors (other than those in the business of throwing away other people's money) do not want.

-MarkM-

So it'd be like the search engine circle-jerk back when the most relevevant possible page, in the engine's eyes, was its own output.

So we got what, a big three in each part of the world?

Modulo the fact that blocks are not cultural/linguistic the way web pages are, so maybe the big three can be the same big three world-wide, no "you don't even speak our language, you don't understand the nuances of our pages, thus your searches suck" effect helping very-different cultures to prop up a big one of their own (do they even get to have a big three, or do the regions where the big three aren't the biggest only have a big one of their own not their own whole big three?)

Way to not centralise. Are the big number two and big number three still shrinking relative to the big one or are they becoming more equal?

-MarkM-

We immediately put in a block number at which max block size will be read from the config file instead of being hard-coded into the code.

Then sit back and yack until what actual number to put in that spot in the config file becomes clear.

-MarkM-

Did you try Ripple.com ? They have a wiki there so any info you don't find in the wiki you can put in the wiki once you do find it!

-MarkM-

He would trust you for the coins, but him doing that as a note to himself that you owe him coins would not be shown in Ripple as you actually owing him the coins, so one cannot really do a unilateral entry into RIpple of the fact of an existing debt. You would have to actually send him the IOUs in order for Ripple to "understand", and thus show nicely for him in his client, the (now actually acknowledged by you) fact that not only do you owe him bitcoin but that you do so with his consent. (It wouldn't have let you send him the IOUs without his "consent" in the form of the trust amount he extended to you.)

I guess this kind of means RIpple does not really do "invoices" yet.

Which is good, as that could need, in order for consent to be preserved, to be linked to a preceding purchase order, and on into gosh knows what more esoteric accounting stuff. (Did your nanny authorise you to send out the purchase order, who gave her authority to do that, etc... the kinds of things Open Transactions groups ideas are heading toward seemingly.)

-MarkM-

As far as I can tell the main objection seems to be that the limit is not being raised long before it needs to be raised, maybe combined with its not being raised "how high oh lord and master" the instant some loud forum voice says it should be done right away or as soon as possible.

I guess they have a fundamental distrust of the ability of the community to perform a co-ordinated transition to an updated rule or set of rules, despite the team presumably being able to streamline the process more and more each time it is done. We should be able to expect to get a new rule up and running with less lead time than last time, and for the next one after that to require even less lead time. Especially with something whose actual code-change is as simple as changing one integer. We could put it in a config file even so those who cannot just press a button to have new code validated, compiled, installed and run can just press a button to have one config file entry changed and the config file re-read.

-MarkM-

Would a "sorry this code is out of date" shutdown for nodes that fail to update in time be "a trainwreck" or just get such nodes out of the way so those that do upgrade in time can smoothly synch in whatever the new system turns out, by then, to be?

Maybe there is starting to even be a case for a Big Bitcoin launch that will allow anyone interested in massive blocks to destroy coins on the old chain in return for being minted coins on a new chain that uses massive blocks.

The new, massive-block chain would still be denominated in bitcoin, without inflating the total number of bitcoins in (spendable) existence.

The new massive chain would be the one to attempt to muscle in on the retail sales market or other markets where handling vast numbers of transactions fast is key.

We could even call the old chain "Bitcoin savings accounts" and the new one "Bitcoin current accounts".

Make it big enough and maybe it will show us the hard way whether blockchains are just too hard/expensive to scale.

Make it a secondary chain in merged-mining, so classic bitcoin need not bother with it at at all but miners huge enough to handle it (let it be really really huge) should be able to easily handle the classic chain as primary to merge with so they don't lose the benefit of all the hashing power being directed at the classic chain.

Maybe the Bitcoin plus Ripple thread I am about to read offers a better idea though...

-MarkM-

Excellent! Hopefully we will succeed in convincing the "something must be done" crowd that actually that isn't really the case yet, but nonethess have the discussion anyway so that when it is the case the discussion will be behind us so we'll know exactly what to do.


There would be more money available then for upgrading infrastructure, although I continue to hope that by then exchange rates will be so much higher again than they are now that sheer increase in the buying-power of bitcoins will cause no one who is mining them now and not stupid enough to dump them to have any hesitation* upgrading their infrastructure if they planned to continue mining. Those who just mine to dump are basically "shorting" bitcoins against fiat anyway so if they quit that might be a net good for us rather than any loss at all. (Bulls might be able to pick up their gear even.)


It is well suited to final settlement. Most e-commerce actually wants, maybe even "needs", to delay finality of settlement for quite some time, That might not be a trivial factor in what differentiates final settlement systems from consumer retail sales/purchase systems. Heck from time to time there is even talk of eliminating or deprecating cash even in meatspace, especially for decent-sized transactions. Come to think of it its not just talk lately, isn't cash being outlawed even in some places? It might be appropriate to get more and more pessimistic over time about cash's future - and, already, present - prospects. So I guess I can to an extent feel for you on this one but more so really re cash than re bitcoins, since bitcoins might help get us out from the crunch/attack cash is being subjected to.

* Other than "spend them while they are skyrocketing in value!?!?! Woe is me!"

-MarkM-

Yet we supposedly cannot rely on miners to find that equilibrium point for themselves with respect to the actual soft limit they do get to play around with, we have to let them screw with the "National Security" Absolute Block Size Limit ?

-MarkM-

Bitcoin: because if its good enough for A Good Wife its good enough for a hubby.

(Main objective is it needs research to even begin not to "WTF" so might motivate some searches. Or might not.)

Okay how about making max block size a configuration file / commandline variable?

From then on, no hard fork of the code would be required to change it, only, potentially, a hard fork of the blockchain?

Shops can have signs on their doors warning customers about the actual setting that shop uses for max block size, and customers can choose higher size supporting shops if they feel confident risking their money in blockchain branches they think might end up with less hashing power behind them than forks adopting a more traditional / more conservative limit?

Customers would maybe prefer merchants whose limit is set so high only a few miners world wide can handle it thus that have lower hash power, plus their coins will still be safe back on the original size branch because no higher size block can ever move any original sized block chain's coins anywhere at all.

Merchants wanting to actually be able to receive real original coins on the real original chain will set their clients to not approve blocks larger than those of the original chain, the chain which established the damn things have any value at all in the first place.

Maybe we should make two forks right away, a double sized block and a half sized blocks chain, and see which chain's coins best retain or gain value?

The config file setting method of setting the max will at least get rid of all the "we have to fork the code" excuses / arguments, reducing it to each node's choice what value to put in its config file. Thus putting the power with the nodes, not with the developers. (Which might be a really really really crappy idea. "Eat shit! Half a million houseflies can't be wrong!")

-MarkM-

I think it is probably more like how we limit the speed limit to a hundred thousand miles per hour to limit the number of cars that can make the journey between point A and point B per unit of time, thus limiting the number of cars built because the slower the speed limit the number of people actually interested in going from point A to point B by car declines.

Or something.

-MarkM-

That just makes claiming it is not a currency and warning people not to treat it as one make all the more sense.

Do you have democracy in your country?

If so, what measures are in place to ensure that there is a viable market, without crashes, for votes, so speculators buying votes are ensured the price won't crash out from under them?

Just curious...

-MarkM-