I believe trying to synchronize each individual cycle of all threads to a unique sequential index will be prohibitively slow, hardly useful for even highly specialized scenarios. You can't seriously expect 'real-time' interrupts anyway.

Instead, I propose a much larger sequence of cycles per block, perhaps hundreds (or millions) of cycles. Then exactly like bitcoin, each node atomically submits a pre-computed bunch of bits as a transaction, which other nodes can verify. Bundled with other transactions, blocks are added to the public blockchain. Only the blocks are synchronized and only blocks increment the 2^63 time rows. And just like bitcoin, blocks can not confirm much faster than a few minutes otherwise your latency is greater than your error/synchronization rate, and the network will spend most of its resources thrashing.



You've sold me on the elegance of the absolute fewest axioms. Nearly all applications will first shebang some interpreter (or decompressor) followed by a script and data. How you get from NANDs and BITs to registers, addresses, words, gotos, loops, comparisons, stacks, and arithmetic is beyond me, but I trust self-hosting/bootstrapping has been done for decades and can be done again.



I posit that you can not have both synchronized cycles and voluntary execution.

If every submitted transaction represents some execution performed by a node voluntarily, and a block represents a collection of transactions verified by some miner voluntarily, then you can synchronize only those voluntarily executed blocks of cycles.

On the other hand, if you expect all cycles to be synchronized, then you must require that for each delta bit in the entire address space, at least some node actually executes/verifies it (which is probably impossible).

I don't see any way around it: Unloved code can not be synchronized. If no node bothers to execute a thread, it is a cryogenic zombie and can not be retro-actively executed.



Verifying data (with hash checksums) is trivial. Verifying x inputs, y algorithms, and z results is not trivial.



It seems to me that each block (time slice) must be verifiable in its entirety by any single node (just like all bitcoin transactions in a single block need to be verified by the rewarded miner). It's the past history that we can relax. We can assume that since no one has complained thus far, then we can be confident that the cumulative hash value of the previous ten years up to last month is probably true, but we still need to hash each current state in its entirety and hash it again against the previous cumulative state.

Phinnaeus, are you claiming to be or sympathize with Nazis?

Alternating funding of both Iran and Iraq wars over the past forty years has been classic Machiavellian divide and conquer.

Thanks Lonelyminer, I've had more than too little of the Christmas Gløgg to fully appreciate your post. But I suspect you put me in my place. Thanks for the education.

I believe you would need 'big heartbeats' of arbitrary (though constrained) duration. I should be able to set some data and code in time and space, and then after sufficient validation, to share that data and code as a library. Using the (three?) axioms: BIT, NAND, and a 320-bit POINTER, I begin by defining a basic assembly language with XOR, IOR, AND, NOT, multiplication, bit shifts, loops, comparisons, etc. This would require enormous amounts of data (because each address is 1/3 KiB - I think you need much smaller relative address 'words'). I would expect its inclusion in the MerkelWeb to be atomic (like your version control analogies).

Each heartbeat is synonymous with a verified bitcoin-esque block consisting of numerous cycles. Inclusion in a block asserts valid code execution and resultant state. However, unlike bitcoin, I don't think the MerkelWeb needs to verify the ENTIRE address space. Perhaps you might add a third dimension, addressing isolated MerkelBranches, each with its own manageable blockchain. Personally, I don't want to spend a single one of my local cycles thrashing on some idiot's infinite loop. I prefer a DVCS analogy. I can arbitrarily clone and pull from any MerkleBranch (repo). MerkleBranches can reference across other MerkleBranches.



I imagine a transaction as a single node's assertion of code and data. I might allocate 100n merkleBits of a fibonacci calculator and submit that code as a single atomic transaction to the MerkleWeb. Since it is static code/data, it should have no trouble getting verified and included in a MerkleBlock by peer miner nodes. Next, I set a 'thread pointer' to the top of my routine and calculate twenty iterations of the series and submit the state and output register as my second transaction. Now a peer miner would need to re-execute my code and verify that yes indeed, he agrees with the state, before including the data, code, and execution state into another block.

In theory my fibonacci routine, once executed will run forever, unless it segfaults on pre-allocated finite memory. However, I rather think that some node must actively execute the code and submit the state as a transaction, otherwise if no node applies cycles, a program halts indefinitely.

What's the incentive? Verification of code and execution state included in a block is undeniable proof of local resource allocation. The miner can be rewarded with computational and storage credit, which like bitcoin can be used as fee, to inject new code and state into the MerkleWeb.



I disagree with this. As written above, I believe execution should be every node's prerogative. A thread is indefinitely halted if no node bothers to continue executing it (or pays credits for other nodes to execute it). Each transaction is an assertion of an arbitrary number of cycles and/or injection of data/code.



This is perfectly analogous to a double-spend, mining blocks, and reorg. There is only one longest chain of events, but it takes a few blocks to unambiguously confirm global state. It would require enormous computational power to change reality, "deja vu" Matrix-style.

Should we understand the MerkleWeb as a shared memory heap? Is each 'transaction' essentially a single memory space, or stack, and entire execution history recorded as a merkle tree since some earlier verified (fork) point in time/memory? Any node can voluntarily recreate any execution history? Does the MerkleWeb have 'blocks' a la bitcoin? Does each program/merkle tree run until exit, or can its entirely deterministic state and history be recorded in a block mid-execution? How do we reconcile multiple executions of the same 'program' with different inputs/race conditions? Have I processed an invalid path of confusion?

As for monetization/incentive: processing cycles, memory storage, and bandwidth are each quantifiable and valuable commodities.

Sure, OT + libbitcoin + GUI. At this point, it's too abstract for me, and 99% of people here. In the very least if there were a bunch of utilities, then I could bash script some stuff, slowly getting into it. By Google Wave analogy, you can't just build a beautiful palace underground and expect its brilliance to be self-evident. I know it's much to ask, but that's the way with software. We need to feel it, touch it, see it, use it, before we 'get it'. As it is right now, I can only smell OT, though it smells delicious.

For two parties with accepting services, Mt. Gox redeemable codes are much easier and faster to transfer than real bitcoins, but would offer no benefit over private key import/export.

Could someone please explain how a 'sweep' is more simple and less confusing than 'import and transfer'?

I realise the blockchain is slow. That is an issue. But it won't be solved by complicating local key management.

I'm interested, but like I've said before, I'm just as interested in franchising, or just buying the holo-stickers from someone with an established reputation (Mike, for example). Maybe southerners want to buy tupilakker with bitcoins up their... noses, which would still be valuable after the bitcoin is redeemed (like smashing a piggie-bank without the smashing).

Oh, then I would still suggest both local and network timestamps to normalize future wallet mergers.

At this time, I think it is best for a fledgling nation to mint gold rather than an unstable bitcoin. But I suppose on the internet, anything is possible. The flashing 'new' text on its webpage alone discredits the entire Wirtland project in my book. A legitimate and extant government in exile would be more promising.

I would expect confirmed transaction to use a canonical timestamp (agreed by the block chain) and would expect an unconfirmed transaction to have an estimated but similarly unconfirmed timestamp.


List transactions - the balance sheet in the local client? Could the local sent timestamp or autoincremented index be stored separately from the block timestamps?


For whom is this a requirement? I for one, would prefer my data was in consistent agreement with the rest of the network whenever possible.

I wish you would implement some of the bitcoin protocol within OT. I am frustrated with the conservative reference platform's refusal to embrace side-channel transactions. An OT client which didn't just facilitate smart contracts denominated in bitcoin but actually handled bitcoin transaction and key management would be killer.

Be careful not to follow the plight of Google Wave: a superior framework too abstract to catch hold.

I do see the absence of these very simple axiomatic key functions as show stoppers. Why do I have to be a guru to wrap up a card to be opened in ten days which reads:


And more importantly, why must my Dad be an über-geek to receive my paper coins?

Then it appears to me that this sweep 'solution' is more confusing, error prone and retarded than anything it's trying to solve.

I believe there are only two general use case categories: (1) I created two wallets myself and want to merge them for convenience or (2) I obtained a private key or a wallet from a third party and want to merge them into my existing wallet.

The 'confusion' due to case (1) is silly. I can't even articulate in a short paragraph how someone could be confused after merging their own wallets. As for (2), perhaps some users might not realize there is a double spend (race to spend) condition, so it is wise to suggest that the user immediately transfers the funds to a new address. After doing so, life should move on; All keys should behave similarly. If another party sends money to the imported key, no problem. If the original creator of the private key forgets that he gave the key away, no problem. How is this user, the one importing, going to get confused? Because there's an earlier history?

Yes, correct, assuming your passphrase is strong and your computer has not been compromised.

As any populist will tell you: YES YOU CAN!

I suggest you google BASE, MB, M0 versus M1, M2, M3. A bank can not print paper dollars, euros, yuan, but they can create M2 credit (aka money) just as I can create M2 bitcoins. A fractional reserve bitcoin bank can get into just as much trouble as a traditional bank. The only difference is that no one lender of last resort can bail out a bitcoin bank through monetization (printing).

I can take bitcoin deposits from all of you and lend virtual bitcoins. As long as I keep up a confident smile and not all of you simultaneously run to withdraw, I can keep the ponzi scheme fractional reserve system in perpetuity.

Genjix' libbitcoin fits the bill: https://bitcointalk.org/index.php?topic=30646

Bitcoinjs (based on node.js) is quite modular.

and Open-Transactions is a crypto platform/library with heavy bitcoin support.

This seems to suggest that an swept private key would not be (even after transferring funds to a new address) imported as a first-class citizen like all other private keys in the wallet.

What do we mean by re-sweep? Once the private key is imported, rescanned with the full latest block chain, is there any need to re-anything more before another import?