|
Simple answer is no. This is why Bitcoin all crypto-currencies use the random output of a hash function to approximate a given amount of work.
You in theory could solve a block of any difficulty with a single attempted hash or not solve a block even given a magnitude more attempts than difficulty suggests however neither of this single rare events are of much consequence. To attack a network in any meaningful manner requires a large number of blocks and in the long run it will take "on average" 2^32 * Difficulty attempts to find a solution.
|
|
|
|
snip
This is why politics always confused me when I was younger. Why do they call themselves liberals, and then aim to use government force to take liberties away? That's not very liberal, unless you consider taking liberties liberally as liberal, which seems to be the only thing they're liberal about. Why don't we just call dogs "cats", pop open a cold beer and call it a day? The reality is they are actually statists but that term isn't a nice sounding. Left or right is linear thinking and too simplistic. At a minimum there are at least two axis social feedom and economic freedom. "Liberals" tend to be liberal on the social freedom axis but horribly regressive on the economic freedom axis. "Conservatives" tend to be more liberal on the economic freedom axis and but regressive on the social freedom aspect. Honestly they are both merely "flavors" of the same statist agenda. Socially liberal statist vs Socially conservative statist. Every politician in the US is in the upper right quadrant so any labels are merely how they relate to each other.  An interesting quiz for two dimensional political views (takes about 10 minutes): http://politicalcompass.org/test |
|
|
|
I addressed latency and orphans here: Yeah that isn't a solution. So the attacker simply DDOS the centralized point (or few points) of failure. Still you seem to gloss over the fact that validating a block takes a non zero time. Most of the delay isn't actual propogation delay it is validation delay. For example time zero your node is notified (either directly or through so easy to take down centralized MBR what has to happen before you validate the block and begin work on a new one. 1 ) You must receive the list of transactions in the block (this could be modified to a list of tx hashes to be more efficient) 1a) If protocol sends tx hashes you will need to query peers for missing txs. 2 ) You must validate that each tx is valid which means a) the inputs are unspent outputs (lookup/locate the referenced prior tx output in the UXTO) b) the tx is properly formed. no invalid structure, parsing issues. c) pub key for each input matches the pubkey hash of the prior unspent output (i.e. hash the pubkey and match to prior output pubkey hash) d) for each input compute the simplifed tx form, the simplified tx hash and validate the signature. e) verify that the sum of inputs exceeds the sum of the outputs. note the difference between sum of inputs and outputs. f) parse and verify the tx output script is valid. 3 ) compute the merkle tree and merkle root hash (which involves 2n-1 hashes)4 ) validate the coinbase value is correct (coinbase should be <= computed subsidy based on blockheight + sum of all tx fees in 2a) 5 ) validate the timestamp is within 2 hours of mean network time. 6 ) validate the prior blockhash in header refers to a known block 6a) if prior blockhash is unknown query peers for the block in question (and perform all the steps in this process on that block) 7 ) validate that difficulty & version is correct 8 ) compute blockhash and ensure it meets difficulty target Even given infinite bandwidth and all miners having all other miners as a peer, this process takes a non-zero amount of time. The most time sensitive elements are indicated in bold. The single largest by time is the validating of all input tx signatures due to the fact that it is 1 ECDSA sig validation (relatively slow process) per input in the block. Today with relatively low tx volume the time to validate a block is sub 1 second but as block sizes grow (think hundreds of MB and hundreds of thousands or millions of transactions) that time will rise. Now there are some optimizations possible but propogation delays will cause increased orphan rates in the future if network volume rises even to PayPal levels (50 to 100 tps). A smaller block interval is going to result in higher orphan rates and less security. Why do you think Satoshi decided on 10 minutes, why not 1 minute, or 1 seconds. It never occurred to him that smaller block intervals would be possible? Alt-coin "designers" simply modified the code thinking shorter = better but it is compromise. Now I am not saying Bitcoin is perfect but any block interval is a compromise between Latency and security. |
|
|
|
A faster first confirmation is an enormous benefit if we want alternative currencies to be used in brick and mortar stores and restaurants. You can't have each person in line waiting 10 minutes or more. You aren't going to have them wait 2.5 minutes (which may be up to 5x as long due to random nature block solutions) either. So either payments will be prepaid, will be off blockchain. or the merchant will accept the low but non zero risk of double spend fraud. When you consider the reduced security due to increased orphans and smaller overall network what exactly is the innovation. Now you may be right something "significantly" superior to Bitcoin may replace it but that significantly superior solution isn't LTC and the horde of copy cat pump and dump scamcoins don't even have enough momentum to break out of a paper bag. |
|
|
|
Yeah, I'm starting to no longer have fun doing this. The relationship between the inputs and outputs are about as clear as mud. Well, let me be clear, I get that each output needs an input, but hell if I know how to figure out which outputs refer to which inputs. Just a bit ago, I wanted to figure out how to convert the binary representation of a public-key to ASCII and even that it had a log of dependencies; even the 'no library dependency version' depended on some network thing called 'htonl' and on an encryption routine as well. That's a lot of code drug in just to convert some binary to ASCII. They don't. That might be why you are confused. The only relationship between inputs and outputs in a tx is is that the sum of the inputs must be equal to or greater than the sum of the outputs. The tx fee is the difference between the sum of the inputs and the sum of the outputs. So some rules to get you started. 1) The inputs of all txs (except coinbase = generation) are the output of prior transactions. 2) There is a 1:1 relationship between the INPUT of a given transaction and the output of a PRIOR transaction. 3) In a given transaction there is no relationship between the inputs and outputs. 4) For a tx to be valid the sum of the inputs must be equal to or greater than the sum of the outputs. 5) The difference between inputs and outputs is the tx fee. 6) Since a tx can have n inputs and m outputs we refer to a specific output by both the tx hash AND the index. but converting that raw date into paired input/output transactions seems to be a bit of a mystery to me so far. It will forever remain a mystery no matter how many libraries you use until you shake that flawed model. Lets look at a random transaction. http://blockexplorer.com/tx/a6d9c176ecb041c2184327b8375981127f3632758a7a8e61b041343efc3bcb6eIn raw form {
"hash":"a6d9c176ecb041c2184327b8375981127f3632758a7a8e61b041343efc3bcb6e",
"ver":1,
"vin_sz":1,
"vout_sz":2,
"lock_time":0,
"size":257,
"in":[
{
"prev_out":{
"hash":"b5045e7daad205d1a204b544414af74fe66b67052838851514146eae5423e325",
"n":0
},
"scriptSig":"304402200e3d4711092794574e9b2be11728cc7e44a63525613f75ebc71375f0a6dd080d02202ef 1123328b3ecddddb0bed77960adccac5bbe317dfb0ce149eeee76498c19b101 04a36b5d3b4caa05aec80752f2e2805e4401fbdbe21be1011dc60c358c5fc4d3bedd1e03161fb4b 3a021c3764da57fee0d73570f3570f1b3dd92a1b06aae968846"
}
],
"out":[
{
"value":"300.00000000",
"scriptPubKey":"OP_DUP OP_HASH160 0331e5256416bc11ecf9088091f8424819553a10 OP_EQUALVERIFY OP_CHECKSIG"
},
{
"value":"699.99950000",
"scriptPubKey":"OP_DUP OP_HASH160 4186719d739ae983d8c75a0cb82958e94b7ae81e OP_EQUALVERIFY OP_CHECKSIG"
}
]
}
Now the tx hash is a6d9c176ecb041c2184327b8375981127f3632758a7a8e61b041343efc3bcb6e The # of inputs is 1 (vin_sz). The # of outputs is 2 (vout_sz). The single input of the transaction is referenced here: "in":[
{
"prev_out":{
"hash":"b5045e7daad205d1a204b544414af74fe66b67052838851514146eae5423e325",
"n":0
},
"scriptSig":"304402200e3d4711092794574e9b2be11728cc7e44a63525613f75ebc71375f0a6dd080d02202ef 1123328b3ecddddb0bed77960adccac5bbe317dfb0ce149eeee76498c19b101 04a36b5d3b4caa05aec80752f2e2805e4401fbdbe21be1011dc60c358c5fc4d3bedd1e03161fb4b 3a021c3764da57fee0d73570f3570f1b3dd92a1b06aae968846"
} The INPUT for this transaction is the OUTPUT of a PREVIOUS transaction. Specifically it is the tx with hash b5045e7daad205d1a204b544414af74fe66b67052838851514146eae5423e325. However a tx can have multiple outputs so how do we know which one of those otuptuts this input refers to? Simple the tx output index is provided. Inputs of transactions are outputs of prior transactions.In this case the input we are looking for is is specifically the output #0 of transaction hash b5045e7daad205d1a204b544414af74fe66b67052838851514146eae5423e325 So lets look at that transaction. The output #0 of this transaction is 1,000 BTC. http://blockexplorer.com/tx/b5045e7daad205d1a204b544414af74fe66b67052838851514146eae5423e325So back to our current transaction (hash ending e325). There are only 1 input. The value of the transaction is the sum of the inputs. In this case a single input of 1,000 BTC. Now looking at the output section we can see we the two outputs "out":[ { "value":"300.00000000", "scriptPubKey":"OP_DUP OP_HASH160 0331e5256416bc11ecf9088091f8424819553a10 OP_EQUALVERIFY OP_CHECKSIG" }, { "value":"699.99950000", "scriptPubKey":"OP_DUP OP_HASH160 4186719d739ae983d8c75a0cb82958e94b7ae81e OP_EQUALVERIFY OP_CHECKSIG" } Output#0 is 300 BTC and output #1 is 699.9995 BTC. The sum of the outputs is 999.9995 BTC The sum of the inputs is 1,000.0000 BTC The tx fee to miners is the difference or 0.0005 BTC. If you want to decode further which addresses a transaction is sent to well you will need more code. Lets look at the second output. OP_DUP OP_HASH160 4186719d739ae983d8c75a0cb82958e94b7ae81e OP_EQUALVERIFY OP_CHECKSIG So what is 4186719d739ae983d8c75a0cb82958e94b7ae81e? It is the RIPEMD160 hash of the public key. However Bitcoin addresses include a checksum and are converted to Base58. BTW the public key hash 4186719d739ae983d8c75a0cb82958e94b7ae81e is Bitcoin address 16yTynjmSe5bsRGykDaaCL5bm2pxiEfcqP. |
|
|
|
Simply refuse to donate in anything other than crypto-currencies, everywhere. If they don't accept crypto, they don't need
money that urgently anyway.
This. I am a long time donator to both EFF and wikipedia. A while back EFF came out with some dubious reasons for not accepting Bitcoin. Worse those reasons were often used by other organizations for not accepting Bitcoins. I stopped my donations to the EFF. They called/emailed me a couple times in their annual fund raising drives and I simply reiterated I would donate once they accepted Bitcoins but not before. https://supporters.eff.org/donateEFF now accepts Bitcoins again. Vote with your wallets. No need to get angry, or outraged. Just calming indicate to wikipedia why you will not ever donate until they accept Bitcoin donations. When millions of people do that they will get with the program. |
|
|
|
|
Simple answer is yes, however like most problems it can be solved with technology.
Just some ideas (hardly exhaustive) to get your mind thinking:
Hardware wallets will make it possible to be significantly more secure even among foolish users. The main attack vector to any theft is access to the private key. If we assume that general purpose computers are simply too hard for average user to secure properly then logically the private key shouldn't ever (not even for a millisecond) be on the GP-PC. Instead we move the private keys to a dedicated hardware wallet with independent display and keypad. The DHW can rely on a GP-PC for connectivity to the network but all signing of transactions is internal to the device. Hackers can't steal what they don't have access to.
Another route would be multi-sig wallets. There would use two (or more) devices to partially sign transactions. It would take multiple signatures to authenticate a transaction. So you spend from your high value saving's wallet on your home computer and it is half signed by your home computer wallet. On a server somewhere a watching wallet sees the half signed transactions and sends the details to your smartphone. A notice appears on your smatphone showing the time, amount, IP address, Bitcoin receiving address, etc. If authorized you ok it and your smartphone provides the second required signature. For the sufficiently paranoid given a large enough market I could see development of dedicated hardware signing devices with independent WWAN connectivity.
Eventually you will likely see Multi-sig banks/eWallets. Imagine an entity that simply can't spend/steal your money without your permission. The added advantage is if a merchant trusts the bank/wallet to not double spend they can accept 0-confirm transactions. It is far easier for a merchant to trust a handful of well known entities then to trust thousands or millions of semi-anonymous customers.
|
|
|
|
Only thing I would like to see - lesser reward for block in next 4 months, so those asics don't get to print too much money daily. They should be awarded with ~25% over their electricity and maintenance costs, not more.
They will. Difficulty will keep rising until the ROI% over capital and electricity is low. The block subsidy will not change until block 420,000 when it drops to 12.5 BTC. |
|
|
|
WTF kind of post is this - wait till BTC get's to zero - then see just how pissed everyone is.
BTC will never go to zero. I promise to buy all of them for $1 per 1B 1T satoshis. |
|
|
|
I think assault rifles are only "scarier-looking" rifles that perform equally as well.
This. The fact that there is even a debate on a made up term like "assault weapons" means the statists who made the term up already won. It would be like banning certain car paint colors, spoilers, and tires in an attempt to reduce traffic fatalities. The "assault vehicle ban of 2013". Won't someone think of the children. Nobody needs to drive a military vehicle on public highways. etc. etc. |
|
|
|
Found a little more info here .... Used in 0.8.0: * wallet.dat: personal wallet (BDB) with keys and transactions * peers.dat: peer IP address database (custom format); since 0.7.0 * blocks/blk000??.dat: block data (custom, 128 MiB per file); since 0.8.0 * blocks/rev000??.dat; block undo data (custom); since 0.8.0 (format changed since pre-0.  * blocks/index/*; block index (LevelDB); since 0.8.0 * chainstate/*; block chain state database (LevelDB); since 0.8.0 ok "custom format". Well that helps.  |
|
|
|
|
Thanks. That makes sense and yes this is from a very old install so it fits.
Any idea on the format of peers.dat file?
|
|
|
|
|
All transactions can't go off chain unless there is a single monopolistic entity handling all Bitcoin transactions. Even if there were only two entities handling all the transactions they would need the blockchain to settle transactions between the entities.
|
|
|
|
Looking for detailed information on the data directory and file formats for QT client (0.8.3). There is this wiki page but it is pretty sparse: https://en.bitcoin.it/wiki/Data_directoryFor example what format is the peers.dat file in? The chainstate sub folder contains leveldb representation of the UXTO right? What is the significance of multiple xxxxxx.sst files? There is also LOCK, LOG, and MANIFEST-xxxxxx files? The "blocks" subfolder contains leveldb representation of raw blocks right? Why are the files of difference size? 08/05/2012 02:16 AM 2,097,361,271 blk00000.dat
12/16/2012 02:37 PM 2,097,361,271 blk00001.dat
12/16/2012 07:04 PM 2,097,299,522 blk00002.dat
02/22/2013 01:23 PM 1,879,601,111 blk00003.dat
02/27/2013 07:07 AM 134,217,728 blk00004.dat
03/04/2013 02:05 AM 134,217,728 blk00005.dat
03/08/2013 01:52 PM 134,217,728 blk00006.dat
03/13/2013 05:51 AM 134,217,728 blk00007.dat
03/18/2013 11:53 PM 134,217,728 blk00008.dat
03/24/2013 03:29 AM 134,217,728 blk00009.dat
03/29/2013 04:37 AM 134,217,728 blk00010.dat
04/02/2013 06:30 PM 134,217,728 blk00011.dat
04/07/2013 01:42 AM 134,217,728 blk00012.dat
04/11/2013 06:15 AM 134,217,728 blk00013.dat
04/16/2013 12:28 AM 134,217,728 blk00014.dat
04/21/2013 04:08 AM 134,217,728 blk00015.dat
04/25/2013 09:57 PM 134,217,728 blk00016.dat
05/01/2013 09:47 AM 134,217,728 blk00017.dat
05/06/2013 02:32 PM 134,217,728 blk00018.dat
05/11/2013 12:56 AM 134,217,728 blk00019.dat
05/15/2013 07:33 AM 134,217,728 blk00020.dat
05/20/2013 09:52 AM 134,217,728 blk00021.dat
05/25/2013 11:00 AM 134,217,728 blk00022.dat
05/30/2013 03:57 PM 134,217,728 blk00023.dat
06/04/2013 05:22 PM 134,217,728 blk00024.dat
06/12/2013 11:01 AM 134,217,728 blk00025.dat
06/16/2013 06:07 PM 134,035,313 blk00026.dat
07/02/2013 06:03 PM 134,216,638 blk00027.dat
07/02/2013 06:16 PM 134,108,901 blk00028.dat
07/03/2013 06:25 PM 83,886,080 blk00029.dat
02/22/2013 01:42 PM 264,241,152 rev00000.dat
02/22/2013 01:54 PM 242,221,056 rev00002.dat
02/22/2013 02:25 PM 236,978,176 rev00003.dat
02/27/2013 07:07 AM 17,825,792 rev00004.dat
03/04/2013 02:05 AM 16,777,216 rev00005.dat
03/08/2013 01:52 PM 17,825,792 rev00006.dat
03/13/2013 05:51 AM 16,777,216 rev00007.dat
03/18/2013 11:53 PM 16,777,216 rev00008.dat
03/24/2013 03:29 AM 16,777,216 rev00009.dat
03/29/2013 04:37 AM 16,777,216 rev00010.dat
04/02/2013 06:30 PM 17,825,792 rev00011.dat
04/07/2013 01:42 AM 16,777,216 rev00012.dat
04/11/2013 06:15 AM 16,777,216 rev00013.dat
04/16/2013 12:28 AM 16,777,216 rev00014.dat
04/21/2013 04:08 AM 16,777,216 rev00015.dat
04/25/2013 09:57 PM 16,777,216 rev00016.dat
05/01/2013 09:47 AM 16,777,216 rev00017.dat
05/06/2013 02:32 PM 16,777,216 rev00018.dat
05/11/2013 12:56 AM 16,777,216 rev00019.dat
05/15/2013 07:33 AM 16,777,216 rev00020.dat
05/20/2013 09:52 AM 16,777,216 rev00021.dat
05/25/2013 11:00 AM 16,777,216 rev00022.dat
05/30/2013 03:57 PM 17,825,792 rev00023.dat
06/04/2013 05:22 PM 17,825,792 rev00024.dat
06/12/2013 11:01 AM 17,825,792 rev00025.dat
06/16/2013 06:07 PM 17,127,799 rev00026.dat
07/02/2013 06:03 PM 17,186,353 rev00027.dat
07/02/2013 06:16 PM 17,151,788 rev00028.dat
07/03/2013 06:25 PM 9,437,184 rev00029.dat For example there are 30 blkxxxxxx files the first few are very large then most are 134MB. The last one is smaller but that would make sense as it is the block file in progress. Why 134MB? Why roughly 2GB for the first two block files and then the third one breaks that pattern? |
|
|
|
I think failure to deliver is illegal already covered under some business law, contract law I imagine Sadly failure to deliver is not illegal. Reg SHO prohibits dealers from shorting unless they have borrowed the asset in question this ensures that it is impossible to fail to deliver (if you borrow the asset first and then short it, when settlement comes it is impossible to not be able to make delivery). However Reg SHO provides plenty of exemptions, if you meet one of the exemptions then Reg SHO doesn't apply and you can naked short sell. If you can't deliver that is a contractual dispute but assuming your failure to deliver arises from being exempt from Reg SHO then you haven't broken the regs. Even if your failure to deliver is the result of breaking Reg SHO the failure to deliver is simply how you got caught the violation occurred when the short was made in violation of Reg SHO (you didn't have the asset in hand when shorting). If you break Reg SHO and borrow after the fact and thus are able to deliver you are still in violation it just likely means you won't get caught. Don't try to apply logic like I said it will just make your head hurt. The regs "could" simply require everyone at all times and for all reasons always have the asset in hand before selling. Period. The fact that the regs aren't written that way and the SEC sees a 50% reduction in failure to deliver as a "win" (which still means hundreds of billions in failures to deliver) just shows the law was written the way the powers that be wanted it written. |
|
|
|
I'm curious about a particular situation involving change values.
Say I have a wallet with 2 addresses.
Each address has received 1BTC, for a total of 2BTC in the wallet.
Say I then want to send 1.999999 to someone.
As I understand it (and correct me if I'm wrong here, looking to learn, not to pick fights), I would end up sending the full 2BTC, and then receive the change back.
Now, I know I'm not including the transaction fee in this scenario. This is really just a thought exercise with regard to the handling of tiny change values.
...
How is this handled?
Yes you must send full outputs. The amount "at" each address is irrelivent. Bitcoin works on a concept of outputs. Outputs are either spent or unpsent. Unpent outputs becomes inputs for new transactions and in the process are spent. So I will correct your example and say you have a wallet which has receive 2BTC and 1 BTC. You wish to pay someone 1.999999 BTC. The client will attempt to avoid spam at all cost. As such it will create a tx like this: In1: 1 BTC
In2: 2 BTC
Out1: 1.999999 <- your payment
Out2: 1.000001 <- your change
Fee: 0 BTC
The 1 BTC & 2BTC outputs are now spent (and thus will be pruned from UXTO). Your wallet would now have a single unspent output worth 1.000001 BTC. I am guessing you are wondering next what happens if you only had a single 2 BTC input. The tx would look like this: In1: 2 BTC
Out1: 1.999999 BTC
Fee: 0.000001 BTC
Since the creation of a 0.000001 BTC output would create dust the client will simply not create it. In any tx the difference between inputs and outputs is the fee. Note fees are not explicitly defined in ANY transaction they are just the difference between the tx inputs and outputs. |
|
|
|
Just to clarify a little, this is incorrect. While the original ratio will be 0.2 BTC per share, that will decay over time, and the trust will spend a portion of those Bitcoins. There is nothing sinister or odd about this -- it is, on the contrary, common and entirely expected by investors. Agreed and I misunderstood although (possibly my reading of) your wording seems to indicate a sinister intent. their 'company' will then be able to pay them wages/dividends and generally bleed down the value of BTC whilst only they benefit from it. it's a clever piece of latteral thinking, but not a good thing for a technology whose best outcome would be it stabalised into a currency The company is able to bill the trust for the small management fee (unstated but 0.5% annually is a common amount) and the NAV will decline over time but I wouldn't call it "only they benefit". If there is no benefit to shareholders (of the trust not the management company) then they won't buy it. I mean it is an open market. Investors will weigh the value/utility (if any) of the fund vs the cost (in terms of annual management fee). They buy because the value outweighs the cost. I would argue there is a lot of potential utility here: * A company which had a margin brokerage account could accept BTC for goods and hedge volatility between time of acquiring and time of selling by selling short the fund. * Speculators looking to go long could use margin to extend their leverage at lower cost and risk compared to systems like bitfinex. * Long term holders of physical BTC (in cold storage) could sell covered calls against the fund for USD cashflow without needing to periodically sell off BTC on exchanges of unknown risk. * Buying calls and puts would be a more sophisticated way of trading Bitcoins without dealing with entities of unknown trust. * Someone looking to borrow BTC but sell them for USD could hedge out the currency risk partially or fully through the use of options. If nothing else buying way out of the money calls would be a method of capping currency risk. |
|
|
|
It is kinda hard to believe people would still think dollars are backed by gold but then again fiat currencies are a relatively new "invention". The Federal Reserve Act lead to the creation of fiat currency in 1913 but National Money still existed along side it in various forums until 1968. Maybe he saw a really old dollar like this one and assumed the promise was still valid.  Or maybe one of the various silver notes issued over the years. However even if you find these notes today the promise of redemption has been rescinded (US notes in 1953 and silver notes in 1968).  These notes were the last national currency of the United States, issued by an independent treasury, outside the control of any bank, and backed by precious metal. I will say that again since it seems to be something that a lot of people simply don't get. The United States has not had a national currency since 1968 (and the begining of the end was in 1913). While FRNs may say "US Dollars" the Federal Reserve is a private cartel of corporations, and the private script they issue is as "federal" as Federal Express. If you deposit any of this "legacy" national currency at your local bank it will be replaced with FRNs and the notes sent to Treasury for destruction*. Why? Well banks don't like competition and they fought very hard for nearly two centuries (with lots of setbacks) to eliminate national currency in this country. Federal reserve notes are a currency in use in the United States, they are even accepted as legal tender in the United States but they are not money of the United States. If you didn't know this already likely right not your first thought it "no that can't be right". I would say the majority of Americans don't even realize there is a fundamental difference between the two notes. The United States Notes (and other forms of national currency issued by the treasury like silver certs) were a bill of credit. Each note being backed by reserves of precious metals (either silver or gold) in US Treasury vaults. In essence if you had a US note (prior to close of redemption) the US government OWED YOU the holder some value. This made it was exactly like buying and selling in physical bullion except more convenient. Federal reserve notes on the other hand are issued by debt. They are issued by the Federal Reserve and the interest becomes a perpetual obligation of the United States. Holding a federal reserve note doesn't mean the federal reserve owes you anything. On the contrary the very fact that you have a federal reserve note in your hand is proof the government is in debt to its bankers. If the US government had no debt there would be no federal reserve notes. As disgusting as the bait and switch is, I have to give credit where credit is due, the transition (which took decades) was an awesomely well played. It finally (by 1968) gave a private cartel of bankers something they schemed to acquire for nearly two centuries ... complete and absolute control over the money on the United States. Give me control of a nations money supply, and I care not who makes it’s laws. * A little bit of sad trivia. Since US notes were originally issued by the US government they were a liability of the treasury however the Treasury wasn't in debt because for each issued note it held an equal amount of precious metals (assets) thus the net liability on the Treasury was zero ($1 printed = $1 of gold/silver in reserve). However when the reserve was removed and sold off, the notes remained (thus $1 note = $1 liability with no matching reserve to offset it). This means the United States treasury acquired a debt equal to the amount of outstanding notes. By outstanding notes we only mean actual "legacy" national currency. FRNs aren't issued by the Treasury (they are bought by the treasury for debt). While US notes can no longer be redeemed for gold they can be redeemed for FRNs. Banks will do this as part of the normal business. They seperate the US notes from THEIR federal reserve notes and then ship them up to the federal reserve banks. The federal reserve then sells these notes to the Treasury for more debt in FRNs. Slowly overtime as the bills come out of circulation the debt by the Treasury to the holders of the currency is reduced but it is replaced by an equivalent amount of debt owed to the federal reserve. |
|
|
|
LMAO really? LMAO They aren't bad, this is computers not mints. Dust outputs don't take up any more space than a 100BTC transaction. They are painted bad cause the core developers can't fix the blockchain so that is the problem not the dust. That is like itunes saying we aren't going to allow any music less than 30 Secs. It makes no sense.
Well no you already know that dust has nothing to do with blockchain size but EVERYTHING to do with UXTO bloat. Dust (or a very high probability of dust approaching 1) won't be spent thus it remains in the UXTO. For normal economic transactions the UXTO only grows linearly (related more to the number of discrete entities not total transactions over time). This is good because the UXTO is a far more critical resource than the unpruned blockchain. It is highly likely that in the future most full nodes won't even maintain the full blockchain but they will need the entire UXTO. Having tiny worthless transactions which last forever in the UXTO lowers the efficiency of every node, forever. Of course you already knew all this but since you love to feign ignorance this correction is more to ensure others aren't mislead. |
|
|
|
So I'm not the only one who doesn't want to store thousands of tiny fractions, that are basically unspendable (or at least very expensive to spend) for other people.
It's easy to change online services to make them compatible with this and it can be changed back to a lower limit, if it's reasonable.
Do you guys always pay with $/€/... 0.01 coins?
Scalability & making it less expensive (in terms of storage) to run a full node is more important right now. Well done, Mr. Andresen.
I don't want to store any transaction over 100 coins, they waste space on my hard drive. I hope they block them soon. Scalability isn't an issue in P2P models, and storage is so inexpensive. Then do so. You have the freedom. You also have the freedom of relaying and/or mining 1 satoshi dust too. Freedom doesn't mean the authoritative hand to force others to do so. |
|
|
|
|
Show Posts
