You don't.  You just pay in Bitcoins.  The merchant registers with Bitpay to handle/track payments.

Very good summary.  That said the protocol should be better documented.  The client specific features should also be better documented and indicated as such.  I am not blaming anyone but the fact that the code is the spec doesn't mean that the spec "as we understand it" can't be written down outside of the code.  If nothing else it will help to highlight areas of concern "tricky issues", and areas where the spec didn't match execution in the past. 

As time goes on the spec would encapsulate a lot of trial and error, issues, etc.  For people like kokjo they still won't be happy because the spec will need to be updated over time to better reflect the actual expectation of nodes in the wild (which is the "real" protocol).  It won't be possible to say "nope the spec says X so we do X going forward even if it means a catastrophic hard fork because all existing nodes don't do X they do X'".  Still having it all in black and white makes it easier for new developers to get up to speed. 

Plus putting something in black and white allows knowledgable people to spot omissions or inaccuracies.  The spec can include both required behavior and best hehavior going forward (i.e. non-standard signatures are accepted however all nodes should implement checks to ensure that only canonical signatures along with some test examples).

The issue wasn't so much 32bit process running out of memory.  I can't seem to figure out why it was loading as a 32 bit process.  Architecture was "AnyCPU".

The System.Data.SQLite assembly is "AnyCPU" (PE=PE32 & 32BITREQ=0) with no native code (ILONLY=1).


For some reason System.Data.SQLite is referencing the x86 not the x64 version of SQLite.Interop.dll forcing the entire assembly to run as a 32 bit process.  Forcing x64 as architecture results in a "BadImageFormatException" exception on System.Data.SQLite so once again for some unknown reason it is loading the assembly as 32 bit.  I am not sure why as the point of the split System.Data.SQLite.dll (managed AnyCPU wrapped) and SQLite.Interop.dll (native dll in both x86 and x64 versions) is to allow both x86 and x64 projects from the same reference right?

Anyways I bypassed the issue by just using the mixed mode x64 assembly.
http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki

Still not sure exactly why it didn't work.

Agreed.  For my purposes x86 compatibility is a non-issue and as time goes on the data will only get larger.  32 bit general purpose clients make sense where the client is really only interested in the UXTO but for a general purpose parser to build blockchain related tools I see little value in trying to make x86 work.


Well a nice start so far. On my system it synced the blockchain from the genesis block significantly faster than bitcoind did.  

Awesome I will sell mine for $500K each and use the procedes to fund Bitcoin 2.0 and the other half to retire.

This link shows it better (link to tx vs the address).
https://blockchain.info/tx/f045f489dd97e8a66e4551d67b117678a558a068ce886cba1aa47b6f7eee84f0

That wasn't a fee.  It was change.  Bitcoin can't spend part of output so it needs to make change
The person making the tx had outputs worth:  0.11097293 BTC and wanted to spend 0.1 BTC.
For some asinine reason they decided they wanted to include a single satoshi (0.0000001 BTC) as a fee (not exactly sure why).
Inputs must equal outputs + fee.

However the user didn't want to spend 0.11097292 BTC they wanted to spend 0.1 BTC so the client made a tx like this

IN0: 0.02465968 BTC
IN1: 0.08631325 BTC
OUT0: 0.1 BTC   <---- amount user wanted to spend
OUT1: 0.01097292 <---- the "change" sent to another address controlled by the user.

FEE: 0.00000001 BTC

You will notice the sum of the inputs minus the sum of the outputs is 0.00000001 BTC which is the fee paid to the miner.

Think of it like you want to buy a candy bar for $1 but you only have a single $20 bill.  How large will the tx be.  Well it can't be $1 because you don't have $1.  The tx will be $20. So you send $20 to the cashier and she sends back $19 in change and puts $1 into the store's account.

In Bitcoin terms it would be like this:
IN0: $20.00    <- your single $20 bill
OUT0: $1.00   <- your payment to merchant
OUT1: $10.00  <- your change in the form of $10 bill, $5 bill and 4x $1 bills
OUT2: $5.00
OUT3: $1.00
OUT4: $1.00
OUT5: $1.00
OUT6: $1.00
FEE: $0.00

You will notice the merchant had to give you a large number of discrete outputs (smaller bills).  This is because in fiat currencies the currency can only exist is predefined forms ($1, $5, $20, $100, etc).  Bitcoin however can create a new output of any value thus in the Candy bar analogy it would be like "You hand cashier a $20 bill, she securely destroys it and prints a new $1 bill and $19 bill, she puts the $1 in the teller and hands the $19 bill back to you".

Thanks for that I probably will go as well.  How did you find out about the discount code?

I agree this is a cludgy hack compared to the power (elegance?) of type-2 deterministic wallets.  The day that the reference wallet supports deterministic wallets (and only deterministic wallets) can't come soon enough for a whole variety of reasons.  

However until that day I am asking if I missed anything from a security or usability point of view with this "workaround".  I don't believe I have and in testing both wallets function as expected just trying to get a second opinion.

A common question is how to setup a website or service to accept bitcoins without using any third party services and without leaving keys vulnerable to an attacker.  The most direct method is using a "watching wallet" (aka "read only" or "watch only wallet").  This wallet does exactly what it sounds like.  It can only "watch" owned addresses for incoming transactions.  It is unable to spend/transfer coins.  It does this by simply not having the private keys necessary to sign transactions.  There is a complimenting "spending wallet" which can be kept secure offline (or at least off the visible public webserver) which has the private keys and can sign transactions.  An attacker can't steal what isn't there.  Other clients have supported watching wallets but bitcoind does not, this guide however will illustrate a workaround which enables the use of bitcoind in a "watch-only" manner.  

Assumptions on my part:
1) Bitcoind requires an encrypted wallet to be unlocked to refil the keypool.
2) The wallet will perform this refill transparently (without notifying the user) anytime the wallet is unlocked for any reason.
3) If the wallet is never unlocked the keypool will eventually be exhausted.
4) If the wallet is exhausted and locked, a request for a new address (getnewaddress RPC call) will always fail and no address will be returned.

These assumptions have been verified and create a scenario where we can ensure the public keys on a wallet don't change.  We do this by expanding a keypool, locking the wallet, and not unlocking it.  The webserver simply "doesn't know" the passphrase necessary to unlock it's wallet and thus the keypool will consists of known keys until it runs out and needs to be replaced, this is the "watching wallet". By having another copy of the same wallet offline with a secure known passphrase we can spend coins we receive if/when necessary, this is the "spending wallet".


Random passphrase method for creating a "watching wallet" using bitcoind:  Obsolete now that pywallet supports creating watch-only clones.
1) On a secure non-public computer, create new wallet, expand keypool to desired size, encrypt with strong known passphrase
2) Make an offline backup of the wallet and passphrase = "spending wallet"
3) Change encryption passphrase to a random 256 bit string (64 hexadecimal digits) = "watching wallet"
4) For security purposes, discard and do not record the random passphrase anywhere.
5) Transfer "watching wallet" to wallet server.

At this point you have two identical copies of the same wallet (including the same sequence of private keys in the keypool).  The "watching wallet" has an unknown and unbreakable random passphrase so loss of the server wallet will not compromise the private keys.

Pywallet clone method for creating a "watching wallet" for use with bitcoind
At this time the ability to clone a watching copy is only available in the beta version of Pywallet (v2.1.0b2 or later).
Pywallet will work with the encrypted copy of your wallet file, does not have access to your private keys and does not require your passphrase.
BETA DISCLAIMER: Beta software should only be used for development and not for production.

Pywallet 2.1.0b2

1) Secure the "spending wallet".
You will need a copy of the wallet which can be used to spend coins as the watching wallet lacks to the private keys necessary.  We will start by ensuring we have a good "spending wallet".  I recommend starting with a new wallet (launch bitcoin with no wallet.dat and it will create a new one).  You should encrypt the wallet by setting a passphrase.  Before you go any further verify the passphrase is set correctly by unlocking the wallet. This is also a good time to securely record the offline passphrase in a paper backup.  Strong cryptography is a great tool but lose/forget your passphrase and you will realize the nightmare of how strong it really is.  The wallet you have now is the "spending wallet".  It should be stored securely offline or on a secure (non-public) computer.   The spending wallet should never be on the same server as the watching wallet as that defeats the purpose.

2) Expand the keypool (if necessary)
Since new keys are added to the keypool randomly, the watching wallet will remain perpetually locked so no new keys are added.  This is important because new keys are random so if the watching wallet expands it will not match the "spending wallet".   By keeping the watching wallet static we can ensure there is no loss of keys.  The downside is that eventually the watching wallet keypool will be exhausted (0 available new keys) and you will then need to repeat this process. The default keypool in bitcoind is relatively small at 100 future keys so for most applications you will want to expand the keypool to something larger.

To expand the keypool bitcoin (GUI client) or bitcoind (daemon) needs to be started with the --keypool argument.  This can only be done at launch there is no RPC call available. 


XXXX is the desired number of private keys in the keypool (i.e. keypool=1000 will enlarge the keypool to 1,000 keys).  The value provided is the new keypool size not how large to expand it.  On a new wallet using keypool=1000 will add 900 more keys for a total of 1,000 not 1,000 new keys for a total of 1,100.    The command only informs the client it should expand the keypool when it has access.  The client can't expand an encrypted wallet if it is locked.  You can force the wallet to unlock temporarily with the walletpassphrase RPC command.


For large keypools it can take a few minutes to create and store the keys depend on your system performance and the program will provide no indication of progress.  Just wait.  

Performance Note:  Wallets with a large number of keys (more than 5K to 10K depending on system) can be sluggish in responding to RPC commands.  It will also require more resources to scan the blockchain for incoming transactions.  Try to balance the size of keypool with your expected number of keys and the computing power available.  If your site needs <10 new keys per day and is running on a low powered VPS making a wallet with a 20,000 key keypool is likely not going to produce good results but on the other hand if you need an average of 200 keys per day and have a dedicated server making a keypool of 250 is going to need nonstop refreshing.

3) Verify the keypool is set correctly.
To verify the size of the keypool, use the getinfo RPC call.

This wallet has 301 keys in the keypool.

4) Make a backup
Make a backup of your current wallet.dat.  This is a backup of your "spending wallet".  I recommend you name the backup something descriptive to avoid confusion with the watching wallet copy (i.e. "wallet.spending.dat".  At this point the spending wallet should have an expanded keypool and be encrypted with a strong passphrase.   

If you lose a copy of your spending wallet you will be unable to spend your coins.
If the passphrase for your spending wallet you will be unable to spend your coins.
The watching wallet copy we will make next is incapable of spending the coins to ensure you have a backup or your wallet and passphrase.

The whole point of the watching wallet is for it to be unspendable, you should understand that undspenable means unspendable.  There is no hack or trick or backdoor which will restore access to your coins.  The watching wallet copy should not be considered a backup.

Paper backup of private keys (optional)
For additional security you can export and print your private keys using a dump from pywallet, to store in a safe offsite location (fireproof safe).

The dumpwallet command will dump the entire wallet (tx history, keypool order, labels, etc).  For brevity you can print just the "keys" section (it includes the keys in the keypool).  You don't need the "pool" section as it just contains the order of the keypool.  If you include a passphrase the keys will be decrypted.  If you do not include a passphrase the keys will be left in encrypted form.  I use the encrypted option to print a disaster recovery (a backup for the backup) copy of all the company private keys which is stored off site in a fire rated safe.  Yeah I am a little paranoid about backups but haven't lost a Satoshi yet.

5) Clone the backup of the "spending wallet" to produce a "watching wallet" using pywallet
You will need pywallet (and python and necessary dependencies) installed.  Installation is beyond the scope of this guide:
https://bitcointalk.org/index.php?topic=34028.0

Only the beta version of pywallet (2.1.0b2 or higher) has support for watch only clones.
http://pastebin.com/raw.php?i=2FtQDj3v]Pywallet 2.1.0b2

We will use pywallet to create a "watch only" clone of the existing encrypted wallet.  For ensure the watching wallet can't be used for spending the existing keys will be overwritten with random placeholders.  Pywallet can't simply delete the private keys as bitcoind is unable to handle a wallet with no value for a private key so it uses a random value as a placeholder.  The watching wallet should remain perpetually locked as if it is unlocked the keypool will refresh with new random keys not contained in the spending wallet.  Pywallet protects against accidental user unlocking by setting the passphrase on the watching wallet to an unknown random value.

So in summary:
A thief can't steal the private keys because they don't exist in the watching wallet.
A user can't accidentally unlock the wallet because they don't know the passphrase.


The command to create a watch copy of the wallet using pywallet is:

An extracted keypair dumped from a wallet prior to cloning.


The same keypair dumped from the cloned watch-only copy.

You may wish to store a backup of the watching wallet in the same location as the spending wallet.  There is no risk of losing funds if the watching wallet is lost/stolen/corrupted however having a backup avoids the need to reclone the spending wallet.  It is strongly recommended that you label the files appropriately (i.e. wallet.spending.dat & wallet.watching.dat).

6) Upload the watch-only copy to your public server.
Upload the watch-only copy of the wallet to your public webserver.  Make sure you upload the correct one.  If necessary rename the wallet to wallet.dat.  Restart bitcoind.  Once synced to current block, if the client still shows an incorrect balance, restart using the "--rescan" command line option.  

Wow nice article and one I couldn't imagine seeing a year ago.  I agree with just about everything in it including the idea that Bitcoin may crash and burn but the genie is out of the bottle.  The concept of cryptocurrencies controlled by math and logic rather than sycophants and central banks is far larger than just Bitcoin.


This sums it up.  Bitcoin (or more generally cryptocurrencies) are a next era of currency. Please don't this as "Bitcoin can't lose put all your money into it".  We have no idea how long it will take for this era to replace the last one, nor what form it will look like.  However barring some end of the world as we know it scenario it seems plausible that decentralized currency will eventually on a long enough timeline at least partially replace fiat currencies.

Human history has really only seen 4 eras of currency.
1) No currency era = bartered goods, generally one form of bartered goods because the "most bartered good" and acted as money
2) Commodity based currencies = issuance limited by bullion available to mint into coins (i.e. gold coins issued either privately or by sovereigns)
3) Commodity backed currencies = issuance limited to bullion reserves held by issuer (i.e. old US Notes)
4) Fiat currencies = issuance limited only the whims of the central bank  (i.e. Federal Reserve Note)
....
5) Cryptographic Currencies issuance limited to the consensus protocol (i.e. Bitcoin, et all)

No currencies are the most traded good.

Say I will sell you 1 ounce of gold for 20 Bitcoins.  Is that a good deal?  Lets pretend no USD/BTC exchange rate is available.  Well the only way to know would be to compare all the others goods and services you can get for 20 BTC and try to come to some rationalization of value.  Now here is the funny part.  Likely in your mind what you will do is something like this.

So I can get a 10 steam games for 1 BTC.  Steam games (discounted) tend to run $5 to $10 ea so lets say $7 so 10 steam games is $70.  Therefore 20 BTC is 200 steam games or $1400.  Yeah I guess that is a good deal.

The problem with that is that it is horribly inefficient.  With little price visibility commerce will still occur but it will be less frequent and smaller valued trades.  This creates a cycle effect.  Less historical trade data means less visibility which means less commerce which means less historical trade data which means less visibi.... sorry I got stuck in a loop.

Currency Exchange exists.  It is exists for a reason.  The reality is that for most fiat currency users it is hidden.  If you buy an xbox for EUR (produced by a US company which pays profits/salaries/expenses in USD and built in China with costs in CNY) it is IMPOSSIBLE for currency exchange rates to not affect the sale price of your unit.  Now you don't see it because Microsoft does some rounding to make the price nice and "neat" (like 299.99 EUR) but those factors are going on behind the scene all the time.  If the exchange rates deviate too much they will have to reprice (or more likely not have a price drop because the exchange rate fluctuation ate into the price drop margin).

Long story short there will never be a scenario where an entire economy is in BTC.  The entire US economy (used by 300M people and backed by the power of legal tender) isn't isolated from international exchange rates.

Oh and stop complaining about "too much speculation" (this is in general and not to the post I am responding to).  The speculative market is what creates liquidity. Sellers must sell, buyers must buy it is speculators who can do both and leave standing orders.  Case in point the US GDP is ~$15T annually.  Guess what the USD Forex trade volume is ....  ~$5T.  Sounds like a lot huh er wait that is PER DAY.  US "real economy" $15T annually, USD currency exchange $5T a day or $1.825 quadrillion dollars annually.

Now some people say what happens when fiats fail.  Well it is unlikely they will all fail at the same time.  80% of all fiat currencies have already failed.  The history of fiat currencies is a never ending fail train.  Say the USD fails, then the CNY may rise as a reserve currency, 30 years later China implodes and the EUR2 becomes the most traded currency, 30 years later the reformed United States issues a new gold backed currency which is considered a safe haven.   Still in the hypothetical scenario where no fiat currencies exist (an unlikely scenario and most likely will be after your grand children are dead) something else will be the metric for value.  Maybe it is gold. BTC:GLD ratio or electricity BTC:XEC. I made that symbol up BTW.


 

Your mistake was your coin was fundamentally flawed.  It was flawed due to YOUR ignorance.  Getting a better programmer doesn't just magic away that ignorance.

a) having flat coin generation for 7 years and dropping to zero is asinine.
b) believing that a variable block rate helps small miners is equally asinine.
c) thinking someone with 51% of hash power can change the rules shows a fundamental lack of understanding in an area where you are trying to "invent" something new.
d) accepting a statement that variable block rewards can't work with POS protected chain shows how shallow your knowledge is.

These aren't programming mistakes they are flaws in the high level thinking required for designing a crypto-currency.  The worst part is your inability to accept responsibility and instead blame everyone around you.  Please launch equal dubious failures, get them out of system quickly.

There is no exponential growth.  The rate of new scamCoin releases is significantly down.  The number of releases is also irrelivent, what matters is the number of actively developed and mined coins and that is a flat line at best.

6 months ago Bitcoin had ~95% of cryptocurrency marketshare and Litecoin had ~4% with the other 1% spread among a couple dozen dead or dying coins.  Today Bitcoin has ~95% and Litecoin has ~4% and the final 1% is spread among a couple dozen dead or dying coins.  The scamCoins are parasitic to one another.  They are exact copies which produce no value so one gets hyped one weak and crashes the next weak.  A coin goes offline only to be replaced with another one.

The vast majority of the coins will be gone in a year and will never rise to any significant usage. Only five coins have ever broke through $1 mil USD in valuation and honestly even $1M is a negligible amount.  None of those have been released in the last three months.  Of the five only NVC was released this year. 

You don't unless you are an admin or mod.

Probably not.  Not just from a hardware standpoint.  The concept of a decentralized networks is more established.  Although it is a crude analogy BitCoin is to money as Bittorrent is to data.

Um it is a CU.  There are no shareholders.  The CU is owned by members and CU strive to remain roughly break even over time as members both pay fees/interest and collect interest.  If the CU posts a profit it is returned to members on a % basis of total deposits.  However CU don't attempt to seek a profit as that would simply mean they are overcharging their members to begin with.

TL/DR All CU are owned by the members of the CU.

Got an out of memory exception at around ~ block 216,057.  I had all three caches set to 100 however the system has 16GB of memory, roughly 12GB free.  Looks like BitSharp.Client was using 958.6MB of memory at the time of the exception


Was able to restart and it resumed without issue.  Stranglely it is running as a 32bit process so that may have had something to do with it.  Need to check configuration settings as it should be building as Any CPU.

Correct.  It comes from the fact that today nodes running 0.8.2 or higher will (by default) reject tx which have outputs less than 5,430 S, that is 54.3% of the min mandatory fee (10,000 S).  If the entire network was running 0.8.2+ with default rules your tx would not have gone anywhere, if you were running latest version of client it would have prevented you from making this transaction.   As it stands right now some node are running older versions of the client and thus your tx "got through".  In time as the % of nodes running 0.8.2 (or equivalent for non-reference clients) increases the chance that a similar transaction will be able to find a compatible node to relay it will be greatly reduced.

Export the private keys involved into a different client and attempt to create a double spend.  The issue is that any node which saw the first tx will reject the second one.  Bitcoin makes it intentionally difficulty to double spend. 

If the first tx should have had a fee and doesn't then it may have been blocked/rejected by nodes on the network this increases the chance the replacement can be relayed to a miner and included in a block.  The chance is still low though.

Get over yourself. The concept of variable/lottery/super blocks was first introduced over 2 months ago in the (now dead) luckycoin.  "Your" protocol was nothing new, novel, and didn't achieve its stated goal of helping smaller miners.

You will notice the code in luckycoin is almost indentical to the code in "your" coin.  Well with the exception that it actually works.
https://github.com/LuckyCoinProject/Luckycoin/blob/master/src/main.cpp#L842

You aren't even #2 at least half a dozen coins launched before NUG included the concept of variable block rewards.

How can you not be capable of reading your own thread?

https://bitcointalk.org/index.php?topic=256460.msg2744015#msg2744015