Is coinlab a full bitcoin exchange? Or is it just a more convenient way to get USD into Mt. Gox?
Soon to be only way to get USD into and out of Mt. Gox.
|
|
|
Thus one has to try to either tame them or define a scheme by which the blockchain can be cleared from them once in a while. Miners have complete control over which transactions they include in a block. They don't need to use the default rules, nor do they need to change the protocol. A couple lines of code could create the necessary incentive to clean up all of these "unspendable" dust outputs. https://bitcointalk.org/index.php?topic=150726.0
|
|
|
I see, thus avoiding sending a "watching-only" wallet from offline to online computer? Exactly.
|
|
|
So, I guess it would not be a good idea to open an account over at CoinLab It's a great idea, just remember the first rule of Bitcoins - you don't actually own them unless you control the private keys. Use CoinLab as a convenient way to move dollars into the exchange and buy bitcoins with them. Then withdraw your bitcoins to a wallet you control. Don't hold funds in the edge exchanges - use them as an escape route.
|
|
|
It seems like it should be possible to set up online/offline Armory instances, generate the public and private keys with a separate utility, and import the private key into the offline instance and the public key into the online instance.
|
|
|
Not just care, but care enough to forgo some income for it when they take a txn consuming more utxo paying lower fees per byte over one consuming less utxo paying more.
They don't necessarily need to forgo income. At high enough transaction rates there must be some economic value in keeping the UTXO set small enough to fit in RAM. Presumably miners are smart enough to analyze their capital equipment costs and determine the correct magnitude of the incentive.
|
|
|
how do you arrive at 3?
Blockchain.info is down again so I couldn't get exact numbers but I know the current transaction rate is less than 10 tps. 10->2000 is three orders of magnitude. If we are less than 2 on average now it should be 4 orders of magnitude.
|
|
|
Just found this thread because I was wondering what will happen in the future if (when) the user base is many times greater. Will we reach a point where it's no longer feasible for the average user to run a complete node? Before that happens fully functional nodes will no longer need to store the entire blockchain all the way back to the Genesis block, and blocks will become a list of transactions instead of including copies of the transactions themselves, to cut the average bandwidth needed to participate in the network by half and reduce the burst bandwidth requirement to almost match the average bandwidth. The average user might not be able to participate with a 10 year old laptop and dial up modem, but with reasonably modern equipment and connectivity they can still be part of the network.
|
|
|
So lets say $20 per day per node, compare that to the number of dollars available to be mined each day and you have the number of nodes the network can support I guess, yes? If we're talking about a Bitcoin economy that is generating 2000 transactions per second there's a bit more to it than just the block reward. Don't forget to scale the existing fee revenue by three orders of magnitude. Then make sure to add in the nodes operated by Bitcoin-dependent businesses that absorb that cost into their overhead.
|
|
|
Permanent storage isn't the (significant) scarce resource that requires block space to be rationed, bandwidth is. Downloading an amount of transactions equal to Visa, based on today's bandwidth costs, would be less than $20/day.
|
|
|
By default Bitcoin will not created blocks larger than 250kb even though it could do so without a hard fork. We have now reached this limit. Transactions are stacking up in the memory pool and not getting cleared fast enough.
|
|
|
Your reasoning would make sense to me if UTXO set size was the only scarce resource being rationed, but block space needs to be rationed at the same time. True at the moment, but in the long term block space does not need to be rationed. It's not even strictly necessary for anyone to keep every transaction all the way back to the Genesis block. The only data that absolutely must persist forever for the network to function is the UTXO set.
|
|
|
SD is not "the tip of the iceberg". Let's imagine a bitcoin-operated coffee shop and compare it to Satoshidice. Assume you have 1000 customers at your coffee shop every day, everybody makes one purchase. 1000 transactions spread over a day is not much. One coffee shop is still part of the tip of the iceberg. Bitcoin eventually needs to be able to handle multiple coffee chains, each with tens of thousands of stores, all serving 1000 customers per day.
|
|
|
i've always been a bit wary of djb crypto, despite the guy being a pretty big producer idea-wise. his algos are not nearly as well-studied as the standard ones and he has a tendency to assign "frankenlicenses" on his code. Everything he does is non-standard. He invented his own FHS and init implementation, just because. Integrating his software with any system vaguely unix-like is an enormous pain in the ass that people only ever tolerated because the alternatives to his software (Bind) sucked that much at the time.
|
|
|
World domination by 2020
|
|
|
Does anyone still make dot matrix printers?
|
|
|
Do you have a solution to force miners to care about Bitcoin in the long-term? I'm all for better solutions, but so far I've not heard any. You could make it economical to clean up the mess, which is a better long term solution because it doesn't rely a constant arms race to filter out bad behaviour. https://bitcointalk.org/index.php?topic=150726.0At least one client developer is willing to automatically clean up those unprunable dust transactions if the right incentives are in place.
|
|
|
Yes! We have plans also to integrate PGP into the site for ALL communications. More Bitcoin sites need to give users the options of uploading a public key to encrypt email messages with.
|
|
|
It could happen... It could also go to zero.
|
|
|
|