Bitcoin still needs an efficient way for miners to communicate their prices (fees they'll accept) to clients. The client shouldn't really hard-code anything, ideally. But yeah, that's on the long to-do list of Bitcoin. Patches are welcome  . The hardcoded rules aren't intended for revenue. They are intended to protect the network from denial of service attacks. Miners are free to include or exclude any transaction for any reason. During peak activity paying the min fee may not be sufficient to get included in the next block. During period of low activity paying no fee (for high priority transaction) may be sufficient for inclusion in the next block. There does need to be a "fee discovery" system however the anti-spam rules are necessary to protect the network. |
|
|
|
It never dawn on me that the fees would rise due to the increase of the exchange rate. I'm pretty sure there's a simple solution--change the percentage rate in the code. There is no percentage rate in code. Nodes following the reference client rules: * require no fee on high priority transactions. * require a min fee of 0.0001 BTC to relay a low priority transaction to other nodes. * require a min fee of 0.0005 BTC to consider a low priority transaction for inclusion in the current block. |
|
|
|
|
First not all tx are required to pay a fee. The client enforced an "anti-spam" fee on low priority small value transaction which present a denial of service risk to the network. Without it a brain dead chimp could cripple the Bitcoin network by simply sending the same coins back and forth between addresses at no cost.
The mandatory fee on low priority transactions has been reduced in the past and likely will be reduced in the future if the exchange rate continues to rise. You can avoid the mandatory min fee today by ensuring your transaction meet the requirements for high priority.
|
|
|
|
|
Some people believe Bitcoin will not replace sovereign currencies for non-technical reasons. Governments are reluctant to give up their ability to control their own money supply. Governments have the trump card of demanding payment of taxes in legal tender which means there will always be some demand for sovereign currencies.
Still with Bitcoin current usage a tiny fraction of even say PayPal those worried about it not becoming the one currency to rule them all seems myopic. Lets look at Gold as an example. The value of all refined gold is >$10T with 95%+ of that simply being a store of wealth. If gold had low transaction costs (especially in digital space) it would make an awesome alternative currency. However gold does not and never will have the low transaction costs needed to compete with fiat currencies (whose true costs are subsidized by taxpayers). Say Bitcoin "fails" at replacing all sovereign currencies and only has a money supply worth that of gold. Oh noes, the worlds largest open payment network worth more than ten trillion USD? What an utter failure. Lets pull the plug. Actually given that limits the upside to only 20,000x todays valuation lets just give up now.
|
|
|
|
I think I'm starting to get it. Alice's work gets ignored if Bob solves his block first, regardless of who has the faster hash rate? I had thought both sets of transactions could be merged into the blockchain, but I guess Alice has to include the hash of the newest block if she wants to get a reward+fees.
Well it isn't so much "ignored" as worthless. How much are losing lottery tickets worth? Just about as much as Alice hashes which don't solve a block. I guess because the idea of mining for day, months, years without solving a block is depressing sometimes people have a tough time realizing there is no "progress" towards a block. You either solve it or you don't. If you attempt 1 trillion hashes and none of them solve a block you are no closer to solving a block then before you started. Still you are right there is no concept of "merging" transactions. Even if there was Alice would be better served still going for the highest fee tx (no matter how painfully slow she is). If Bob solves a block, Alice validates the block and removes all the included tx from the memory pool. Alice then reselects the "best" tx, builds the merkle tree, and starts hashing a new block. The amount of effort in constructing the blockheader is negligible compared to the trillions upon trillions of hashes (proof of work) it takes on average to solve the block. It doesn't save Alice any time or energy to NOT include the most profitable txs. |
|
|
|
It would be useful to include a "special exception" to the double spend rules. Nodes will drop double spends of outputs currently in their memory pool. A double spend which consists of the exact same inputs and same outputs and only differs in the amount of the fee to miner by a preset amount (say up to 5x min fee) could be allowed to "pass through" the double spend shield. This would allow users to "upgrade" a transaction from low/no fee to standard/higher fee and get it to miners. Mining pools could offer this as a service by setting up a node that allows for lots of direct connections and bypasses the normal relaying rules, and which immediately includes qualifying transactions in the next block. They could but for it to be useful it would need to be integrated into the client. If you need to hack the wallet.dat to force a change then you might as well just delete the offending transaction and wait for the network to forget about it. Also most mining pools limit incoming connections as a pool wants to get a block to other miners (namely other large pools) quickly. Having a bitcoind bogged down with hundreds of connections doesn't help orphan rates. In theory a miner's optimal peer configuration would be direct connections to all other mining pools and then a few connections to major tx hubs (exchanges, blockchain.info, major merchants, etc). |
|
|
|
|
No that is flawed thinking. As Gavin said there is no such thing as faster (or fastest) miners. Each hash has an equal (and very small) chance of solving a block. A miner with a faster hash rate gets more attempts to solve the block but there is no preset time before solving a block. Each attempt is independent and unique. A nonce has a random chance of solving a particular block (by producing a hash below the target) that is 1 in (difficulty * 2^32).
The best analogy is a lottery. Instead of buying lottery tickets miners generate lottery tickets by attempting a solution. Every hash is a potential winner. There is no "progress" towards solving a block. A miner takes a nonce, includes it in the blockheader, hashes it, and checks if the hash is a "winner". A hash below the block difficulty target wins, all other hashes are completely worthless (although pools collect some of these worthless hashes to determine each miner's share).
If Bob has 5x the hashing power of Alice then Bob simply gets 5x as many hash tickets per second to the block lottery. In the short run Bob could go a very long time solving no blocks and Alice could solve a block on the very first hash. Alice could even potentially solve two blocks in a row before Bob solves any. On average in the long run Bob will win 5/6ths of the blocks and Alice will win 1/6th of the blocks.
For the 1/6th of a time that Alice "wins" the block it makes absolutely no sense for her to include ANYTHING but the highest fee transactions. To do anything less would simply reduce her revenue. In the long run she will still only solve about 1/6th of the blocks but by taking lower fee tx over higher fee tx she would earn LESS THAN 1/6th of the global mining revenue.
|
|
|
|
|
It is possible to cancel a transaction although it is intentionally not user friendly.
The first thing to know is that all nodes will forget about transactions after a few hours. This is intentional otherwise someone could bring the network to its knees by spawning a huge number of low/no fee transactions when the blocks are close to max size. Memory Pool spam vs blockchain spam.
The problem is your client is very diligent. It continually looks to see if a transaction it sent has been including in a block. If it hasn't then periodically it will notify its peers and the transaction will propogate the network again. Any node which has forgotten about the tx will be informed of it again and the process will continuing infinitely.
To cancel a transaction you must delete it from your wallet.dat. This will prevent your client from keeping it alive. Eventually all nodes will drop it from their memory pool automatically.
It would be useful to include a "special exception" to the double spend rules. Nodes will drop double spends of outputs currently in their memory pool. A double spend which consists of the exact same inputs and same outputs and only differs in the amount of the fee to miner by a preset amount (say up to 5x min fee) could be allowed to "pass through" the double spend shield. This would allow users to "upgrade" a transaction from low/no fee to standard/higher fee and get it to miners.
|
|
|
|
Does having the public key even give you any information at all other than "nope, that's not the correct answer"?
Edit: also, to answer your question OP, never.
In classical computing knowing the public key removes the need to perform the address computation still given the amount of time/energy needed it is a negligible improvement (i.e. "only" need the energy output of 19 supernovas not 20 ). Having the public key is important in some quantum computing attacks so either Satoshi was really lucky (on a lot of things) or he is a time traveler from the future. Not re-using an address after you spend from it, means the public key is never publicly known. That provides a level of quantum resistance for cold storage addresses. |
|
|
|
Simple version: it can't be done. Not with a computer, not with a bunch of really fast "next gen" processors, not with a dyson sphere and a planetary sized super computer which operates at the thermodynamic limit until our star burns out. I think this sums it up the best. These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space. http://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html |
|
|
|
|
OP you logic doesn't make sense. The slowest miner is going to take the highest fees. If a miner solves the block they get the block reward (subsidy + all fees) if they don't then they don't. There is no scenario where it makes sense to NOT take the highest fees and go for the lowest fees. From the largest TH/s miners down to the single processor miners, if it is economical to mine it makes no sense to do anything other than take the highest fee tx first.
|
|
|
|
Why would fees becoming 10-50% effectively kill the system?
I guess you mixed up something there.
I meant 10-50% of the entire transaction amount, not of the block reward. Does it matter how many coins one transfers per transfer? Im imagining this like credit card fees, where they collect a percentage of the transaction amount. Yeah you do realize that the current cost of the network is about 1.6% of transaction value and that is dropping with time (as transaction volume rises). By true cost I mean including the subsidy (all fees + all block subsidies)/(value transfered). If the network could today operate with no subsidy and a 2% fee why would you think in a hundred years (without potentially thousands of times as much transaction volume) fees would be 10% to 50%? http://blockchain.info/charts/cost-per-transaction-percent?showDataPoints=false×pan=&show_header=true&daysAverageString=7&scale=0&address= |
|
|
|
Does anyone still make dot matrix printers?
They are still made for specialty purposes like printing checks and govt forms. However remember the spent ribbon on a dot matrix printer contains a reverse image of what is printed. Unless you intend to keep the printer and ribbon secure and destroy all spent ribbons it is a pretty easy method to exploit. |
|
|
|
please excuse my ignorance but why does this need a fork at all? "fork" sounds like all users will be forced to make a complicated decision with uncertain consequences, inconveniences, etc and actively migrating from A to B. At least thats what it sounds like. Couldn't it simply be done like that: # pseudo-code
def get_limit(block):
if block.timestamp > SOME_DATE_IN_2014_FAR_AWAY_SUDDENLY_IN_THE_MIDDLE_OF_THE_NIGHT:
return 2E6
else:
return 1E6
and then commit that change to the master branch of the reference implementation like every other upgrade or bug-fix or protocol extension too, document it in the official specifications and be done with it? That is a fork. People who upgrade will be on a different set of incompatible rules then those who don't upgrade. Not maybe everyone will decide to upgrade and the current bitcoin fork will die off but it doesn't change the fact that it is an incompatible fork. Worse say roughly half the community supports the "larger fork" and half support the "current fork". Both call themselves Bitcoin, each one is incompatible with the other. Now I am not saying this a death blow or any kind of FUD like that but people need to start realizing that Bitcoin is what a consensus of users say it is. Right now it is the protocol EXACTLY as implemented today. Any deviation from that is a fork and when you introduce a fork there are three possibilities: a) the fork is not well accepted and dies off <- waste of time b) the fork is overwhelming accepted and the original dies off <- best case but even here it is still a hard fork c) both forks are supported and both call themselves "Bitcoin" creates massive confusion and chaos <- what we want to avoid |
|
|
|
Though with that said, security really shouldn't depend on DNS if it's being done properly. I'd be interested to hear what the actual method of attack was just to see if it's one I've heard of.
Agreed though it wasn't BitInstant's security which was compromised it was VirWox. VirWox WTF are you thinking? It is 2013. Implement 2FA on your exchange or shut down. Period. |
|
|
|
|
I would point out that pruning doesn't have to be binary. It can be probalistic.
For example the active transaction set could exclude all spent outputs and all unspent outputs below a certain threshold, it could even exclude very old outputs. Essentially the active transaction set is acting like a cache and using probalistic functions to try and balance resource requirements vs cache hit rate.
If a transaction is created which uses an output not in the active set then the details could be fetched from the full unpruned database. If is even possible that some nodes wouldn't maintain this locally and simply query other nodes by sending the tx id and requesting details.
SD inefficiently uses a critical resource. Basically it comes down to you either believe in free markets or you don't. If you really believe in free markets then the market will solve the problem of inefficiency. More valuable transactions will crowd out SD ineffcient use of the resource. SD will adapt either by raising min and thus collecting same revenue using less of the critical resource, or by moving transactions off blockchain. If you don't believe in free markets then Bitcoin will fail eventually anyways. SD isn't a problem, Bitcoin is.
Personally I believe free markets are the most efficient allocator of resources (including space in a block) and thus SD isn't a "problem" long term.
|
|
|
|
|
I rarely publish sales metrics but I am really impressed with what our team accomplished during the crazy and volatile past 48 hours.
Tangible Cryptography Combined Transaction Volume 03/06 & 03/07
Total Transactions Completed: $321,304.40 (7,371.788 BTC)
Total Transactions Cancelled: $0.00 (0.000 BTC)*
I want to thank all our valued clients for putting us on a track to make March our highest volume month yet.
* No "high risk" reversals here.
|
|
|
|
|
Transactions ARE sent to every client, however until they are included in a block they are unconfirmed (0-confirms). The blockchain is a way to force a consensus which is mandatory for the system to work.
Imagine I have 1 BTC. I send the 1 BTC to John and I sent the 1 BTC to Jane. I send them at the same time. John's client believes it has received 1 BTC and Jane's believes it has received 1 BTC. Two people can't own the same coin. Did I just magically create a coin out of thin air (counterfeiting)?
Bitcoin only works if the entire world has a single consensus view of where the coins are. If there is a dispute only one version of a coins history will end up in a block. The blockchain forces a consensus so in the transaction above if John's coin ends up in the block then Jane's coin ceases to exist (she has been double spent). Harsh but Bitcoin can only work if there is a single global view of the current location of the coins. If Jane tries to spend that coin it will be rejected by the network as every client will see John is the correct owner of the coin.
|
|
|
|
|
It is volume weighted average and there was a lot of volume in that "flash crash". Until that is older than 24 hours it will dominate the weighted average.
|
|
|
|
Litecoin does make sense, but not really as a currency. It makes sense as a way to mine using your CPU/GPU and still make money. You don't really even have to look at it as a currency. Its a platform to trade CPU/GPU cycles for bitcoins.
So greater fool theory? http://en.wikipedia.org/wiki/Greater_fool_theory |
|
|
|
|
Show Posts
