My understanding is that blocks that are not on the best chain are still relayed, otherwise people will get stuck on the wrong chain.  So even if the block were only sent to the target, the target should have relayed it and the rest of the network should have seen it.  The network does not know which fork will be extended next, so everyone will have to have both.

An "innocent" fork that occurs by pure chance should have the characteristic that all transactions in the abandoned block are included either in the "true" block of the same height, or in the next block.  I think reversing a transaction will require a transaction in an abandoned block to be invalidated in the "true" fork due to a double-spend.  It seems unlikely that such a transaction reversal could happen by accident.

When the block chain forks, the "true" chain is ambiguous by design.  The algorithm only promises that it will resolve eventually.

There might be ways of reducing the likelihood of this attack, but it is inherent in the system.  You stop it by waiting for several confirmations.

It looks like

and
and
but

So, if I'm reading this correctly, if the priority is high enough and the block it's going into is small enough, then the transaction can be free, as long as none of the outputs are too small, in which case the base fee is charged instead.

Edit:  COIN is the number of satoshis in one bitcoin, which is 100,000,000.  The valuein for the purpose of priority is measured in satoshis.

You don't need to mine 2 blocks in a row.  Mining a single block is sufficient if the network resolves the fork the way you want, and it might be possible to set things up so that this is likely.

Let's say I observe the timing of when nodes are broadcasting transactions and how they are propagating through the network.  By watching for which nodes are earliest to broadcast transactions from my target, I manage to establish a direct connection to my target.

I use a similar method of watching block broadcasts to establish connections to most of the mining pools.

Now I create a transaction making a valid, large deposit into my target.  I do not broadcast this transaction but I add it to a block that I am attempting to mine.  I mine solo, just like normal, except that I have an extra non-broadcasted tx that I am including.

Eventually, I succeed in creating a valid block.  I do not broadcast it immediately, but instead I wait until someone else mines a block, and when that happens, I immediately broadcast my block to my target.  If my target sees my block before the other block, they will accept it, and my transaction will have one confirmation.  The block chain has forked, and my target (and possibly other nodes, if my target relays quickly enough) will believe that my block is the correct one, while other nodes will believe that the other fork is the correct one.

I immediately request a withdrawal, and my target generates a transaction sending the large amount of coins to an address I control.  I also double-spend some of the inputs, sending the coins to myself.  The part of the network that did not receive my block first (which hopefully is most of the miners) will accept this as valid and work to include it in the next block.

If my block eventually "wins" because enough miners saw my block first and added onto it first, then I have just made a deposit and withdrawal, and I lose nothing.

If my block eventually "loses", then the deposit is invalidated.  If the deposit tx was not one of the inputs to the withdrawal transaction, then the withdrawal is still valid.

Writing blocks to a flat file is not very ACID, and there is no attempt at something analogous to BEGIN TRANSACTION/COMMIT when updating the block chain or indices, so a failure part-way through a reorg is very likely to leave the database in an inconsistent state.  Granted, both of these problems are outside of BDB and do not reflect on the strength or weakness of BDB.

I would say that bitcoin is effectively using a NoSQL "style" by not taking advantage of consistency guarantees, or of a relational model, both of which I think it would benefit from.

Berkeley DB, as it's being used in the existing bitcoin client, is a perfect example of why not to use NoSQL.

Building the dependencies with MinGW takes an eternity.  Not sure where the blame lies (as if it matters), but it is really painful.

Not only that, but they are also huge in terms of file size.  After compiling, they are nearly 4 GB.  Yes, disk space is cheap, but it's definitely not all necessary.

I think I'll put together a set of minimal binaries for the dependencies for Windows + MinGW.  No reason to go through all that unnecessarily.


As for missing .h files, double check the path names in the include path (-I on the command line) and double check that they exactly match the names of the directories on your file system.  Watch for subtle differences like dots instead of underscores or dashes.

Ok that makes sense.  I am a bit concerned that even though the update is a single statement, it must touch a lot of rows, but it should be infrequent enough to not be a problem.

My next question is regarding the very common operation of determining whether an output has been spent.  Each output could be spent in a single transaction that belongs to multiple blocks (in separate forks) or by multiple transactions (also in separate forks).

So it seems that to determine if an output has been spent in a particular chain, you will have to query for all the inputs that spend the output, find (JOIN) the transactions that contain those inputs, find (JOIN) the blocks that contain those transactions, and see if any of those blocks have a span range that contains the chain in question.  I know databases are supposed to be good at this kind of thing but it sure sounds like a lot of work.  On the other hand, most of the transactions will not have a double-spend, so all the joining shouldn't make a difference in the most common case where there are no inputs that spend a txout.  All the joining might slow it down a bit when the blockchain forks, but a few extra indexed lookups shouldn't be that big a deal I guess.

I'm thinking I'll switch to your schema with the spans, because it bugs me how my version has dynamic fields marking whether a block is part of the 'best chain' and whether a txout has been spent in the current best chain.  It is a real headache to add a block to a fork other than the current best.

Great work, I just have a question about the span.  I don't understand how it works, because if you fork the block chain, won't all the existing span numbers have to be incremented?

I've been trying to implement a sqlite backend (so far just dump to sqlite which is mostly working), and it seems to be helpful to distinguish between dynamic data and data which is immutable such as the successor relationship between blocks, transaction containment within a block, etc.

Whether a block is in the best chain and whether a txout has been spent in the best chain is dynamic, so I have to implement queries that more or less correspond to ConnectBlock and DisconnectBlock.  I would love to be able to eliminate it using your span mechanism or something similar but I'm not understanding how it works.

Have you considered using OpenTransactions in addition to bitcoin?  OpenTransactions allows an issuing party to issue certificates which can be traded.  It is quite different from bitcoin but I believe it complements it well, especially in a scenario like you are attempting to construct.

It has been suggested elsewhere on this forum, but I'm not sure if you have seen it or thought about it.

The bitcoin block chain at a low level is basically two things: it's an eternity service and also a timestamping and race-resolving service.  And as such it can be used as a public communication channel.  It is possible to layer additional protocols on top of it, and although it is far from ideal, it is possible.

Implementation details aside, at the core, you are establishing a system of deposits and withdrawls and transfers between account holders.  That part is not particularly problematic, but treating the deposits as if they were a new currency does not fit very well because the deposits are not at all cash-like.  The deposits cannot be transferred without the participation of the deposit holder, so they are more like checking accounts.

Now in addition, if the 'bank' establishes an understanding that accounts will be held in some asset other than bitcoins (gold, let's say), then that could be a benefit to account holders who don't want to be exposed to the risk of bitcoin value fluctuation.  It would be incumbent on the bank to properly position their assets rather than gamble with the account holders' money, but that's up to them.


The implementation details are not great, but it is doable.

Asking an institution to hold value in something other than bitcoins is not unreasonable.  The exchanges do it after all.

But if it is not cash-like, then I don't see a lot of point to integrating it so heavily with the block chain.  Since a central institution must be involved anyway, why not simply register a key with the bank and sign checks that transfer value from your account to another account?  All of the accounting and double-spend checking has to be implemented by the bank regardless, so the advantages of the block chain are really not being used.  Even a public, synchronized communication channel is not necessary.

One major consideration is that the proof of work, as it's currently defined, has zero dependence on outside data.  This gives it a certain robustness, whereas if there were some dependence on a job list or some kind of computing grid external data, then the security of the entire system is degraded to the security of the external data source.  There is no guarantee that the jobs are as hard as they need to be, or that the system can't somehow be gamed or cheated.  The current double-SHA256 is impossible to cheat without breaking SHA256.

Better to just buy and sell compute cycles using bitcoins, rather than try to fit useful computations into the block chain proof-of-work.

I listed what I believe to be the supported build configurations, which is my intended purpose, not the family of the underlying OS itself.  I have nothing against other flavors of Unix-like systems, I am just unsure whether they can use the existing code and makefiles and have everything just work.

There is some flexibility in the interpretation of "or similar" for the Linux or BSD option because I recognize there are varying degrees of similarity between Unix-like systems.  I would say if bitcoin compiles and works with little or no tweaks, then it is "similar" for the purposes of the poll.

If your friend cannot easily compile, and is having to port to Solaris, then I would say that would belong in the 'Other' category, not because it's in any way inferior or not Unix-like, but simply because it's not similar enough to a supported configuration.

Remember that dew occurs due to radiation of heat into space.  This radiation can cause the temperature of an object (especially an object with low thermal mass such as a blade of grass) to drop below the ambient air temperature and sometimes below the dew point, causing condensation.  This radiation is minimal with the computer under a carport.

If your computer is on, (even if not mining) the generated heat should more than compensate for this, whether protected by a carport or not.

If your computer is off or might lose power, then it is possible, but even then the carport and case should protect the interior from dew.

This is not about which platform is 'better' but which platform you currently use for development and building.

If you can come up with a way of combining proof-of-work (as in securely provable) together with general-purpose useful work, that would be a wonderful thing.  To my knowledge, nobody knows how to do this.

How would you want to handle the problem of rounding?

Not that I think it will have a lot of financial significance, but it is possible to get into situations where multiple txouts could yield slightly different total value depending how they are spent.

There is also the problem of agreeing on time, and even the time between when a transaction is issued and when it is included in the block chain could make a transaction over-spend its (now shrunken) inputs, or create other sorts of "slightly off" errors.  It might make sense to define the demurrage time in terms of the block chain and not in terms of 'wall clock' time.

An alternative is to have the underlying implementation store non-shrinking coins as they are now, with no demurrage, and to change the user interface to map a nominal demur-coin to the underlying non-shrinking coin according to a formula.  Then the underlying implementation would be represented in terms of coins-at-a-particular-point-in-time which are converted to present nominal demur-coins by a pre-determined time-dependent ratio.  There is still the problem of 'slightly off' errors if someone is asking 1 DMC in payment and you make the 1 DMC payment but by the time they receive it they get only 0.99999999 DMC.  If this is a human recipient it makes no difference but an automated payment processor could reject it.

Seems the natural solution would to be to have an "address watch list" that can maintain balances at addresses without the private key anywhere in sight.  I would have expected the wallet to use something along those lines internally anyway, but not sure how hard it would be to expose that functionality with arbitrary addresses and no private keys.

It is simple to secure a compute node against running malicious code, but not at all straightforward to secure a customer against a malicious compute node.  At least not without huge overhead.

A marketplace for 'compute cycle futures' is also subject to default risk if the compute node cashes out and never delivers, so they will have to be bonded (or something equivalent).

But despite these challenges, I think this would be a great direction.

There is a world of difference between trusting an external agent and trusting the protocol.  They might achieve the same ends but they are nothing alike.

You are entitled to your own opinions about "the idea behind bitcoin" but to me one of its key features is wherever possible, to do through technology what has traditionally required trusted institutions and intermediaries.  You already have limitless control of paper in your mattress.