My BFL Single arrived today...it is now mining successfully with bfgminer-3.1.0 (I had to upgrade from 3.0.2 to get it to work). It is getting close to 60 Gh/s. It is being powered via two PCIe power connectors from a typical computer power supply and it's being driven by a Raspberry Pi (which is also driving a jalapeño).

Whoa: http://www.zerohedge.com/news/2013-03-20/spain-bitcoin-run-has-started

Featured Story on Zero Hedge right now.

Here are a few pics from an Atlanta Nodejs Meetup last night...we did a presentation on Bitcoin and Bitpay to this group (of ~50 developers).  Maybe about half of them had even heard for Bitcoin before.  Also, I have to say this was one of the coolest (if not the coolest) offices for software company I've ever seen.  It was at Thrust Interactive, a game software company.  They bought an old photography studio (basically a warehouse with a lot of photography sets)...they left all the sets in tact when they converted it into their offices.

In that other thread...Jeff commented that Bitcoin could not withstand a targeted cyber attack.  I expected him to talk about polluting the block chain or a DOS involving lots of spammy transactions.  But instead he seemed to imply we just need more full nodes and miners.  On the miner side, I assume that Bitcoin probably already has sufficient power, but perhaps it needs more diversity (something I expect cheap and easy to setup ASICs will help with).  In terms of full nodes, I would think a few thousand nodes would be sufficient to thwart a large scale DDOS attack (most DDOS attacks are successful because they target a very small set of servers...if you have to start targeting thousands, I think they would be much less effective).  However, if we want to encourage more people to run full nodes, here's an idea. 

Make a full node that is designed to serve multiple web based wallets (with keys never stored on the server except in encrypted form, etc).  Web based wallets are convenient but unsafe, even the ones that never expose keys to the server (the service provider could always change the Javascript code at any time).  For this reason, I'm reluctant to recommend such services to my friends and family.  I'm also reluctant to recommend they run a full node.  I personally want the convenience of a web based wallet, but I also want to run a full node.  I want to run the full node on a server I control that's only indirectly connected to the broad Bitcoin network through a grid of other full nodes.  I want to connect with a web browser to that node for my day to day wallet usage.  And, I want this to be the wallet I recommend to friends and family (that way I don't have to ask that they place trust in someone else that they, nor I, might not know that well).

I think this model would be preferable to having just a few large web based wallets that everyone uses.  It would strengthen the network because many of us would operate such nodes for the benefit of our circles of family and friends and it would reduce the dependence on the few web based wallets that currently exist.

Bitcoin is on ZeroHedge…
http://www.zerohedge.com/news/2012-11-02/friday-humor-ecb-explains-what-ponzi-scheme-awkward-silence-follows

The Blockchain.info app is back on the app store…no idea how that happened, but install it now before Apple changes their minds again.

The bitcoin URI specifies the following query parameters:

  label: Label for that address (e.g. name of receiver)
  address: bitcoin address
  message: message that shown to the user after scanning the QR code
  size: amount of base bitcoin units (see below)
  send: used to send bitcoin, rather than to request them

It would be nice to add another parameter called singleUse (or something shorter) to indicate to the wallet that the bitcoin address should not be retained for future use.  At bitpay we see a few cases where people accidentally send coins to an old address…it would be nice if the addresses we present aren't retained in the senders wallet to prevent this from occurring.  It would also be nice if wallets didn't automatically remember any address unless explicitly requested.

Thought this would be of interest to people here…
http://www.extremetech.com/extreme/133067-unbreakable-crypto-store-a-30-character-password-in-your-brains-subconscious-memory

there are probably many other kinds of patterns that the brain would be good at learning…these 3d gesture input devices come to mind (http://www.technologyreview.com/view/428350/the-most-important-new-technology-since-the-smart/) …I can imagine an disconnected device that reads your gesture input, hashes it with a domain name and userid and yields a long password for use in authenticating… the software or website could communicate the the domain/username to the device and the device could communicate the secure, generated password back to the site…that would be the only communication the device was capable of once initialized.

I was thinking about allowances, awards, and such for my kids…in the past we've used a regular bank account, this has proven to be a hassle and incur silly fees.  The point was to teach them about banking, but given the hassles, we just started keeping track of a balance outside of a regular account.  I'd also like the kids to learn about virtual currencies.  In particular I'd like them to get accustomed to securing a wallet and sending and receiving bitcoins.  However I don't want them using real bitcoins until they're a bit older.

At first, my thought was that it would be great if there was some software that worked basically like Bitcoin, but uses a centrally issued coin (no blockchain, etc).  I could issue them and they could use them or redeem them if they wanted to buy something, etc.  I thought of open transactions (and maybe I'll still look into), but I really want something very simple that works very much like a typical Bitcoin client works (with similar a addressing scheme, etc).

My second thought was maybe I should use Bitcoin, but scale it down such that 100 satoshis can be redeemed with me for 1 bitcoin.  But then I have the issue of having yet more copies of the block chain.  Are there any clients that support running one node in the house, but allowing multiple other wallets on other computers to connect to it (so that I only need one copy of the block chain for them)?  A second issue is that such small value transactions may take a long time to confirm (and might be considers spammy…a fee wouldn't work because the fee would be worth more than the few satoshis themselves).  I think I would want to avoid using web wallets…all of the ones I know about seem to be unsuitable for one reason or another.

The ideal here would probably be a version of the bitcoin client that worked with a centrally issued coinage and block chain.  It would be nice if it even simulated block generation every 10 minutes like the real Bitcoin system, but of course didn't actually use processing power to secure it…I'm fine just having a computer in the house that is the central authority.

Is there any way with the current Bitcoin-Qt client to share the block chain with multiple wallets?  Ideally I'd like to be able to do that when the multiple wallets are running concurrently.  From looking at the directory structures, about the only way I can see is if you swap out wallet.dat with the desired wallet when you start it up.  I now have about 5 copies of the block chain on my computer…I'm looking for options to consolidate around a single copy of the block chain.

I'd love it if the wallet functions and the client functions could be separated into two different processes.  Another way of solving it would be to enhance the Bitcoin-Qt such that it could manage multiple wallets (even just a feature to open a different wallet.dat file from the file system).

In the thread about Eric Schmidt's comments regarding Bitcoin, I began digging into Google Bucks.  It turns out he mentioned it in his 2011 keynote at the Mobile World Congress (see the other thread for the video and time ranges).  During that segment he also talks about NFC.  He mentioned a secure, 80 byte code that is embedded into NFC devices.  Previously I had just thought of NFC as a communications protocol, but these comments made me think there's more to it.  If NFC devices have an 80 byte code embedded in them, then presumably this is a private key of some sort.  If these devices are only available through providers that collect identifying information about you (i.e. mobile carriers that make you pledge your first born to obtain a phone), then surely they can connect any NFC device back to an individual.  And if they can do that, they can trace your every financial transaction (and if it becomes popular enough, perhaps your every communication).  I'm not an expert on NFC, but I wonder whether the standard is such that any person can create their own NFC device with a uniquely generated private key (good), or if they've instituted measures that ensure NFC devices (and the associated private key) can only be obtained through channels that would connect your identity to this NFC key (very bad).  I'm concerned it's the latter.

This poses the question: is NFC actually a strategy to institute a system whereby all communications (especially financial communications) can be tracked (by institutions that don't have your best interests in mind).

Bitcoin was featured again tonight on Freedom Watch with Judge Napalitano on the Fox Business Channel.

If no one implements this, I will.  I post it here in the hopes someone else will beat me to it (I've sat on it for a while because I had hopes that I could implement it myself, but alas, there is too much work and too little time).

I think the whole namecoin idea is flawed.  They've implemented a separate currency to trade for domain names.  However, as CommitCoin has demonstrated, it's possible timestamp any document using the bitcoin block chain.  If you further establish a depth first, left right rule regarding the merkle tree of transactions, then it's possible to establish a community agreed upon ordering of arbitrary documents.  These documents could be anything, including contracts for the initial claim of a domain name and the subsequent transfer of those domain names.

I think that should be all the clue anyone needs to implement a better namecoin system.

There is still a risk of a chain split even with a backward compatible change such as BIP16 or BIP17.  To avoid that from happening, Gavin is trying to get miners to commit to supporting one of the BIPs up front and then coordinate the timing for them to actually switch over.  But lets say he gets the commitment, sets a date for the switch over, but for one reason or another, only 30% of the miners start enforcing the new rules.  Let's also assume we have a miner that's not restricting itself to transactions that are considered "standard" (*ahem* Luke-jr*).  In this scenario, you could see a transaction that is considered valid under the old rules (may not be standard, but could be perfectly valid), but which is invalid under the new rules (see one of the methods of spending a BIP16 or BIP17 transaction under the old rules without authorization).  You now have a chain split because the old chain still has 70% of the hash power and the new chain won't be able to outrun the old chain.

Now, to be clear, I don't expect this to happen with the BIP16/17 transition as I expect the miners will all do what they're expected to do and pretty much all transition to the new rules.  But it does rely on people acting in a coordinated fashion.

So, here's how I think it could work in the future that would work even if miner coordination is botched.  Clients should be designed to support 2 script engines and their associated block chains.  The script engine could be factored out as a shared lib or some plugin that could be installed or swapped out independent of the client itself.  Normally, people would just have one script engine installed and the client would just manage a single block chain.  But when a script change is being implemented.  A new script engine could be distributed.  People would install this second script engine.  When two engines are installed, the client would keep track of two block chains and would validate all transactions against both block chains and refuse to accept or propagate transactions that don't successfully validate against both engines.  If the script changes are backward compatible, there is a good chance there won't be a block split even though there are two script engines, so the client is just managing the single block chain as usual (but still validating all transactions and blocks against both engines).  Miners can then decide on a schedule to start performing validation using the new script engine and attempt to make the transition in a coordinated fashion.  But the good news for everyone else is that if the miners screw up, they only hurt themselves and not everyone else.  Some of the miners might be creating blocks with worthless coinbase transactions, but that's their fault for not getting their act together.  Miners will have a very strong incentive to all be mining on one chain or the other…so any division of mining power between two block chains should be very temporary (it should only take a few days at most for the super majority of miners to get on the chain that appears like it will be the survivor).  Once it becomes clear that one of the engines/chains is going to survive (this might be indicated by blocks appearing at very long intervals or the difficulty plummeting), people can drop the dead chain.

I think this (or something close to it) would enable smooth transitions in the future, even if the changes would lead to a chain split.  The only requirement would be that the proposed new chain still support old style transactions (perhaps the new engine could reject long since deprecated transaction styles in order to phase out the use of them, but transaction styles still in widespread use would need to be supported).  In fact, a chain split might actually be preferable in this case because you would know definitively which set of rules are being enforced by the majority of miners (with the proposals for BIP16/17, assuming a split doesn't occur, you don't have a reliable way to know for certain if the majority of miners are actually enforcing the new BIP16/17 rules).

You could distribute a new script engine months ahead of a proposed date for miners to switch over.  That would give ordinary users a fair amount of time to install the new engine and prepare for the change (especially if the change will cause a chain split).

----
* I actually think it's good that we have a pool that accepts all valid transactions…I would be more nervous if no one accepted strange transactions and no one was thinking about the implications…if someone can do something that might compromise bitcoin, someone should do it (as a white-hat kind of exercise).

In thinking about p2sh and about the whole topic of the recipient of a transaction being the one who has the incentive to see that a transaction makes it into the blockchain, I've arrive at this potential solution.  Note, for bit-pay (as well as other processors), having the recipient set the transaction fee could be quite beneficial.  We occasionally get very low priority transactions that, while being perfectly valid, take forever to get into the block chain.  It would be nice if we had a mechanism where we could ensure it will get the appropriate priority with miners.

What if instead of transactions being included directly in the block chain, they were instead put into a container that could hold multiple transactions.  A sender could deliver a transaction to the recipient who could then add another transaction that pays a fee.  Loose transaction could move about the network as always, but until they get put into a container, they are ignored by miners (at least for the purposes of inclusion in a block).  There might be other uses for transaction containers.

I realize that this would be a radical change for bitcoin and not likely to happen anytime soon, but I'm curious if anyone has thought of alternative ways of doing this (ideally that preserve the simplicity of the sender just paying to an address without requiring the recipient to communicate anything else up front)?

Like Bitcoin itself, the value represented by P2SH transactions is enormous.  Probably second only to bitcoin itself.  You can read about the various use cases for p2sh on these forums, I won't rehash them here.

For some enterprising individual, there is enormous wealth to be gained.  You can bypass this whole debate about BIP 16/17.  All you need to do is implement p2sh in a manner that is better than either BIP 16 or 17.  I would suggest a complete rewrite of the script engine.  Do it in a language of your choosing so long as it is approachable by many, open source, and very well tested (unit tests with code coverage analysis is preferred).

Forget about backward compatibility.  You are going to fork the block chain.  You will do it deliberately by injecting a p2sh transaction into the network that the old bitcoin block chain accepts and that yours rejects.  This will be the shot fired across the bitcoin bow.  Your script engine must accept all current bitcoin transactions with the exception of coinbase transactions and their derivatives (so almost everyone's transactions will be perfectly valid in your block chain and the original bitcoin chain).  People will look at you like a lunatic until they start to realize your script engine is indeed better than the original bitcoin script engine and that p2sh transactions are a killer feature.  Once this realization sets in, people will desperately rush out updates to the bitcoin block chain…or they'll even try and start using your script engine on the main bitcoin block chain…but by then, your software will have been so well tested with many clients already supporting it, and enough miners committed to it that it will be a lost cause.  The remaining hold outs will simply flock to your new block chain rather than reinvent what already exists.  And by then you may have mined the better part of a years worth of bitcoins'.

The discussion in the mining forum and the upcoming transition to support p2sh is very interesting.  As a miner, you have a vote on such changes to the bitcoin protocol.  Your vote is proportional to the amount of mining capacity you control.  The mining pools are being asking to voice which of the proposals for p2sh they support by stating their preference in the blocks the create.  This got me thinking…as a pool operator, taking a position could be risky.  Miners in your pool that don't agree with your position might leave for another pool that was inline with their position.  So, one thing the pools could do is divide up their operations such that the miners could connect to one of several servers, each of which takes a different position on the issue at hand.  This lets the individual miners register their votes however they wish and they don't have to jump to another pool.  Good for the miners and good for the pool operator.

In the future, I would love to see mining hardware sold as a little solid state brick device for less than $100.  Just about everyone could run these miners to help secure the network and ensure they have a vote in its future direction.  Pools could make it simple for you to configure these devices.  They could also notify you about proposed protocol changes and let you register a vote by configuring your device accordingly.

I started thinking about this question when studying the proposals for p2sh implementations.  Here's how I would change it:

First, the scriptPubKey shouldn't be a script at all, it should just be a hash value (a bitcoin address).  All transactions would be a "p2sh" transaction.  Second, the scriptSig would not include the operations that setup the initial stack (the initial push operations that you typically see).  Instead, there would be another field that holds the values for the initial stack (which would typically just be a signature).  The scriptSig would also include an assertion at the beginning that verifies that the proper number of values are on the initial stack (this would prevent the hole that Gavin mentions that allows nodes to stick extra stuff at the beginning of a scriptSig).

You could probably mimic this in with bitcoin in the following ways:
1. Only allow 2 types of scriptPubKey transaction types (the traditional one, and one that verifies the code hash similar to the BIP-17 proposal)
2. Only allow PUSH operations before OP_CODESEPARATOR in the scriptSig
3. Add a bit of code after the code separator that verifies the number of items on the stack (note, I think this would close the hole that Gavin mentioned about pre-pending stuff to the scriptSig)
4. Add a new opcode for pushing a code hash onto the stack

So, a typical transaction would look like:

   scriptSig: [signature] OP_CODESEPARATOR OP_DEPTH [1] OP_EQUALVERIFY [pubkey] OP_CHECKSIGVERIFY
   scriptPubKey: OP_CODEHASH [20-byte-hash of {OP_DEPTH [1] OP_EQUALVERIFY [pubkey] OP_CHECKSIGVERIFY} ] OP_EQUAL

(note: OP_CODEHASH is a fictitious op code that computes the HASH160 of the code starting from the most recent separator and pushes it on the stack)

Are TestNet coins really trading for $1.90???  I looked at CryptoXChange.com and that's what it shows at the last price (although the best ask is lower than the best bid which makes me wonder).

Is it possible to construct a pair of transactions such that either both are accepted into the block chain or neither is accepted?  Is it possible to do it with three transactions?

Edit: meant to post this to the development section.