I don't think that is actually necessary, really?

What does your block 86425 look like and what is its hash? Is it actually different?

I think there is something other than those checkpoints that is causing connects to be dropped and so on.

I had a hard time just getting a second instance on my same machine to connect to my first instance. But finally after changing the order in which I started them up I got them to connect.

If you recall we did compare what block we were on etc, plus also I have recieved coins osmeone (maybe even it was you?) sent so it did seem we are both on the same chain, which should not even be possible if your block #86425 differs from mine.

-MarkM-

No, because bitcoin will never have more than 21 million coins.

DeVCoin has the issue because there is no actual real limit to how many DeVCoins there will be; it makes 50,000 more every block forever, so some day, I do not know when, should have more coins than can fit into the "int64 devtoshis" format used on the blockchain.

But, that just means no one transaction-input or transaction-output can have more than int64 devtoshis.

-MarkM-

You are proposing to sell income-earning / money-making "assets"? In short, "investments" or "business opportunities"?

Or is it just that by using an affiliate scheme, maybe even a multi-level structure of affiliates, you hope to attract affiliates who will try to earn money by selling your idea/product?

-MarkM-

One person told me one, in private message, that I use with -addnode. But that was in a private message, and my own node has no incoming port, sorry. Set yourslf up with an incoming port though and people should find you, and if they don't then give out your own node's IP and port for others to use -addnode to tell their nodes to reach out to you.

-MarkM-

0.8's blockchain uses 128 bit integers?

-MarkM-

Maybe the incentive is "multiply the fee your local (or trusted, or least-hated, or least-distrusted) blockchain-audit corporation charges you for consultations regarding the verity of the blackchain by the number of such consultations you expect to or want to make, and compare that cost to the cost of running a node so that you can audit it yourself"

-MarkM-

As I said really the limit is the use of int64 in the blockchain.

We'd need a blockchain based on, I guess, 128 bit integers instead of 64 bit to really lift the limit properly.

The constant set as 21M though maybe could be tuned up to maxint64/100000000.

-MarkM-

We need to go over the user-interface again, making sure it rejects any attempt by the user to send more than max number (currently probably 21M) coins at a time.

It might even turn out that it is the GUI that is allowing it not the deamon, as I know nithing about wxwidgets nor QT widgets and input/output forms/templates and so on thus I'd think myself far more likely to have missed a spot in the GUI code than in the daemon. But maybe not, maybe both don't check user inputs against the max and reject ones that are too large.

I also wonder what will happen when a user interface tries to tell aq user the total balance of a wallet or account if that wallet or account contains lots of addresses that each have the full 21M coins in them. I don't even know if doubles (double precision reals) are used for such displays and the addition that leads to them or if int64 is used there, a timebomb waiting to overflow the integer. I vaguely recall or have an impression that I had a cursory glance at it but I think I basically took it on faith from Unthinkingbit that it is the total per transaction/address that needs to be limited, the grand total of all coins in existence of in a wallet or account or whatever not being limited to using int64., Not sure though at this late date.

-MarkM-

Which boils down to is it or is it not a zero-trust system?

I suppose you'd argue it is a limited entry level zero trust system, a system that is zero trust for the megacorps and any sufficiently wealhy nations or other sufficiently well heeled players, but for normal folks is just another trust the big boys / trust the grownups / trust Big Brother system?

-MarkM-

Ten times the block size seems like scarcity is banished far into the future in one huge jump.

Even just doubling it is a massive increase, especially while blocks are typically still far from full.

Thus to me it seems better never to more than double it in any one jump.

If relating those doublings to the halvings of block-subsidy it too slow a rate of increase then maybe use Moore's Law or thereabouts, increasing by 50% yearly or by 100% every eighteen months.

It is hard to feel like there is anywhere close to being a "need" for more space when I have never yet ever had to pay a fee to transfer bitcoins.

-MarkM-

Think "to throw out windows".

-MarkM-

I don't know, but I don't think bitcoin 0,8's code will fix it, as the limits constants inherited from bitcoin aren't any different from one version of bitcoin to another.

So if we can fix it, we can do so right away, with a fix to the current old-bitcoin-code based DeVCoin; no need to wait for some day when we get around to making a version of DeVCoin that is based on the 0.8 bitcoin code.

Basicically if we can figure out what number where in the code is preventing it from being processed into a block, we will then be able to check whether preventing it getting into a block is necessary; if it is in fact necessary we should fix the user interface (the RPC calls for sending coins, and whatever the GUI code to do it is in the GUI version) to prevent users from being able to do such transfers in the first place, so that they never get sent to the block building system in the first place.

I suspect the problem, at root, is that users are being allowed to [try to] send more than 21,000,000 coins at once.

Possibly we can also adjust the actual limit constant definition, which is probably currently set to 21,000,000 coins, to (maxint64/100000000) too, if that is so much larger than 21M that such a change is worth stepping away from the number 21M that coiners already have genetically coded into their expectations of maximum number of coins of a bitcoin-based / bitcoin-derived coin system.

-MarkM-

EDIT: As to actually losing the coins, probably if you double-spend them, that is, send them in batches of less than 21 million somewhere else, your new transactions might get into the chain, making the old one obsolete, leading to it being dropped from the memory pool. If that doesn't work without a fee, maybe adding a fee too could help if the block building code actually does prioritise transactions that have fees over ones that have lower fees or no fees. Whether clients tend to allow one to easily attempt such re-sends aka double-spends I do not know.

(That might be where newer bitcoin code might come in: maybe the old code we used does not have coin-control and does not have a raw transactions RPC call.)

No, because the hard limit is a hard limit on how large of a "little guy" they could push out, and that limit is, basically, guys so frikkin tiny that pushing them out gains so little the effect is lost in the noise of more not quite that extremely tiny guys coming online all the time.

Basically you can't kick out the little guy, given the current hard limit; you can only kick out the trivially tiny guy who isn't even worth the trouble of kicking out.

-MarkM-

Only if all the folk we are worried about clearly identify blocks they make as having been made by them.

Absent voluntary identifying of themselves who made a block is unknown, they are pseudonymous just like any other bitcoin-address.

And even if they do vokuntarily identify blocks they make that they want us to know were made by them that would not force them not to make any other blocks they don't tell us were theirs.

-MarkM-

Hmm I am pretty sure we tried to increase a bunch of the "highest number of coins" constants when we created DeVCoin, but, I think that there is one that  limited by the fact that the number of "devtoshis" is a 64-bit integer. So the for-real limit caused by using 64-bit integers should be maxint64 divided by one hundred million.

Thus I think we ended up trying to limit the number of coins at any one spot in the binary representation to the inherited 21-million number. I cannot recall if that meant no more than 21 million at any one address or no more than 21 million as any one input or output.

I think actually it might have been, no more than 21 million in any one calculation, so whenever adding them up or multiplying them etc the result must always be within the limit.

Arguably 21 million might not be quite the very largest number of whole coins a 64 bit signed integer can represent, I don't recall ever thinking too hard about that, maybe just figuring Satoshi likely already had and had thus tuned the total minted coins in the original bitcoin to be a number of Satoshis that int64 can handle.

-MarkM-

Oh, it is not actually a transaction that is in the blockchain? (Zero confirmations?)

I thought you were talking about a block that is in the blockchain, thus one that presumably has more and more confirmations all the time.

And it has no fee? Or does it have fee?

-MarkM-

It is not even arbitrary in itself, once you already accept halving the block subsidy. It is simply an attempt to give the miners more space to sell to make up for lowering their subsidy.

Now if you want to argue that changing the subsidy over time is arbitrary, leading to the limit of 21,000,000 coins being arbitrary, well yes you've got me there. But, the actual total number of coins is irrelevant as no matter how many coins "100% of all bitcoins" happens to be it remains "100% of all bitcoins" so how many that is in various units of measure other than "fractions of the whole" it happens to be is kind of irrelevant (and making it look different cosmetically like calling it millis or macros or megas or picos or whatever is purely a user interface design issue).

-MarkM-

Once I get my free Ripples I will be able to start telling Ripple about all the various altcoins I would like to exchange for each other and for Ripples. That will just be a stopgap measure while I wait for the ability to flag an account as a "destination code required" account so that I can start trying to adapt the sample "web-based gateway between bitcoin and Ripple" code to other blockchain-based currencies.

Basically I am looking to issue Ripple IOUs denominated in the various coins my Open Transactions server already supports.

Hopefully those IOUs will help people to more easily exchange between those various currencies, however my model is more like e-gold or Pecunix than, say, MtGox or Vircurex or Bitparking. That is, the intent of the tokens/IOUs is to be long term 100% fully backed tokens backed by actual coins buried so deeply and securely in cold wallets that ordinary people are not expected to be causing the vaults to have to be dug up and dipped into on a day to day basis; rather, it is intended that market-makers buy and sell the tokens to help people get in and out of the markets.

Nonetheless if I can adapt the web-based-gateway code to alternate chains I might well end up running one of these market-maker type operations myself (a hot-wallet operator, basically) in addition to my token issuer operation (a cold (very cold!) wallet operator, basically.)

As to the specific currencies aka assets I already support in my Open Transaction server and thus hopefully will be able to also bring to Ripple, see http://galaxies.mygamesonline.org/digitalisassets.html

-MarkM-

Re sucking in more users, if it is precisely an increase in the number of users that threatens us with all these problems in the first place, maybe it is time that we stopped being so eager to suck in more users. We are working nicely so far with the users we already have. If more want in that is going to cost us a lot, so using freebies that cost the whole population of full nodes, including miners, a lot, precisely to attract more new users faster, does not seem that great an idea.

-MarkM-

If I recall correctly, pretty much the only, or at least the core, argument in favour of allowing any free transactions at all is as a propaganda / public-relations scheme to suck in more users. Basically a free loss-leader.

Aren't we getting to a point where anyone who wants to blow wealth on giving out free loss-leaders can do so themselves, simply by paying the damn fee themselves or lowering the prices of what they are selling by the amount of the fees involved in the actual selling of the thing?

For example, merchant terminals could add an input from their own float account to the transaction before presenting it to the buyer for signing of the buyer's input, or publish separately a transaction with fee that takes one or more recent payments of customers as input. (This latter though would make verifying blocks harder, since verifiers would not be able to tell whether a free transaction has sneaked into the block simply by checking whether the transaction contains a fee. So maybe free transactions are not yet being rejected by verifiers simply because verifiers are currently too simplistic to recognise cases in which the fee is being provided by a dependent transaction? We could however, make each block able to be verified as to its lack of free-riders by requiring any such method of providing its fee be in the same block.)

-MarkM-