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-

Yes. Personally I happen not to care whether there are any fees to be had in making a block or not, only that processing blocks remains viable even if the only fees one could ever hope to make doing it come from all the many interesting applications that could spring up in the merged-mining space.

For example I do not want namecoin to be unable to be merged-mined alongside bitcoin due to bitcoin being such a massively bloated high speed neverending stream of worthless spam/dust that even given the huge hashing power it brings to the problem of securing blockchains it is just insanely impractical to process the damn thing, let alone in the context where it is not even your main profit-centre, just a chain-securing resource you would like to use to secure your cancer-curing genes study or whatever application you happen to be using a blockchain for and are looking to secure that blockchain.

One could merged-mine against the highest difficulty alternative high difficulty hashing provider, but if one's app turned out profitable, that would in effect be to support a potential attacker of bitcoin instead of supporting bitcoin.

It seems better to hope to be able to have the bulk of the world's SHA256 hashing power merged mining alongside bitcoin than to plan on diverting enough of it away from bitcoin to make all other chains secure.

-MarkM-

It is not the only constraint necessary, even if it is the only one necessary for motivating / profiting miners.

We still should have an absolute limit, and (possibly unfortunately for miners) it does seem prudent that the absolute limit be at least slightly larger than whatever limit suffices in slow seasons to support miners. Christmas might only come once a year, but it does come. So the max limit should be high enough to accomodate Christmas even if miners find it convenient or expedient to create blocks smaller than the max the rest of the year.

-MarkM-

Isn't a huge huge amount of the increase in transactions so far attributed to what seems to be basically an app designed expressly for the purpose of artifically/frivolously spamming the blockchain with frivolous/trivial, even "dust spam", transactions?

If so it seems more to show desperation on the part of some bigger bigger bigger agenda than any real need. Especially the dust, that is pretty much an attack really, even if intended to highlight a problem existing with tiny value transactions so it can maybe be addressed.

-MarkM-

Again, please no going back.

If it absolutely must be raised, raise it.

But no decreases, ever.

Miners can voluntarily not use the full max size all they want, right now they aren't using the full max size, but we aren't going to lower the max just because they aren't actually using it all yet.

Heck if we want the kind of adaptive that reduces as well as increases we should forget all this yelling about needing to increase it and instead discuss how much and how fast to DECREASE it because MINERS AREN"T USING IT.

-MarkM-

Yeah who knows what new thing will be out?/ It took long long time before Ripple finally got actually implemented.

It is something more like Ripple that is our competitor / plug-in-replacement for Paypal; Bitcoin is our competitor / plug in replacement for the units of account themselves, the fiats, not for the apps that play with them / use them.

-MarkM-

Good, yes.

One of the biggest advantages of the every reward halving idea was knowing well ahead of the exact block size to upgrade for and the date by which to complete the upgrade.

By the way it also occurred to me we aren't necessarily even competing against a six months final settlement with paypal, six months is the optimistic case; if they go bankrupt / into receivership there can be clawbacks going back up to a year. So imagining we need paypal's level of transactions on the blockchain is silly. Nothing a paypal type service 's customer does would even go out to the blockchain for six months, whereupon they can send one amount per other bank, gateway, wallet type service to settle up the grand total balance of trade of all their users six months ago.

Think Ripple IOUs as our paypal layer, with maybe quarterly redeeming of mass of IOUs at a gateway to put actual coins on the blockchain.

-MarkM-

Hmm Satoshi wrote that over two years ago and we still aren't actually close to needing it yet.

Still I guess it mostly depends on how many more years it is going to be before someone actually goes out there and signs up Walmart or President's Choice or A&P (are they still around?) or Sainsbury's or something and actually shows us a little of this vast flood of users they keep yelling is going to descend upon us any moment now.

So far it seems possible the volume of ranting about vast numbers of users coming at us is actually inversely proportional to the number of users the ranter actually has signed up lined up ready to bring aboard.

-MarkM-

Sixty Minutes, not Six Months! - for Final Settlement use Bitcoin!

-MarkM-

Well only for BBQcoin, because it is so fun, but not for all the scam coins like litecoin.



-MarkM-

Much the same probably applies to the security.

Before the twin towers got knocked down, did people vote in the removal of of what liberties or privacies they had not already lost by then? Or did it take a catastrophe  to make an entire nation or maybe even continent finally upgrade its infrastructure enough to hopefully make it invulnerable to that kind of attack going forward?

Of course some people are not going to want to be invulnerable to a too large block, as they are going to want to be the attacker. Others will not because they cannot afford the far far too excessively huge setting the fat cats think is fine for a max block, so simply will not put enough resources in place to handle it.

When the attack comes, paralysing the whole nation we'll be going like damn just leaving the max block size at a reasonable level would have nipped that in the bud. Prevented it outright.

We really kind of need it to be achievable all around, not so high that tons of pipes never actually bother to even try to really be capable of it because it just seems like some number the megacorps put in to blow them away with, not a reasonable defensive measure at all. If it is there so the megacorps can blow you away you might as well just wait for them to blow you away instead of blowing yourself away voluntarily ahead of time by trying to upgrade to prepare for it when you aren't even getting anywhere near enough transactions yet to even fill the current limit.

Remember, final settlement with, for example, paypal, takes six months. So having transactions take up to six months to finally get into the chain is a good thing, its by design in networks like paypal.

-MarkM-