A "cent" doesn't require moving the decimal point of the currency, it's what we already use: 1.00 = bitcoin 0.01 = bitcent A "centibitcoin" (and that would be technically correct) would be too close in value to the existing currency, making mistaking one for another too easy. SI units are commonly used as primary designators, and two uses can perceived as different words: microfarads = capacitance centimeters = length kilometers = length However, there are no examples of SI units with currency though, because there have been few times in currency history where small units have bought so much. US Dollar in 1850-1900 is equivalent to Bitcoin now. If we divided bitcoins into eighths: "Shave and a haircut, two bits!" = $0.25 in 1900 "Shave and a haircut, two bits!" = BTC0.25 in 2013 ($11) "Bits", or pieces of eight, is a term that comes from a time in colonial America when a silver coin was too much money to be used. Fortunately we don't have to cut up a bitcoin to spend it.  For large amounts, language already has it's own "SI" units, million, billion, trillion. "The US budget deficit is $845 gigadollars" is not said. I think we have another three decimal places of valuation to go before BTC becomes burdensome, making it difficult to visually discern decimal places on a number like .000051 bitcoins. After that, microbitcoin would be the logical unit to use, as a unit that is one million times smaller is a big enough divide that both currency designations won't be commonly used at the same time, and an error in the amount will be easily noticed - "oops, I accidentally sent you 10,000 BTC instead of 10,000μBTC" just isn't going to happen. A satoshi is a microbitcoin cent. "Who wants to be a microbitcoin millionaire?" = 1 BTC |
|
|
|
|
Copy the entire bitcoin data directory except the wallet. You may also have to remove log files in the database directory, they often are associated with the wallet file or are platform-specific.
|
|
|
|
|
The problem you would have would be that in most wallets, you do not have control over which funding source is used.
Example:
1. Receive 1 BTC at your donation address that everyone knows, and
2. Receive 1 BTC to another address you want to keep private.
then
1. Send 1 BTC to buy nuclear detonators.
You can't guess which of the payments will be used fund a new transaction. If you want to send 1.5 BTC, then obviously both will be combined to fund the new transaction. You have even less chance that payments from different sources won't be combined if your wallet contains many different payments from different addresses. Other past or future transactions may also connect the two addresses to one owner.
If you wish to maintain anonymity and plausible deniability, it is best to use two different wallets to avoid any association between addresses.
Only the address that receives the Bitcoins can send them, they can't magically move from one address to another.
|
|
|
|
Nothing that you have stated is anywhere remotely useful or informative.
First of all this is not a "BIP", since the decision on whether or not to include free tx has nothing to do with the Bitcoin protocol. Per BIP 0001: A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. This change eventually invalidates some transactions that the reference client currently creates. optional inclusion of no-fee transactions by miners should be eventually removed. Second, miners will eventually drop free transactions all on their own, without the blessing of your wise and thoughtful post, because doing so is in their economic best interests. This will happen all on its own as the transaction volume increases. It is also in their best economic interest to drop transactions that the reference client creates by default. This BIP first fixes the transactions that Bitcoin is creating. |
|
|
|
Catching attention with such a title is NOT nice at all and however good your idea might be that you actually want to present, people will immediately look down on it because nobody likes to be fooled.
Okay, you get a non-fooly subject. Please state exactly how many satoshis is the minimum fee per kB for the centuries to come and why.
I purposefully don't address what the minimum fee amount is, only that the current method for calculating it is appropriate for all transactions, and that optional inclusion of no-fee transactions by miners should be eventually removed. As always, the amount may be changed in the future if deemed necessary, independent of it's enforcement. |
|
|
|
|
You can view my "how bitcoin works" link in my signature.
It's intended for noobs, so it won't answer your questions in extreme depth. Others have said it's too much reading for a noob, but I'm sure you are literate...
|
|
|
|
|
The reduction of Satoshi's 0.01 minimum fee to 0.0005 was an error. A divine design was altered by whims and perceived exponential growth of Bitcoin value, without considering future impact on the network. Whims like those seen all over this forum in the past few weeks.
The transaction volume currently being experienced, which pays an average of 0.5 bitcoin per block, would instead be paying 10 bitcoin per block, on track to replace the mining reward on schedule. Bitcoin would be used for transferring currency between individuals in exchange for goods and services, instead of for frivolous applications.
Instead we have this thread.
The solution is to pay more for your transactions instead of demanding more for less. The current block size and new higher fee prioritization code allows us to crowd out the spammy with only nominal fees, even though it is still not necessary to include more than the default fee for next-block service. Economics will regulate the applications of Bitcoin to those uses that are worth paying a reasonable fee for reasonably fast processing. Unfortunately version 0.3.23 broke proper economics.
|
|
|
|
The simple philosophy "read before write" applies here.
The priority on transactions must exist, especially with respect to aged coins, or else an attacker can flood the peer to peer network with free transactions that move one satoshi back and forth between two addresses.
There will be no more free transactions. See subject. I would address one more issue if I find it fits the motivation of the BIP, set a max size of the "generate" transaction to avoid miner-flooding (paying the generate transaction out to 1MB of addresses). This only moves the transactions a miner-flooder would create to the main part of the block though. Typed but not included: Unfixable in Bitcoin: It would be possible for a mining entity/pool to directly accept free or lower fee transactions under contract. In the miner's block, the miner can include directly-submitted transactions that are not published to other nodes, that appear to pay a minimum fee, but as the miner can "print" fees for free, they can refund the fees to the transaction submitter/gambling site/exchange, thereby offering a cheap occasional spam service. |
|
|
|
|
Actually I was lying in the alarmist subject (changed), but now you are reading. It's not developers, just me. I consider a standardization on one true fee as beneficial for Bitcoin. The proposal's incompatible "forking" modification, enforcing mandatory transaction fees in miner's blocks, would only take effect after a very long sunset period or after near unanimous miner voting consensus.
I think it's a good idea, you should too.
BIP draft proposal (actually half-a-BIP, I got tired of writing):
Abstract
This standards-track Bitcoin Improvement Proposal declares that Bitcoin and Bitcoin compatible network clients shall now consider all transactions to require the minimum per-kB fee when creating transactions. A future client version shall begin enforcement of this rule in all transaction and mining activity, with a final block number declared after which non-minimum-fee transactions will be considered invalid, including the invalidation of blocks created including them.
Motivation
The computation resources used by transmission, verification, and storage of Bitcoin transactions have no relation to the wealth or patience of the sender. However, Bitcoin currently determines whether fees are required with these exact criteria. Bitcoin has a special high-priority class where transaction fees are not required if the transaction value is large enough or the age of the input is sufficient. Bitcoin clients create transactions without fees if the transaction fits this high-priority criteria. This BIP removes all priority calculations and considerations.
There is only a limited area for these fee-free transactions in a block - 27kB of 250kB. This may create scenarios whereby, depending on network utilization, free transactions may be processed faster than fee-paying ones, or fee-free transactions languish waiting for free space. The implication of such automatic no-fee transactions is not presented to users when creating transactions. This BIP removes the free transaction window from mining.
Except for this free transaction class, other transactions currently require a minimum fee. However, these fees are not strictly enforced by miners, resulting in the creation of transactions by various clients, or organizations on behalf of their customers, with less than the required fee, that will languish or not be processed at all. These are created in the hopes that a miner that doesn't observe rules will eventually include these transactions. This BIP demands minimum fees be paid on all transactions, with its eventual invalidation of all non-compliant transactions.
Rationale
Bitcoin has inconsistent rules that create inconsistent handling of transactions. It makes some transactions free, and doing strange things such as adding another 10 BTC input to a transaction might make an otherwise 0.5 bitcoin fee transaction qualify to be free.
Bitcoin lets high value transactions have free priority. This is counter-intuitive, common sense would set the value of a money transfer at the amount of currency contained in the transfer. Analysis of the Bitcoin protocol would tell you that data size and computation cost should be paid for by transaction fees. Bitcoin does not use the former, it inconsistently uses the latter.
There is no such thing as a "low priority" transaction in Bitcoin, there are only transactions that don't follow minimum fee rules. The reference Bitcoin client won't send these transactions, but others will, often without the knowledge of users of a wallet or banking service. This creates poor performance with no explanation when these transactions aren't processed in a timely fashion.
As maximizing profits is the goal of almost all independent miners, it is reasonable for fee-seeking miners to ignore fee-free (but rule observing) high-priority transactions, creating a poor experience for users of standard clients that create them.
Bitcoin in newer versions (and miners using it) now gives preferential treatment to transactions that include more than the minimum fee - this factor alone is sufficient to prioritize transaction inclusion.
|
|
|
|
As long as we are posting charts, this one's live:  |
|
|
|
|
I'm mining using an ASIC. Code name Juniper. It is an Application Specific Integrated Circuit manufactured at TMSC Taiwan using their 40nm process, and includes 1 GB of memory on it's custom-designed circuit board too.
|
|
|
|
|
Add an additional .001 optional fee in your client and your transaction will be in the next block. The blockchain flooders are cheapskates. Transactions are not supposed to be cheap enough that you can blast hundreds of them out an hour with your gambling bot.
|
|
|
|
This undead thread is fundamentally flawed in any and all assumptions that are being made as a basis of argument. 1: Adding transactions to the block you're working on will slow down your generation rate. What prevents the majority of generating nodes from ignoring broadcasted transactions and making the network unreliable?
Theymos made an incorrect assumption, hash rate is in no way affected by the inclusion or non-inclusion of transactions, there is no advantage to not including transactions. There may have been a very small bit of CPU used in the CPU solo mining days when creating a new merkle tree when a new transaction was received, but these days where multiple pools have over 4TH, the number of included transactions in no way impacts the hashing that miners are doing - they don't even know how many transactions are in the block data that is being hashed. Secondly, even if 50% of the blocks included no transactions, Bitcoin would keep on working. There was already a "mystery miner" that was using a botnet that didn't include transactions, and his 10% of the hashrate was merely a curiosity. If a bad actor has more than 50% of the hashrate required to deny transaction inclusion on more than half the blocks mined, there is a much bigger problem, as they already have enough hashrate to do a 51% attack and can cause more problems by rewriting block history, double spending and erasing blocks. Bitcoin relies on a majority of mining being good, there is little defense against a majority hashrate attack. Finally there is no motivation for this. If a pool operator was doing something against the interests of Bitcoin, it would be known and miners would leave. Not including transactions would be passing up considerable earnings. |
|
|
|
I think there need to be some grammar fixes:
* Bitcoin has its own unit
* it is valued independently on the merits of its usefulness and scarcity.
http://garyes.stormloader.com/its.htmlPossessive = no apostrophe. it's = only used as a contraction of "it is". edit, I just found two more "it's" in the page, thanks. I didn't run a spell checker either, so I just caught the word "aboout" too...  |
|
|
|
Making things suck for the benefit of noobs is why we have Windows 8. Read this board and see how many questions could be answered in a five minute read. I answer the question "how it works" though, which may not be the first link a curious reader needs. If you want to make it more accessible, read the above while picturing it as a script for a weusecoins-style video with corresponding graphics. "Some Bitcoin words you might ear" also has some terms that use "new user" as an excuse for inaccuracy. |
|
|
|
Here's my new "how it works" to give time for everybody's useless comments before I check in the source. http://we.lovebitco.in/how_it_works.htmlI created the content with a few goals: - Efficient use of language,
- 100% accurate, no misleading analogies,
- Starting simple, read as long as you want before you feel you can trust Bitcoin,
- Technical info in sidebars, in the style of "For Dummies" books.
I also noted a bug in the site template - the buttons have images with alt-text that duplicates what the buttons say, creating a mess when images don't load or are disabled. The alt should be simply "icon" or something that reflects the picture. |
|
|
|
I agree, it is a B.S. error. It really should say "insufficient funds to cover the cost of the transaction and all associated fees". if (nValue + nFeeRequired > GetBalance())
strError = strprintf(_("Error: This transaction requires a transaction fee of at least %s because of its amount, complexity, or use of recently received funds!"), FormatMoney(nFeeRequired).c_str());
[b]else[/b]
strError = _("Error: Transaction creation failed!");
It gets to "transaction creation failed" only if the balance equal to or more than value + fee. The transaction has failed for some other reason. |
|
|
|
Sorry if this has already been covered, but I can't seem to get the transaction fee setting to "stick" after I close the client. It only works for as long as the client stays running, and if I shut it down and restart it again the transaction fee to send goes back to .00000000 BTC. Any ideas on this one?
Probably paytxfee=0.00 in the bitcoin.conf file. |
|
|
|
|
Show Posts
