More info here:

http://www.scribd.com/doc/216081750/Reason-Rupe-April-2014-National-Telephone-Poll

Thanks for the confirmation.  In future versions shouldn't the Keys be under Bitcoin-core not Bitcoin-Qt for consistency?


Good to know.  

I wonder though if this could be refactored to provide a more consistent behavior between the two clients.  For non-windows specific options wouldn't it make more sense to just write those to the bitcoin.conf.  The GUI client already reads the conf file for the presence of these options.

As an example, setting the pay tx fee option in the bitcoin-core to 0.1 mBTC GUI client adds nTransactionFee key to the registry however if the same user now starts up bitcoind it will use the default fee (0) because there is no entry in the bitcoin.conf.  Since an RPC call can be made against either bitcoind or bitcoin-core (w/server=1 option) the outcome of an RPC call will depend on where it is made.  Likewise if a fee of 0.2 mBTC is indicated in the bitcoin.conf then the client will still display 0.1 mBTC however the actual fee paid will be 0.2 mBTC.  The client does provide a warning that the setting has been overriden but this isn't exactly user friendly or intuitive.

Do you agree that keeping it DRY would be better?  Refactor bitcoin-core so that both bitcoind and bitcoin-core use the bitcoin.conf to store non client specific settings (i.e. data directory, tx fee, dbcache, proxy, etc).  The registry would only be used for client specific settings (location of windows, units to display, minimize handling, etc).

To be consistent that would also include the data directory however the registry can still be used indirectly by providing the location to the configuration file itself.
1) User launches bitcoin-core with no data directory created.
2) Wizard prompts user for location of data directory.
3) Create bitcoin.conf in directory is needed.
4) Set data directory in bitcoin.conf.
5) Add registry entry pointing to the bitcoin.conf

On startup the client would check for existance of "ConfigFile" registry key and if present load the bitcoin.conf to determine the data directory and other non-client specific settings.

Just something to think about to make the behavior of the GUI and deamon consistent.  The other option is to simply stop bundling the two and treat them like independent applications.

So replace a tiny fee for a much larger one?  Even if the system is feasible on a large scale (unlikely), there will still be counterparty risk.  You are trading direct counterparty risk with the risk of the assurance entity.  Still from a fee standpoint it would be a massive step back.  Your third party reinsurance entity isn't going to take risk for no gain.  Their reassurance fee would have to cover the costs of verify entities, establishing their credit worthiness, protecting against fraud, and covering the % of transactions which are defaulted on.  Fees are very low 0.1 mBTC per KB.  On a 1 BTC transaction that is 0.01% of transferred amount.  Can a third party reduce that cost significantly?  I would say no.

Bitcoin fees are very low 0.1 mBTC per KB.  On a 1 BTC transaction which is under 1KB that is 0.01% of transferred amount.  There are a couple of things which "could" reduce this further in the future. 

Currently miners ranks fees by the ACTUAL FEE / ACTUAL TX size.  The client however rounds up to the nearest full KB when paying fees.  This means that a user interested in minimum fees is overpaying what would be required by a miner with the same requirement.   For example say a typical miner requires a fee of 0.1 mBTC per KB and fees less than that are treated as non-paying.  With average tx being 600 bytes this means a fee of only 0.06 mBTC is needed (0.06 mBTC *1000 / 600 bytes) to be above the 0.1 mBTC threshold required by the miner.  Right now the client would round the 600 bytes up to 1KB and add a fee of 0.1 mBTC to the tx which is 0.04 mBTC more than required.  From a miner's perspective the tx has a fee of 0.167 mBTC per KB.

The client should be modified to make the fee paid based on actual tx size not rounded up to the nearest KB.  Miners already use this methodology for ranking tx for inclusion in the next block so it makes little sense for the client to use a different methodology when deciding on the fee paid.    

The fee required for relaying by v0.9 nodes has been reduced 90% to 0.01 mBTC per KB.   The client doesn't yet allow paying a fee that low (when a fee is required).  This is done intentionally to ensure that when the client does allow that there will be enough nodes which will relay those tx to avoid them being "stuck".  Future versions of the client will also allow creating at this reduced fee level.  

If you combine those two changes it would reduce the fee required to relay an average 600 byte transaction to a mere 0.006 mBTC (600 sat) or roughly ~0.3 US cents per tx.  Now relaying doesn't mean a miner will include it in the next block.  Some (or significantly all) miners may require a higher fee however those two changes will for the most part take the client and nodes out of the fee decision process (with a negligible mandatory requirement on low priority tx to ensure the network is safe from DDOS attacks).  It will be important for miners to be more open with their fee requirements so that users can make a better decision on what fee (if any) to pay.

  

It is bad but not that surprising.  There are a couple of bright spots though.

1) The % advocating a ban drops as knowledge increases.  If fact the only category which is >50% is a self described "none" for how much the persons knows about Bitcoins.  The sad thing is the number of people advocating a ban on something they (self described remember) indicate they know absolutely nothing about.

2) The % advoacating a ban is lower for those with more income and higher education.  Generally these are the types of people who vote more often and are who politicians rely on.

3) Support for banning Bitcoin is the lowest among the "undecided".  This is the group who decides every single national election in the modern United States.  So expect a lot of politicians to play a lot of lip service to their bases and then do absolutely nothing about it.  The ole "pivot to the center" move. 

4) The one bad demographics is something that time will resolve.  Support for a ban is highest among older Americans and right now that is bad because as a voting block they tend to have a high turnout however over a longer period of times (say 10 to 20 years) many of those voters will not be around anymore and since the younger demographics don't support a ban it should begin to even out.

Why would the average tx be 30K.  The average tx today is ~600 bytes and isn't projected to increase.

How much do you think paying for that coffee today with a cc costs?  A lot more than 4 cents.

Mining doesn't work that way.  Miners are always working on the next block.  If they have no tx to include it will simply be an "empty" (only the coinbase tx) block.

https://blockchain.info/charts/blocks-size?timespan=1year&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

The blockchain is currently increasing at ~1GB per month.  Currently there is a cap on the size of blocks @ 1MB ea.  If all blocks were 1MB the blockchain would be increasing by ~4GB per month.  If/when the cap is raised it could be much more than that.

As an alternative, there are "lite" clients which don't require the full blockchain.

FYPFY

3.  Block are larger and the average number of blocks that a transaction has to wait before confirmation has been reduced.

v0.9 changed the defaults for block size.  The chart is not showing the average time between blocks it is showing the average time to the first confirmation of a transaction.  There is a difference.  The average time between blocks has been significantly less than 10 minutes for months now.

When the bitcoin core client is launched on a windows machine with no established data directory, it will prompt the user for the location of a data directory.  Where is this value set?  Nothing is set in the bitcoin.conf. Registry?  Magic?

I like the feature I just don't like not knowing how it works.

Also bitcoind doesn't seem to use the same "data directory" discovery.  I have to add a datadir line to the config and point bitcoind to the config file to ensure it uses the same directory.

Looks like it might write it to the registry?


I wonder why bitcoind doesn't check for the existence of the same registry key for consistency?

Not sure where you got 65536 from but it isn't correct.  It takes 2^32 hashes on average to find one which meets the target for difficulty 1. 

Layered security my friend.  Routers have been compromised in the past due to bugs, exploits, and just generally bad coding.  If your router has wifi and an attacker is able to connect then he is already "inside" your network.

The critical resources being "purchased" is space in the blockchain.  Charging based on anything other than the size of the transaction would be as misalignment of cost and price.  It would be like a gas station which offered to sell you gas per mile.  It might be attractive with those driving Hummers but ultimately the gas station would go out of business.

Nodes don't rely on the target value so in theory it could be removed however it does allow nodes to identify bad blocks quicker.  If your node receives a relayed block which has a different target than what it is expecting then the block is invalid and validation can stop.  IIRC at one time altcoin pump and dumpers didn't even have enough skill to realize they needed to change the magic values and ports to ensure the chain will be independent from bitcoin so the clients would be relaying blocks that are simply invalid for the Bitcoin network.

Technically that you are right it isn't needed and it shouldn't be relied upon.  For efficiency sake nodes validate the header values first.  If they are invalid the block is invalid.  They validate the tx set next.  If any tx is invalid the block is invalid.  The merkle tree is constructed next.  If the computed merkle tree root hash doesn't match the root hash in the header then the block is invalid. Finally only after all that validation is complete the node will hash the header and ensure it produces a hash below the target.  The block is now valid and will be relayed to other peers.

The program is in a different folder than the wallet & blockchain.  The "data directory" is never touched when you install a new version.

No it didn't.

http://bitcoin.sipa.be/speed-lin-10k.png

I find it funny that blockchain.info has had numerous errors, glitches, and other problems over the last couple weeks and people treat it like the word of god on stone tablets.

Lets see:
blockchain.info says hashrate was instantly (as in a vertical downward line) cut in half
nobody else is reporting that
block times haven't suddenly doubled to 20 minutes on average

what is the likely reason for that?

Enough income (or hold less than 365 days)

If you hold the asset less than 365 days it is a short term gain and taxed at your marginal tax rate (10% to 39.6%).

If you hold the asset for 365+ days and your marginal tax rate is in the 10% or 15% bracket then your long capital gains rate is 0%
If you hold the asset for 365+ days and your marginal tax rate is in a higher bracket then your long capital gains rate is 15%

The cutoff is for the 15% bracket is an adjusted gross income of $36,250 if single or married filing separately and $72,500 if married filing jointly.

Well most entities don't report transactions at the transaction level to the IRS.  If that were the case then nobody would ever cheat on their taxes when it comes to cash transactions.   It would also mean that 99.999999999999999999999% (yes I know that is too many nines) of people wouldn't pretend they have no use tax due in states which "require" it.

Generally speaking only when an entity pays YOU do they report that to the IRS (most commonly in the form of W-2, or 1099).  There are a few examples but they tend to be things which act as deductions for the reportee (student loan interest, property taxes paid, etc).  For example if you buy a TV at best buy, there is nothing best buy reports to the IRS.

The reality is almost nobody is 100% compliant with the tax code either through wilful non-compliance (use tax is pretty common), errors due to the complexity, or ommissions the accuracy rate is essentially 0%.  That being said I am not advocating people assume they can always cheat and not get caught but lets use some common sense.  If you buy for a $20 domain name on namecheap with bitcoins and fail to record that as a capital gain there isn't much chance you are going to get "caught" (caught implies IRS would even be looking for that and they won't).  By the letter of the tax law you should report it but if you don't it is very likely nothing will happen and if somehow you did get caught you could always argue good faith effort and simply pay the taxes due.  Now on the other hand if you buy a bunch of Bitcoins at $0.01 each and now they are worth $40M and you plan to buy a yacht to "avoid taxes" well you probably should consult a CPA and there is a very high chance you will get caught and when you do you will be hit with fines and penalties.

I think the property classification is dubious, currency isn't property for tax purposes, neither are bearer instruments, stored value (gift cards), or even casino chips. On the other hand the idea that the IRS is going to demand records on all transactions (even ones where there is no legal requirement to keep records) in order to catch all the $1.38 in missing taxes on capital gains from spending bitcoins for a video game is kinda silly.

Only for long term capital gains.  Short term capital gains (asset held 364 or less days) is taxed at your regular income rate.