You still have to satisfy the multisig script.

Ok, say you want to use nLockTime to send money to yourself in the future to prevent an attacker from stealing the timelocked coins.  You create a transaction that will not be valid for a month (whatever) and broadcast it.  Then an attacker gets in and steals the private key for that address.  They can create a new transaction that sends the money to their own address.  Honest nodes will consider that a double spend and refuse to relay it.  But, if the attacker can give it directly to a miner, and if their attack transaction has a higher fee than the honest transaction, the miner now has an incentive to include the unlocked one rather than the locked one, making your timelock moot.

But, if you use M-of-N, and less than M keys are in places where they can be stolen (like on paper in a safe or bank vault), it is impossible for an attacker to spend, and even if a miner was willing to throw it into a block for a cut, it still couldn't happen.

No, there is no way to get the block number in a script.  People keep asking for it, but it wasn't left out by accident, it is missing for a reason.  (Please think about how the network handles block reorgs for a while before you ask...)

nLockTime has some issues.  For example, if you lose your keys, the network could see two transactions spending the same output, one locked until some time in the future, and one not locked.  If the unlocked one has more fees, miners might just take it instead of the locked one.

The "right" way to do this is with P2SH M-of-N, and make sure that less than M keys are online waiting to be stolen.  It also has the advantage that you don't need to guess the proper duration for the lock.

Sweet!  A way to (nearly) double my bitcoins with no risk!  Where do I sign up?

Haha!  IPv6 is coming "tomorrow" and has been since the early 90s.

I would say that most people depositing into traditional banks do not think of themselves as investors, or at least they don't think of their checking account as an investment.

There is a duration mismatch problem that is fundamental.  If a bank loans out money for a 30 year mortgage, but people want their money back sooner, the bank is screwed.  The bank is "good for it", but can't pay out today.  The modern solution is for a central bank to be able to create money out of thin air and lend it to the bank.

Since a bitcoin bank can't create money out of thin air, it always faces the possibility of a run.  Bitcoin banks could band together with an agreement to loan each other bitcoins as needed, and this would mitigate the problem during isolated or limited bank runs, but if everyone everywhere gets spooked at the same time, the game is up.

The solution is to be clear on both sides about repayment timelines.  The bank could not use demand deposits for duration loans, and the customers could not ask for early withdrawals on duration deposits.  Clever banks would attempt to mitigate this by creating markets for duration deposits, giving people an option to cash out early by selling the certificate to someone else at a discount (penalty), but it would need to be clearly understood on both sides that this system is not a promise of liquidity, but a last resort.

In 2001, the first (allegedly) quantum factoring was done, breaking 15 into 5 x 3.  Now, in 2012, a state of the art quantum computer has advanced to the point that it can factor 15 into 5 x 3, almost half of the time.  I think we have more than 5 years before QC starts threatening bitcoin.

Also, the existence of such a thing will finally force people to stop accepting 0-confirm transactions, hopefully.  Honestly, just the threat of it should be enough, but apparently it is not.

Over time, as bitcoin matures, services will spring up to handle the transaction risk.

False.  Money arose from debt, not barter, thousands of years ago.  But not in the way most people think.

Yeah, that is a fake news site.  Like The Onion, but not funny.

Right, they don't typically offer routes across their high speed network to the rest of the world.  The whole point is having a good system for connecting one I2 node to another I2 node, not improving the internet for everyone.  But the project also is for learning how to manage dynamic high speed networks, and that will trickle out to the rest of the world as the rest of the world upgrades their shit.

I realized last night that parts of this were off by 8.  Some of the numbers I put in were for 512 byte blocks instead of 4k.  It didn't help that 512 bytes is 4096 bits.  In particular, a tree chunk has room for 512 pointers, not 64.  They can cover 9 bits of index space instead of 6.  List chunks still have about 64 entries, it depends a bit on how much metadata you want to attach to them and if you care about alignment.

Also, when a list chunk gets full and converted into a tree chunk, it isn't necessary to create all 512 new list chunks.  You can use zero as a special value to indicate an empty list rather than creating an empty chunk.

If used to index the block chain (which will have an increasing number of initial zero bits over time), the root chunk can store pointers to initial zero trees, letting the system skip quickly to where it needs to start.  Pointers to zero bit depths of 18, 27, 36, 45, 54 and 63 should keep us happy for years to come in exchange for less than 2% of the dead space in the root chunk.

No, internet2 is mostly just a physical network, a subset of the internet, but with faster lines.  It carries same internet protocols and traffic that you are used to.  It just means that nodes on it have reliable high speed links to each other.

For example, Stanford can send data to MIT using private I2 links between universities across the country rather than handing the traffic to commercial carriers.

In IRC, we were talking about new index formats for the block chain.  Since most of the things we want to index by are random, this gets hairy.

I'm thinking of a tree of lists structure.  It should have pretty good performance even in the worst case, and be pretty safe under IO failures.

In practice, this is a collection of 4k chunks.  Each chunk starts with a header of some sort, probably very basic.  At a minimum, each chunk needs to indicate what type of chunk it is, and a chunk ID will make it very easy to keep a journal (see below).  4k was chosen because it is the native block size of modern hard drives.  It is also the native page size for virtual memory in lots of CPUs.  Memory mapped file IO should be FAST, not counting syncs.

The first chunk will be a tree chunk.  After the header, it has 64 pointers, each one 32 bits long.  These pointers are to chunk numbers inside the index file.  The first pointer is for the leftmost branch of a binary tree, corresponding to 000000, the second is 000001, the third is 000010, etc.  Lookups are very fast, simply isolate the 6 bits that are important, multiply by 4 and add the header size.  This could also be a different chunk type, a "root chunk" with extra metadata, but would mostly act like a tree chunk.

If a pointer is to another tree chunk (identified by the header) that subtree covers the next 6 bits, etc, etc.  In the block chain example, this means that there will be 5 mostly empty tree chunks, and the tree will be somewhat unbalanced.  The waste shouldn't be too bad, and a special case could skip through them.  If using this system for keys (or really anything but block header hashes) it will be more balanced.

If the pointer is to a list chunk, that chunk has a list of not more than 62 or 63 pointers (it depends on the size of the header) into the full block structure, each pointer is 64 bits long, just a byte offset.  Lists aren't necessarily sorted, but by the time you get there, it is just a matter of a few dozen comparisons.

Any time an insert would cause a list chunk to hit a high water mark, it triggers a reorg.  64 new list chunks and a new tree chunk are written and items from the old list chunk are distributed among the new lists.  Once those are done and synced, the parent tree chunk would be overwritten with a pointer to the new tree chunk.  Then the old chunk is marked available.  Since chunks are all the same size, the structure won't fragment.  Worst case is a crash just before updating the old chunk, which would leave 65 orphans.  Garbage collection should be trivial though, and the free chunk list easy to maintain.

For extra safety, writes could be done with a journal chunk or two, for example, reserve chunk #2 as the permanent journal, and any time you need to write, write there first, and then write the real chunk.  For performance, you'd probably want dozens or hundreds of journal chunks.  If they have IDs, any time you open the file, you can just replay anything you find there.  Zero the whole journal when you are done with it so that future writes can just start at the beginning of the journal and go in (write) order.

This system could be extended with a recent index buffer in addition to the main index.  This would be a third chunk type, but basically just a list chunk.  The difference would be a pointer back to the previous buffer chunk.  The buffer would be checked first, and the size of the buffer could be dynamic.  If your node mostly looks up recent blocks, most lookups will be buffer hits, so keep more buffer chunks.  If you get mostly buffer misses, you are wasting your time checking it, so keep fewer buffer chunks.

When the system is IO bound, the buffer could even have other uses.  For example, when used for the blockchain, during initial downloads, the buffer chain could be allowed to grow to unusual size, and kept mostly in memory, with completed chunks written only when full.  In a crash, only the most recent few dozen indexes would be lost.  When the node was caught up, it could then replay the buffers starting from the oldest chunk, and only freeing them after their contents were fully committed to the main structure.  This might cause a hole in the structure, but only once, and defragmentation would be easy.

Hard to say if the problem is the USB bus or the NAND speed (or bus).  I'll do a little research, see if I can find a fast USB 3.0 drive to test with.

I have serious doubts about killing flash drives.  Modern flash chips can take a pretty hefty number of writes and should last for a decent number of years, even if written to at full interface speed nonstop.

That said, for running a full node, USB flash drives are too damn slow.  At least the cheap ones I tried were.  I use RAM drives for everything now too.

supply and demand

wtf?

Depends.

If the 10 BTC is received to a key that was already in the wallet at the time it was backed up, you'd still have it.  If not, it would be lost forever.

I'm guessing it was either a first or last check, either of which is likely to (still) be done by hand.