Both of us can wait patiently together for the actual release of the source code of the server.

I hope to manage to adapt for various altchains the source code already provided for a web based IOUs-to-blockchain and blockchain-to-IOUs app, but that is on back burner until I get rippled source code, build rippled, and get rippled running.

You might notice in the running a gateway docs that gateway accounts should be configured to require destination codes. Configuring an account in that way is something else that so far seems to be best/easiest done using a rippled - a rippled of one's own so one can tell it RPC commands without needing to encrypt the commands. (The command to configure an account to require destination codes includes the account's secret as one of the input fields/arguments.)

Overall it has seemed so far that waiting for the server source code release is the current step in doing the above things.

-MarkM-

Automating awaits someone actually automating what they want automated.

In principle, if you trust a bitcoin gateway for some bitcoin(s), any bitcoin-IOUs anyone sends you should automtically arrive at your account as your gateway's bitcoin-IOUs, not as bitcoin IOUs of someone you haven't chosen to trust for bitcoins.

So, to automate your apparent current preference for receiving bitcoins, you need, in essence, to tell your ripple client whose bitcoins, and how many of them, you trust.

Of course I actually meant, as does Ripple, bitcoin IOUs rather than actual on the bitcoin blockchain bitcoins. Thus far.

So technically, you need to tell Ripple whose bitcoin-IOUs, and how many of them, you trust.

If other lines of trust that aren't even really your business, and are not any concern or worry for you, exist out there somewhere, someone connected through webs of such trust lines who actually has some bitcoin IOUs should be able to send some to you.

A really simple setup would be that that person happens to trust the same bitcoin gateway's bitcoin IOUs as you do, and that they have some of that same bitcoin gateway's IOUs, and those are what they send you. (Those are, after all, at this point in the story the only IOUs you have chosen to trust.)

So automating the reciving of "Ripple side" "bitcoins" which really means Ripple IOU-tokens, issued by some specific Ripple accounts, is relatively easy for you; all you need do is tell Ripple how many bitcoins of trust you choose to extend to each of one or more bitcoin-gateways.

Actually getting blockchain-bitcoins is something bitcoin gateways often offer as a service. Such as a website where, if you have deposited with them some of their bitcoin IOUs, you can ask to have the corresponding bitcoins sent to a bitcoin address of your choosing, on the bitcoin blockchain.

-MarkM-

Aren't you yet running into meatspace retailers who don't accept cards for transactions totalling less than somewhere around five bucks/loonies or so?

Or are merchants where you are still offering minitransactions (meaning, seemingly, less than five bucks/loonies or so) over card networks?

Downtown? (aka, is downtown / uptown more or less commonly doing this than less-trafficked parts of town?)

Are card companies losing userbase due to the common pedestrian's inability to buy a cup of coffee with a card unless they accompany it with a cookie, or other similar crippling failures to accomodate minipayments? (Wah, I can't buy a stick of gum with it, I am off to find a more useful alternative...)

-MarkM-

Nice post, thanks.

It seems to me there is both a lot of underestimation of bitcoin's agility and way too much tendency to hurrah "the sharks are starting to notice us, hooray!" while worrying nervously "so we'd better throw away our shark tank else they might not find us appetising!"

-MarkM-

Same objection as above; its even right there below it where you pointed to.

However I am starting to get a sense that maybe part of why it is not blatant to everyone could be an artifact of scale.

It might be that the sheer size/power/longevity/pocketdeepness of "offender" one imagines it might/would take, as compared to the scale one might be contemplating as an organic progression of "growth of our existing network" or of "adoption rates" is very large.

If you persist in thinking of new players entering the game as newborn from tiny startup / granny's basement it might not seem oh so very likely to be a problem, afterall who are these basement-dwellers compared to the likes of Deepbit and Eligius and other "massive" pools.

But in reality, in the larger scheme of things, our vaunted "most difficult proof of work on the planet", our entire bitcoin network, is puny, tiny, trivially so.

How many puny little ASIC-manufacturing startups are there and how many of their products are deployed so far?

How much "smart money" delayed getting into bitcoins for a year due to there being no point in investing in "to be obsolete any moment now, wait for it, any moment,,, coming up... wait for it...." new hardware? Have you seen any indication yet that such gear could impact difficulty significantly? How many hundreds of millions of dollars, really, does all their currently in production product really add up to so far?

Once you blow a few hundred million on a few regional datacentres doesn't it just make sense to balloon/skyrocket blocksize hard and fast to clear all the obsolete players out of the game? What sense is there in blowing hundreds of millions of dollars on securing a network that cannot even handle your own hundreds of millions of users, (you are, like, facebook or google or yahoo or microsoft scale of userbase, or even something really out of left field like a retirement fund with that kind of number of shareholders considering monetising your "user" (aka shareholder) base by controlling the "pipe" through whch others might be willing to pay to get exposure to them, gosh knows. Left field is a vast, vast field, even without whatever parts of it might also be "outside the box"), but imagining there are no "big boys" out there is maybe rather naive.

Every player, all players, in this current puny prototype prevision of what this kind of software could potentially accomplish, even all of us combined, add up to trivial, tiny, puny, still, even if every chip of every wafer of every ASIC in the pipelines that we know of turns out to work perfectly with no error regions etc (100% yield).

Pretending we are oh so capable of swimming with big fish, oh so tough and resilient, that we should throw away our shark cage seems insanely naive, reckless, foolhardy, stupid, exactly what the sharks hope we will do.

-MarkM-

I do not agree that it necessarily has any effect at all on blocks that are "too large", depending on who mines them and who they are directly connected to without intermediation of any of the proposed prejudiced nodes.

The top 51% of hash power can pump out blocks as huge as they choose to, everyone else is disenfranchised. You might as well try to stop a 51% attack by ignoring or refusing any block that contains a payment to a known major manufacturer of ASICs so the 51% attacker won't be able to buy enough ASICs to reach 51%. Oops, too late, they already are there. They but lack an opportunity for "spontaneous order" to hook them up into a "conspiracy" that is simply "emergent", not at all pre-meditated - in particular not premeditated-as-in-foreseen* by whoever got rid of the cap on block size, since they would seem to have apparently imagined some completely different "spontaneous order" than that in which whoever has the most [brute, in this case] force wins?

51% attackers can already do plenty of nasty things, now we're gonna hand them carte blanche to spamflood the whole network into oblivion too?

* No, wait, it has been foreseen, so surely if they implement it anyway it is, literally, pre-meditated, isn't it?

-MarkM-

Could there be more than one type/kind/flavour (or some such) of gateways, so that fiat gateways might always hold fiat that they owe to someone but other gateways (gateways other than fiat gateways) might owe things other than fiat, might owe no fiat to anyone, in fact might be as far as the fiat world is concerned fully funded debt-free entities?

If so then maybe, farther/further, might there be some way some how some such gateways might not be able to divest themselves of the call options they issued by merely tendering some species of fiat in liue of the actual contracted item, commodity, substance, or service?

("Sorry, you owe me one bitcoin. If you think one bitcoin has some correspondence to any kind of fiat, prove it by tendering one actual bitcoin, I don't accept fiat..")

(Maybe needing to avoid the term "debt", maybe also the term "owe", so maybe "Sorry, the contract says you will deliver/tender unto me one actual bitcoin. I'm not sure what that so called fiat is or imagines itself to be but it sure as heck is not an actual bitcoin...")

-MarkM-

Only if its not a good enough number to be used to #define a macro instead of a constant. As a muliplier that happens again by/in June 2015 (18 months after its Jan 2014 first application) though, who knows?

-MarkM-

Oh nice, an actual number, thanks! And it is less than a doubling of the max size, too!

Thanks. There ya go Gavin, we got a times two so far for, likely, the bottom of the range of values to have at your fingertips when time comes to type the proverbial #define



Sounds like maybe the times 1.5 each year won't cut it, but times two per eighteen months might still be in the running.

-MarkM-

Darn, I am guessing this isn't the thread where I had posted "in before someone says p2p means peer to peer, not person to person".

Think peer as in a jury of your peers, not peer as in member of the house of lords / big business old boy's network / etc. They don't run around looking for people of your own socioeconomic class to put together a jury of your peers, they run around finding all kinds of random folk off the street, some of whom might turn out to be owners of big businesses some of which aren't.

Unfortunately things like fire-sharing "p2p" networks don't quite fit "c2c" (consumer to consumer, as distinct from business to business or business to consumer) either, since the people/machines involved [can] both produce/provide and consume files.

Maybe we can differentiate p2p from P2P, making one mean peer to peer, (maybe capitals indicates its peer as in the guys at the capital in the house of lords) the other meaning person to person (the smaller / cheaper / lower case)?

(Hey, this is the internet, we get to make up our own terms / conventions / etc for stuff, right?

Free meenz moar beer!

-MarkM-

Leaving unchanged until closer to actually needing it to be raised was what I thought was being said in that ancient thread.

What did Satoshi say would constitute an actual need, as possibly distinct from lobbyist pressure or gosh knows what other things that could lead some folk to use words such as "need"?

Can haz moar? Needz moar moar moar! Must haz moar!

Who was it said "always leave the audience wanting more", or maybe it was "always leave them wanting more"? Someone with no knowledge of and/or experience with markets and/or marketing?

-MarkM-

And if that does happen, at that predicted time, the developers will have a much better idea of exactly how much to raise the hard limit by then, so setting the actual value of the #define can be a last moment thing just before they all compile the upgrade that fixes it.

Right now we don't even know whether it even will hit that limit that soon, and the soft limits make it pretty much impossible (more transaction fees than there are bitcoins to pay them with, I was told) to actually hit the hard limit.

(Admittedly, commenting out the soft limits would be a cheaper method of reaching the hard limit, but what percent of hashing power has done that so far? At what rate is how much hashing power doing it? By the end of the year how much percent of hasing power will have done it?)

Now don't panic about that "#define at the last moment" bit, I am thinking in terms of Gavin having obtained from us all by then a range of values and possibly a range of network conditions affecting the decision as to the final number to plug in, not that he will by fiat pull a whole different new number out of his ass that hadn't even come up in the discussions carried out between now and the end of the year*.

* "end of the year": an alias for "the time the fix is compiled for release"..

-MarkM-

Look up the user here whose nick/handle/username is "Dank". You two seem like kindred spirits.

-MarkM-

There is also a thread, maybe even this one, that starts with the premise that raising the limit before the optimisations are in place pretty much just invites not bothering with the optimisation, since the limit can just be skyrocketed, or eliminated, or increase over and over again (any time someone otherwise might have to actually materialise these vapourware optimisations even maybe...)

Which makes maybe a middle ground: deliberately crippled by the vaporware optimisation creators' or inventors' failure to materialise the optimisations.

Once optimal use is made of the size already provided, more size might reasonably be made available. While the size already provided is being wastefully wasted, throwing good size after bad doesn't seem like a good way to motivate materialisation of that vapourware.


If they weren't vapourware, they would probably have been adopted by now.

Increasing the size prematurely isn't scalability, its actual scaling. Heck even when it is time to do it (when it is no longer premature) it still will be actual scaling, not mere scalability. Get the difference? Scaling (actually increasing the size) awaits scalability (the mythical or vaporous or simply not quite yet ready to be merged-in optimsations).

-MarkM-

Sheesh!

I kept being tempted to impart this tip and kept refraining, but now I'm tempted to put "don't do it and warranty is void" in the (non-existent, so much for that idea) warranty:

Coin daemon startup scripts should include -rescan, *especially* so if they are started automatically.

Basically if you are not there yourself, with certain knowedge it was not e.g. the power company messing with your power or lightning striking or whatever that caused a start to be happening (due to a stop having happened... who knows how the stop was caused or what condition it left the wallet / blockchain in???), the default startup behaviour should always to be to -rescan.

Its in all my *colinstart.sh scripts, all of them. I have to manually hack it out to start a coin daemon without a rescan, then put it back in.

Which should only be done if you watched the stopping / going down that precedes this start, as its when it went down that is likely to have left a mess.

Ideally, GUI users would use -rescan too on startup, (build it into the command that clicking its start-icon runs! (Or if you use a config file, put it in the config)) but dunno if they'd have the paitience for it if of the "ooooh shiny, lets fire up client to buy it" type rather than the "oooh shiny, good thing I leave my client running 24/7 so I can buy without waiting through the startup -rescan" type.

-MarkM-

Maybe a little harsh, there; my take on the OP was more toward responding "yes, it is a market in action, if it pays everyone it will happen".

As it didn't seem to me to be saying miners could force it up by mining so much as that the soft limits we have in place that miners do get to comment out or adjust to their liking will provide feedback.

In other words, knowing that the miners only have the soft limits to adjust, benefit of the doubt along with recognition that the whole hard versus soft limits techie details was maybe a bit rich for his intended audience led me to the idea that speaking in terms of the soft limits rather than the hard limit possibly suited the article better.

-MarkM-

The FUD brigade's sky-is-falling / sky-will-fall FUD about how failing to make blocks too big too soon will cause a mass migration of users, hence thus presumably also value (else they aren't the important users anyway, maybe) from bitcoin and/or a failure to bring in new users (which, combined with the inflation rate from minting, also could lower exchange rates).

Or in short, "if exchange rates aren't falling, the sky ain't either".

-MarkM-

Hard forks should also get softer and softer over time.

For example some day one's operating system's package-manager might well be able to check the authenticity of an updated bitcoin package from the source you have designated to it as the one to trust, automatically. Even down to checking whether it is a "critical" / "urgent" update or a mere non-critical bugfix update.

The software could even come with a "warning, this version should not be relied upon to remain up to date beyond (some date about a year after its release)".

Any time bitcoin exchange rates fall drastically in response to too many blocks being full of paying transactions too much of the day/night, machines all over the world could find, during their nightly automatic check for package updates, an update ready for them to automatically install.

Sure a lot of security and trust details to get that all down pat, but provably repeatable builds from reputably attestedly audited and tested source code, which is already in place, is a nice step already in that direction.

-MarkM-

We don't want to spend bitcoins, hey are best saved, that is, used as a store of value.

The price of most alt coins is ridiculously low in terms of bitcoins, so although we would love to buy bitcoins with them doing so at these ridiculously low exchange rates is just a waste of altcoins, better to wait for their price in bitcoins to go up first.

Does talking about them effect their price-in-bitcoins? Hmm, dunno, lets try it and see.

Oh look, bitcoins are going up, no wonder altcoins prices are down, everyone who was able to get a much better price than the currently ridiculous rates for altcoins maybe bought bitcoins with them.

Wow, altcoins are cheap, one could buy up oodles of them for such trivial numbers of bitcoins that I doubt the bitcoin price would even notice. SO maybe my bitcoins will keep going up in value even if I dump a trivial amount of them on some of those ridiculously cheap altcoins...

I know some players look at http://galaxies.mygamesonline.org/digitalisassets.html and figure hey, bitcoin is no longer going down relative to alternatives, maybe bitcoin is the one to be holding right now...

-MarkM-

That is the only condition which changes between your conditions for adaptive block size and your conditions for a new constant hard limit.

Why is that? Do you feel that it is a foregone conclusion that an autoadaptive block size precludes fulfillment of such a requirement?

-MarkM-