You may want to portfoward or use uPNP to allow outbound connections.  I have found bitcoind more "stable" using larger number of peers. 
Honestly given the number of hosts with outbound connections I wonder if the inbound connection limit can be raised in a future version.

Yes but I don't show a lower hashrate (well maybe <2% lower) but that might just be noise.  I consider the 1%-2% worth it for the reduced variance (and the support it provides other miners who wouldn't choose solo over conventional pool).

There is no need to sell the private key.

transaction fees aren't subject to any taint list so ....

tainted coins in -----> coin melter* ----> untained coins out 

* coin melter simply makes a tx using tainted coins as the input a new address as the output and send a % to coinbase as a tx fee.

Using enough blocks one could convert all tainted coins into coinbase rewards.  At which point they can be used just like any other coins.

I never really thought a "container" file was useful but I am starting to see the merit.

Moving funds between wallets can be done but:
1) It does take a lot of manual steps.
2) Every wallet is different.

Also from a "meta" point of view it helps to extend the wallet analogy.  The cointainer file is essentially cash.  It is used to move funds from one wallet to another wallet offline.  If you give $10 to a friend you don't give him your wallet, or make a new wallet you take $10 out of your wallet, hand it to him and he puts the $10 into his wallet.

The file extension (.btc) is a new point which hadn't been brought up yet and an interesting concept.  Making it to that a btc file can be used by any wallet would be ideal.

So you convinced me.  Having a standardized format to "export" and "import" funds would be useful.  I think the next step would be for someone to write up a format v0.0.1 spec and create an RFC.  That will give us a starting place to move towards implementation.  Likely you will want lots of input from various client developers.

One thing I would recommend is a max size requirement.  This would ensure all containers can be converted into QR codes which is easy to transfer using mobile wallets than files.

The code doesn't send anything anywhere temporarily or otherwise, everything is done locally on the browser via javascript. 

I have looked over the code (it is just just javascript all the code is right there) and there is no communication to any server.

Still I would recommend that a user do what the the author has recommended ... save a local copy of the generation page.


1) save a local copy of the webpage from http://bitaddress.org
2) disconnect from the internet
3) generate your addresses
4) print 2+ copies (and/or encrypt a copy of output and store)
5) close browser, delete all files, and reboot
6) store your print or encrypted digital copies in multiple safe locations.

Copy the unencrypted wallet.dat to multiple usb drives.

Still you need to be wary on keylogger not just now but any point in the future you use the USB drive. 

Say you store 100,000 BTC to those private keys over the next three decades.  You plug the USB drive in 2042 for the first time.  The inject computer instantly detects an unencrypted wallet.dat circa v0.6 client and makes a copy, transfers the balance to the attackers computer all in <1 sec.

Honestly if you want offline security use offline security and forget the USB drive.

https://www.bitaddress.org

Two issues. 

The first is that pruning results in almost the exact same savings and is optional.

The second is how do you ensure the summary is accurate?  To verify the summary requires having all prior blocks anyways.

The reality is that over time MOST users will use lightweight clients which don't have the blockchain at all.  The nodes which do keep the blockchain (miners, paranoid users, banks, exchanges, merchants, service providers, etc) will want full functionality.

Well no that statute refers to both coins and notes however the point was that FRADULENT INTENT is required.

More info including letter from Treasury with explanation:
http://www.parkpennies.com/pressed-penny/penny-pressing-legal.htm

Condensation on the inside of the metal roof (like say when outdoor ambient temp is cool and below the dewpoint) which then drips liquid water onto the electronics.

So you lied.  Good enough.


It is right there in the quote.  The concept is called "coin melting".  It would render asinine ideas like "tainted coin lists" and "Bitcoin Police" beyond infeasible.  Currency must be fungible.  Having blacklists reduces the fungibility of currency and I see it as a threat to Bitcoin.

The block is a permenent record of tx.  If tx could be tacked on well that wouldn't make it very permenent would it.

The block header contains 6 elements one of which is the merkle root.
https://en.bitcoin.it/wiki/Block_hashing_algorithm

The merkle root hash is a hash of the tree contains all the tx of the block including the coinbase.

You don't "find" a block.  You find a hash of the block header which meets the difficulty target.   That hash is only good for that EXACT block header and set of block components  Change one bit of the blockheader and you have a completely different hash.

Since the blockheader contains the merkle root you can't change/add/remove any tx (not even one bit of one tx) without ending up with a different merkle tree and thus different merkle root and thus different block header and thus different hash.

If you could then mining wouldn't create a permanent record of anything.

Having one card per rig and horribly inefficient cards at that is a good way to waste a massive amount of electricity for a tiny amount of coins. 

I use 3x5970s (6 GPUs) rigs w/ an underclocked sempron and usb drive as the "hard drive" to mininize the host power because the host nets you nothing.  I am moving them to 4x5970s rigs to make them even more efficient.

I know it sounds harsh but mining the way you are is a good way to turn something into nothing.

Haplo I demand you back up your LIES with a cite.

Please provide a specific cite where I stated:
a) fees should always remain the same regardless of the market value of BTC
b) miners "deserve" 50 BTC per block in fees
c) how much fees are necessary to regain 50 BTC per block.

You will learn reputation is earned here and with only 49 posts you are starting out as a blatant liar.  I expect that when you can't find evidence to back up your lies you will correct your blatantly false statements about me.  We can disagree on the facts but I won't stand by when some fraking noob start lying to my face.    Regardless of your actions the quote will remain so others can see how little your word is worth.


Quoted for prosperity how little value Haplo's word has:

Sure we can do it as an experiment instead and any funds I receive will be returned.

Those blocks "from" Eligius are not Eligius blocks.  Eligius like p2pool has a direct payment in the coinbase very easy to spot.

Some time ago "mystery" started relaying found blocks only to major pools to hide the origin.  Blockchain.info only knows who first relayed a block not who mined it.

I use manual portforwarding instead of UPnp but the end result should be the same.  I just checked bitcoind and I have 21 connections.  13 outgoing, 8 incoming.  The bitcoind is unmodified except for api calls which allow excluding tx w/ low/no fee from work generation.


I don't use -otc so I guess you will need to find another endpoint.

Who will then relay it to a 1,000 or so nodes.  It is in a pools best interest to maintain a large # of connections to other nodes and pools to ensure a found block is propagated to a large portion of the network in one hop to win any block race.


Yes I understand the concept however your assumption is that the second well connected node will win a race against all the connections from 4 major pools despite 4 major pools having a headstart and win that race at a high enough frequency to offset the losses when a minor pool mines "my" tx anyways.

There are two competing tx
TX A = payment to your self
TX B = payment to me (which you intend to have reversed by A)

For the double spend to work you need:
1) TX A seen first by majority of hashing power/pools
2) TX B seen by enough nodes to propogate to me before the "path" gets blocked.

If #1 happens but not #2 then I never see a 0-confirm tx
If #2 happens but not #1 then I get "paid" (confirmed).

In an isolation attack you have a good chance of accomplishing both #1 & #2 but that wasn't discussed.


I am willing to try it out.
The key point being that #1 & #2 both happen for you to "win".  Getting your tx into a block is easy but getting it into a block and me still seeing a 0-confirm is difficult.

I willl pay you 10:1 for anything you send to 17KBkkH3rfqTRUqV4mYD4XMFzy7GZ8y2Ai (newly generated address from my wallet) which shows 0-confirm but later is orphaned.  Obviously anything you send here that isn't orphaned I keep.

2^160 is a big number.  Even with Moore's law 80 years is not sufficient time.  I do agree that if Bitcoin remains active then eventually coins could be recovered but we are talking on a timeline of centuries or even a millennium.

Of course.  It is so easy.... er wait no it isn't.

Rising prices will cause people to NEVER (till the heat death of the universe) sell or trade. 

Is that your claim?  Really?  Can't find any flaws in it?