In fact I'd say that it's no different to operating an SPV client on a smartphone for Bitcoin (and is perhaps even less secure than that).

So - another point to those doing the marketing is probably going to be "forget the RPi and other tiny computers also".

@CfB - how will parallel chains help the situation?

Indeed - so I don't think there is any need to panic about getting the blockchain shrinking done overnight either.

I am more concerned with marketing campaigns that end up becoming a PR disaster due "ridiculously over optimistic" promises.

A product that delivers its promises is respected much more than one that "promises the moon" but never actually delivers.

Okay - I hope those doing the marketing will note this and try to not add that extra zero for now - Bitcoin is only currently *capable* of doing 7 TPS at this point after all so a more than 10 fold increase I think should be enough for at least a year.

@rickyjames - I must agree that I am also having troubles "swallowing" the 1000+ TPS "hype" when we are being shown no practical method and are now apparently considering adding more memory, CPU and bandwidth consuming ideas such as "Turing complete scripts".

Maybe Nxt should aim for a more conservative 100 TPS to avoid ending up looking very silly in a few months time.

It actually is rather tricky to explain (so my fault at not explaining clearly enough) - but it is actually a very elegant solution to a very tricky problem and in order to do NXTCash I think we are going to need something very similar to this.

@CfB - the "secret" doesn't unlock the bitcoins "on its own" but instead needs to be accompanied by a <sig> check (so no arbitrary 3rd party could come along and "steal" the bitcoin).

Basically person B has to provide a signed (but incomplete) tx to person A in order for A to be able to get the coin from B. Understand B won't do that until A has also provided him with the same (for the other chain) incomplete (but signed) tx (with the *same* SHA256 value being the "key point").

In order for A to get B's coin A will *have* to "publish" the "secret" (unless A also has B's private key) which then allows B to get the coin from A (due to the same secret being used for both scripts).

Understand that A cannot get *back* the coin (other than via the signed "nLockTime" refund) nor can anyone other than B *get* the coin as the coin is locked to a multisig address (with a clever script).

BTW - provided that A's refund timeout is a lot greater than B's there should be no "race condition" issue either.

See the stuff about "cross-chain atomic txs" - it doesn't involve giving out a private key but *does* involve a "shared secret" that makes it impossible to "steal".

It is only possible because Bitcoin "script" has an op code for checking an SHA256 hash.

I don't know about what would be needed to pay dividends - I was simply thinking of something like basic Bitcoin scripts (as presumably you'd want this "language" to be able to do useful little things like "cross-chain" atomic txs).

Oh - that is a slippery slope then - I think Nxt will be attacked pretty easily if we use the words "1000+ TPS" and then turn around and say "well - what we actually mean is the equivalent of 1000 TPS *in useful work*".

Also if said scripts can't do either EC or SHA256 without doing it "in assembly" I think they won't be able to do much in the way of "useful work" anyway.

Precisely!

I don't think you are understanding the concept of "trust" here - if you want to write some code that does that then just write it.

Why do you even need Turing complete tx's when you don't want them to be run without trust?

Each node (perhaps other than "light nodes") would have to *do* the crypto calculations as part of running the script otherwise once again you can just be tricked.

Again CPU may not be the main problem - but the size of the scripts would for sure be bigger than standard NXT txs are plus the VM "state" would also need to be stored somewhere (presumably as an AM - although currently that limits your persistent state to a paltry 1000 bytes).

Indeed I had thought that was what you *meant* (rather than what you actually said).

Do you agree that it should have op codes for things like SHA256 and what about the whole problem of the impact of running said scripts on the TPS rate?

I do think that "subleq" would end up becoming a CPU bottleneck but I am now going on the assumption we have an *efficient* instruction set (so am now ignoring the CPU issue) but I think that even assuming no CPU issue the bandwidth usage would become an even bigger problem.

Although the actual amount of CPU pain might not be overwhelming the real problem is going to be the "size" of the tx (I can't imagine that these scripts are going to be anywhere near as small as a standard NXT tx currently is).

The whole 1000+ TPS is about "size" (and "bandwidth") more than it is about actual CPU time.

So once again - do you want 1000+ TPS or do you want these "arbitrary script" type txs (as I don't believe that you are going to be able to have both)?

*Exactly* (had already made that point but I think it was missed).

CfB *himself* said 1000+ TPS would only be *possible* if protocol was changed to binary and kept "dead simple".

So - how is it now suddenly become *possible* to also execute (even just a few) instructions of VM "per transaction" (as you can't assume they won't *all* want to do that) and still have 1000+ TPS?

Does anyone else see the problem here?

*Exactly* - it seems there is a problem of "wanting to have cake and to eat it too" here.

It will be almost impossible to a have 1000+ TPS *and* be able to execute "arbitrary code" (and certainly not using low-end hardware).

CfB had already spelled out that to even achieve 1000+ TPS requires the "non-script" idea of very simple transactions and would also require a "binary protocol" (which currently is not being used).

Now you want to add a "Turing complete" VM to the mix and still somehow get to that magical 1000+ TPS?

So guys - I see it has being a case of wanting A or B - either you want A (1000+TPS) or you want B (arbitrary code execution a la Ethereum).

Apparently we managed to get even worse than that - I think maybe CfB might have changed his mind about this now.