I don't know anyone that uses Bitcoin for gambling for a start (and I know a lot of Bitcoin users with a lot of Bitcoin).

So if you're assuming that all Bitcoin users are gamblers (which it seems you are) then maybe you might have made a mistake.

But again - it's your theory and you're welcome to it (certainly I am never going to pay it any attention).

You are of course welcome to use whatever imaginary figures you like - but don't expect anyone else to actually take that seriously.

(as you are seemingly basing your figures upon assumption after assumption that you are making)

Well - I know for a fact (not just an opinion) that some people create "canary" brain-wallet addresses with a small amount to act as a warning for their more complicated brain-wallet addresses that are based upon the "canary" one.

(and such addresses are quite likely to have under 1 BTC in them)

Bad assumption - you could equally assume that you have found the cold storage amounts of many individuals (big or small).

I think it is simply going to be impossible to tell the difference between cold storage and lost keys (a bit like trying to locate every piece of gold ever sold).

Also in regards to small amounts people do use "canaries" for brain-wallets.

I wouldn't think that would be a very good measurement at all (am sure there are many people that have had Bitcoin in cold storage for more than two years already).

There was a topic a few years back about lost Bitcoins (from memory at least 100K have been likely lost) but even if we inflate this figure to 1M over the next ten years it really isn't such a big deal (we go from a possible 21M down to perhaps 20M).

Ships loaded with gold that sank hundreds of years ago are perhaps a similar thing (i.e. as we progress forward the chances of losing large chunks of Bitcoin by accident should be reduced by improved wallet implementations).

Also it doesn't really affect the velocity due to the divisibility (something not as easy to do with gold).

Yes @molecular that is precisely what I've been trying to explain.

In the case of CLTV we can't know whether or not a tx that uses this new (reserved NOP) is valid if we are running older software but once a block appears that has this op-code in it then we just treat it as NOP (assuming that whoever mined it knew that it was valid).

Whether or not we relay such txs isn't actually overly important - the key thing is whether or not such txs are included in a block that you mine.

This allows someone to run the older software without being forced to upgrade (whereas a hard-fork requires you to upgrade).

No - it would not (as it could not know whether or not they are valid).


Yes it would as it assumes that whoever has mined them did know that they were valid.

Are you starting to get it now?
(fingers crossed that the penny has dropped)

Also without relaying you actually wouldn't have a P2P network at all (so it is an essential part of the system not some optional thing) and there are expectations that a node will not relay invalid txs or blocks (and any node that does will be banned by your client).

One last time and then I really do give up.

It is not an "either this or that" and that is where you are just getting it wrong (repeatedly).

As stated (on three separate posts already) validation isn't just a simple and single concept.

There are different validation rules depending upon whether you are mining, relaying or verifying a block (i.e. context).

So the rule about a NOP is not the same rule in all three situations (something that you just don't seem to be able to grok).

(also - I am assuming that you know that both txs and blocks are relayed and that the rules are also dependent upon whether you are relaying a tx or a block)

We have tried again and again to explain but you simply refuse to even read what we post (and just keep on quoting one or another thing to keep on repeating your non-point) - so I'm done with trying to explain things to you (this is also off-topic anyway).

I would advise that you don't try to make suggestions about how Bitcoin should work when you don't even understand how it currently works (or how it used to work for that matter as relaying has been there since day one).

(I have read the code and have been a software engineer since the 1980's)

It was explained to you that the op code is *valid* in the context of validating a block (so of course the block would not be rejected by older software). Why do you think it is called a NOP?

If you still cannot grasp such a very basic concept as how this stuff is working then I suggest you simply stop with your "analysis" of Bitcoin because you will never get it.

(and btw - much of software deals with many practical things such as byte size limits that don't apply to math in general so you're not really making any sense with that statement either - if we were talking about pure maths then the block reward would never end for a start)

I still have one XP OS machine running Bitcoin and found that Bitcoin 0.12 simply won't work on it (both the blockchain and/or wallet seem to get corrupted every time I try to use it and it even screws up using -regtest which you would expect shouldn't have any problem).

Basically I've decided that it isn't worth pursuing trying to get it working on XP so am no longer going to try doing that (it's probably a good idea to move to a more modern OS in any case).

It would perhaps be nice if there was a list of OSes that each version has been successfully tested on as part of the release notes but one shouldn't expect it to work with an OS that is no longer even supported by its creators (which is why I never reported the issues that I had found).

Your logic seems to be completely confused - so let's take a practical example to try and help you to understand (although I get the feeling you're not interested in actually understanding this at all).

Let's look at CLTV and see how that works. The NOP code becomes OP_CHECKLOCKTIMEVERIFY after the number of nodes supporting the soft-fork has got to the correct level (that is determined by the super-majority mining new block versions).

At this point a script that uses this previous NOP code now enforces a rule check to make sure that the nLocktime is greater than or equal to the value on the stack (if not then the result is zero).

This is a restriction not a relaxation (as it can now fail this test) - when any node that hasn't upgraded sees this in a block that has been mined then it will also accept the script as valid even though it didn't do the check and this prevents a fork (as it is indeed being treated as a NOP for such nodes and the value that was pushed onto the stack is the result which is non-zero).

If it was a hard-fork then existing (non-upgraded) nodes would not find blocks that included txs with such scripts to be valid - but as stated *this is not the case* (and again you need to understand the difference between relaying, mining and validating but again I'm sure you'll just refuse to admit that there is any difference and insist that it is all just validation).

If you want to keep on arguing about definitions without actually bothering to understand how the system works then I don't think that anyone here is going to keep on wasting their time trying to explain it to you.

Bitcoin isn't some sort of theoretical model but instead is a practical piece of software (so it doesn't actually care about what you think the behaviour of things should be according to what you think the terms should refer to).

Unfortunately although we have already created (and tested) an ACCT Bitcoin script that uses CLTV the UI side of things is what really takes quite a bit of time and we don't think that releasing an unfriendly and mostly manual implementation would be appealing to virtually anyone so the work to develop decent UI (for the Bitcoin side of things) and to improve the UI on the Qora side of things will take some time.

That being said I do think we should be able to end up with something that is user friendly and that will be very robust (an estimate at this stage is a little hard but I would certainly think that you could expect to see a release by mid-year with this functionality).

It was not previously illegal and will be interpreted as doing nothing by unmodified software (in scripts that might appear in later blocks) so although the unmodified software doesn't know what that op-code does it won't worry about it as far as validating the script goes (important assuming that the soft-fork succeeds).

Because the unmodified software doesn't know what the NOP is intended to do, however, it won't relay such a script (nor would an unmodified miner mine it). This is because the unmodified software knows enough to know it can't be sure if the script is valid or not.

Got it?

(there is a clear difference between relaying, mining and validating)

That will only guess a final character (i.e. is assuming you missed the very last character only). If you are not certain which character you missed then you'd need to basically repeat like this:


(hope that makes sense and of course the first character is always going to be the 5)

I think @vbcs was taking a bit of time of to "charge his batteries" but I think that he is keen to continue work soon.

So you do realise that if we had followed Satoshi's idea then Bitcoin would have actually failed because the number of txs could not be processed in 10 minutes (or don't you care about such facts)?

Again - the guy who says he is not a "Classic Shill" just shows that he is.

As one person that would make perfect sense - but as IOTA is not "one person" that makes no sense at all - does it?

Hint - if you look at @CfB's post calling to reduce the number of topics attacking IOTA it is clear they don't really have many people at all (perhaps nearly all that they have are sock-puppets).

So my advice would be to create ten more such topics and "wear them out" (it probably won't take more than a week to see them making a big mistake due to being too tired).