In theory the state is taxing your use of the good within the state, not the interstate commerce itself. That's why they call it "use tax". Of course, they don't apply "use tax" if you've already paid sales tax, and the rates are always the same. It's an obvious technicality, but one they've managed to get away with.
Maybe I'm just dense, but I still don't see anything in your comment to support the idea that increasing scarcity will render bitcoins less valuable. If the divisibility were limited, sure, then I could buy that argument. It would work for gold, for example, because it's hard to handle small quantities (and there is an ultimate limit at one atom). But bitcoins can adjust to work no matter how many or how few there are. For that matter, the idea that the limit is 21 million BTC rather than 1 BTC or 1 uBTC is just a matter of definition. All the bitcoins in circulation will always have a combined value equal to the total Bitcoin economy. What matters is how many you have relative to the total number in circulation—your fraction of the economy.
... when all the coins have been mined, and nothing new is really being added, the amount of lost coins will overtake the value of the remaining coins.
Lost coins have no value. No one can use them. The fact that some coins are lost makes the remaining ones more valuable, not less. There is a finite limit to the number of bitcoins in existence, but there is no limit to their potential value. One uBTC could be worth the planetary GDP and there would still be plenty of bitcoins to go around (though we would have to adjust the protocol to support more decimal places).
Lastly bit coins are funny. they start at 21 million coins and keep making them smaller and smaller which is possible but really screws with pricing. you sell a service for 1 bit coin and then 1/2 a coin and 1/4 etc. Trying to price out a service and one week later your either charging double, or triple the rate.
It doesn't change that quickly. To get a doubling or tripling of prices you'd need to assume that 1/2 or 2/3 of all the coins in existence are lost in the course of a week. That just isn't going to happen. The change would be gradual, and no more difficult to adjust prices for than the current rate of inflation.
it's ridiculous how easy dodging the sales tax in usa has been. "oh but we're selling online!" yeah...
It's not just online; all out-of-state sales (think "mail-order") have been that way since the country was formed. Online retail just makes "mail-order" much more convenient and commonplace. Sales tax is a matter of state law, and states have no jurisdiction to impose taxes or tax collection duties on anyone outside the state. Amazon wants to change that by making sales tax collection and reporting a matter of federal law rather than state law. Amazon supports this because they would have to collect sales tax everywhere anyway, given their business plans, and they'd prefer to drag their more localized online competitors down with them.
I could see myself backing a uniform national sales tax against the current system, provided it was exclusive at both the state and federal levels. State and local jurisdictions could add their own percentages on top of the federal level, but couldn't vary any of the other details. Tax jurisdiction would be decided on the basis of where the goods are at the time they change ownership, or where the service is rendered. Businesses would only be required to deal with one federal organization, which would handle determination of jurisdiction and distribution of the non-federal portion to state and local governments. I'd even support an unconditional "refund" to every citizen equal to the federal sales tax rate times the poverty level, which should eliminate any concerns about it being a "regressive" tax.
I would insist on some guarantee that they wouldn't just add more taxes later, which probably implies a constitutional amendment.
What I don't understand is why Amazon actually cares about that.... They are a company that is located in a certain location (well maybe a few)...
Amazon has warehouses in quite a few places. They want to have them everywhere, to facilitate same-day deliveries. Under the current system, that means they would have a presence in every state, meaning that they would always need to collect sales tax anyway (for customers in states with sales taxes). This hurts them much more than most online retailers, who generally have a presence in one or two states and only have to worry about sales taxes for those states. That's why Amazon wants sales tax to be collected nationally: to make things just as expensive for their one- or two-state competitors as it would be for them, given their plans for expansion.
Personally, I have no problems with the "unfairness" of the current system, which is a natural consequence of the simple principle that states have no business taxing someone outside their jurisdiction (with jurisdiction most logically determined by where the property is at the time it changes ownership—either on delivery or at the warehouse—or where the service is rendered). If Amazon wants to subject itself to every state's jurisdiction, that's Amazon's problem.
To say that Bitcoins will experience a "deflation" is misleading, because although the amount of Bitcoins in circulation might become less and less, the amount in the ledger does not change !
When talking about inflation or deflation, it's more appropriate to reference the amount in circulation than the amount in the ledger. Money which isn't in circulation can't impact prices, and money which has become completely inaccessible might as well not exist at all.
The most likely outcome of Bitcoin is that when the amount in circulation gets down too low, people will abandon Bitcoin and start using other kinds of virtual money....
There is no such thing as "too low". Rather than abandoning Bitcoin, people can just use smaller units (mBTC, uBTC). As the amount in circulation decreases, the value of each unit increases to take up the slack. Bitcoin could work equally well with a steady-state limit of 1 BTC rather than 21 million BTC. It's really all just a matter of definition and perspective.
... at one point the amount of bit coins lost will be greater than the remaining ones and the value will plummet.
Care to explain your reasoning here? Scarcity would make the value rise, not plummet. And due to unlimited divisibility (assuming appropriate adjustments to the protocol to allow more than eight decimal places) there will always be enough bitcoins to go around, no matter how many are lost.
Capitalism is driven by greed, it is the basic underpinning of the theory.
Capitalism is driven by demand, which is not the same as greed. It recognizes the existence of greed and doesn't break down in its presence, unlike most other systems, but it doesn't reward greed when it leads to irrational behavior. More than anything else, capitalism rewards rational analysis of costs and benefits and voluntary cooperation for mutual benefit (in short: enlightened self-interest).
If I write my Congressman and say, "stop the dam". I've just lobbied. I think what you're really aiming at is, me writing the Congressman and saying, "Remember me? I'm one of your tier-1 donors who also donated an extra $100,000 to your PAC. Build the dam".... The former is a legitimate functioning of our system. The latter is bribery that flies under the radar because some lawyers baked just the right logic pretzel so, "money is speech".
Forget about the donations; they're an irrelevant distraction. The real problem is representative acting against the interests of the very people they're supposed to represent. If a politician accepts a bribe and yet still does the right thing (which may or may not be what he was bribed to do) then there is no problem. If the same politician does not take any bribes, but votes against his constituents' interests, that's a problem.
My proposal would be to allow any representative's constituents to hold a vote of no confidence at any time. If that vote passes, the representative is immediately recalled (without any further pay or benefits), and a new election is called to replace them. There could also be civil liability depending on the state's laws, assuming malfeasance can be proved. A no-confidence vote would be a big step, and probably not used often, but it would mean that you either maintain the trust of your constituents or face immediate and permanent consequences. The prospect of losing the next election isn't nearly enough. It's usually several years away, for a start; it doesn't carry any particular note of censure; and after losing your bid for reelection you still get to keep your pension.
Although you're correct about the 1877 case, it has since been expanded by both Congressional amendments to the statute in the 1952 act, and Supreme Court opinions - see Gottschalk v. Benson in 1972, noting in dicta: "It is said that the decision precludes a patent for any program servicing a computer. We do not so hold."
Having recently reviewed the three major USSC cases relating to patentable subject matter (Gottschalk v. Benson (1972), Parker v. Flook (1978), and Diamond v. Diehr (1981)), I can only conclude that in each case software patents as such were rejected outright. The language generally cited to the contrary seems only to exist to make it clear that an otherwise patentable discovery which happens to include software as a component is not rendered unpatentable merely by the presence of software. (You can patent a novel mousetrap which happens to use software as part of the trigger, but similar software wouldn't violate the patent if used in a context other than a similar mousetrap.)
The common arguments that "software on a computer" (Benson) or "software with an insignificant post-solution step" (Flook) are somehow different from pure software were explicitly rejected.
Regarding Bilski, the USSC still ended up rejecting that particular business method patent using logic similar to that in Benson and Flook. The majority opinion cast some doubt on the exclusive authority of the "machine or transformation" test (as did Benson and Flook), but only because they considered the prohibition on patents on abstract ideas sufficient. The two concurring opinions both rejected the idea that business methods could be patentable subject matter under other circumstances.
In short, I don't see how Bilski could be said to change anything. It upheld the Benson and Flook ruling to the letter, and while they carefully didn't rule that business methods are excluded subject matter, the ruling did strongly imply that such patents would be invalid on the basis that they cover abstract ideas, which amounts to the same thing.
Abolish software and "business method" patents. They're not *things*, just ideas. They're not what patents were *created* to protect.
35 USC 101... states that whoever invents or discovers "any new and useful process [...] may obtain a patent therefor..." A process is not a *thing*, just an idea... but clearly, that is what patents were created to protect.
While I agree with you that patents ultimately monopolize the use of ideas rather than things, Cochrane v. Deener (94 US 780 - Supreme Court 1877) explained the term "process" as follows:
A process is a mode of treatment of certain materials to produce a given result. It is an act, or a series of acts, performed upon the subject-matter to be transformed and reduced to a different state or thing.
Software and business methods obviously do not meet this standard. There are no "certain materials" to be transformed, and the goal is not to reduce them to a different state or thing. Only physical processes count as patentable subject matter.
Google has a virtual monopoly in search. Weakening Google's position in search would enhance not diminish competition.
Weakening Google's position in search by providing something better would enhance competition. Weakening their position through bogus patent infringement claims is not competition; that's just dragging a more successful competitor down out of spite, to everyone's detriment. The whole point of competition, and the reason we generally try to encourage it, is that the best product wins. The goal is not simply to divide the market up as evenly as possible.
Anything that stifles consumption (especially among the poorest) is in my opinion economic sabotage.... The consumption in itself is not the evil here, consumption is the way out of this mess.
If you want to increase consumption sustainably, you need to encourage people to save and invest in the short term to increase their available resources in the long term. Over-consumption on credit amounts to "eating your seed corn"; it solves your immediate hunger problem, but you won't have anything to eat next year.
The mess in (parts of) Europe is the result of economies bankrupted by years of out-of-control consumption. It's the inevitable end result of exactly the policies you advocate. People want to consume, and that desire is the drive behind the entire economy, but if it isn't matched by production (enabled by saving and investment) then pushing people to consume more does nothing but burn capital and drive up consumer prices—"more money chasing fewer goods". Income redistribution, likewise, has the effect of impairing productive capacity while increasing effective demand for consumer goods, bidding prices up further.
You don't have to tell people to want things. They do that on their own. What people need to know is how to get from wanting things to having them, and the secret to that is saving.
Wrong. Only signed overflow and underflow are undefined. Unsigned arithmetic is, indeed, defined as modular. From ISO/IEC9899:TC3:
A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type.
Apparently I know too much for my own good about how binary numbers work.
No, the problem is that you know just enough to be dangerous. The C standard was written to support real architectures which did not use two's complement to represent signed integers; some of the other options include sign-magnitude and biased representation. These architectures are uncommon today, but that is why signed overflow and underflow are undefined. INT_MAX+1 could be INT_MIN, or it could be zero (or even negative zero). It could also cause an exception. Even with two's complement there is the possibility that signed and unsigned integers are not the same width; the standard allows for "padding" bits.
Note that conversion from signed to unsigned is defined to always give the two's complement representation, so if you explicitly cast to an unsigned integer type the problem goes away. (Though you have to use "> INT_MAX" rather than "< 0".)
Actually, ordinary loans from banks are exactly the same as loans from the Fed.... "borrowing" from a commercial bank (loan, credit card, line of credit) is also not "real borrowing".
Agreed. By "ordinary loans", I meant loans where someone has something and lends it to you for a time, rather than simply making it up out of thin air. Borrowing money from a friend, for example.
Normal banks at least have reserve requirements, meaning that they have to give something up to make their "loans", even if it's only a small fraction of the size of the loan. They are also liable for all their "deposits", and can't just order more paper money from the Treasury on demand. The Federal Reserve has no such restrictions, and the loans they extend to member banks count as "reserves", amplifying the effect.
"if (buf + len < buf)" does make perfect sense, because it catches a bug that is caused precisely by the fact that buf + len can become less that buf due to overflow.
The root cause of this problem isn't overflowing the pointer type, it's overflowing the range of your buffer. Unless your buffer extends all the way to the end of the address space, there are many possible buffer overflow conditions which this code won't catch. You should check len against the size of the buffer, or a pointer to the last element of the buffer (like "if ((0 <= len) && (len <= buff_end - buf))"), both of which are compliant with the standard and won't be eliminated automatically.
Maybe I'm overlooking the obvious, but how could foo = foo++ in a loop ever not be undefined behaviour?
That's the point, it's always undefined behavior. It doesn't even matter whether you're in a loop. It is undefined behavior to modify the stored value of an object more than once between two adjacent sequence points, as this statement does by combining assignment and post-increment of the same variable in the same expression. Even ignoring the fact that this explicitly violates the (C99) standard, the result would depend on which update occurs first; the standard only says that the stored values must be updated before the next sequence point (in any order). If the incremented value is stored first, it will be overwritten by the assignment of the pre-incremented value and nothing will change.
The correct way to write this expression is simply "foo++", with no assignment.
Borrowing money under the "fractional reserve" system adds money to circulation for the duration of the loan.... Simply printing money to pay off existing debt does not increase the amount of money in circulation and, thus, has no impact on inflation.... Printing too much leads to inflation. But so does borrowing too much.
This is only because there is no real "borrowing" going on. When the Federal Reserve extends loans to its member banks, those loans don't come out of existing savings like ordinary loans, which would be inflation-neutral. Instead, new money is "printed" (digitally). That's where the inflation comes from. Paying off the debt held by the Federal Reserve (which is only a fraction of the total) with a couple of trillion-dollar platinum coins would just be exchanging one form of "printed" money for another. Paying off the debt to anyone else in the same manner would create inflation, again assuming that the Federal Reserve didn't do something independently to offset the effect.
I did assume a constant difficulty, or rather a constant cost to maintain the attack. In the end the difficulty is going to be determined mainly by the cost of energy, once all the efficiency gains (GPU vs. FPGA vs. ASIC, etc.) have been worked out. It won't keep increasing indefinitely. As difficulty increases, the profitability of mining decreases, which acts as negative feedback. On the other hand, if difficulty does increase, say by 1% per year, that just means you'd need even more seed money to offset the increasing cost. You'd need to pay for the attack with 4% and put the remaining 1% back into growing the investment, meaning you'd need 75 times as much money rather than 60 times. Which, ultimately, only reinforces my argument that a permanent 51% attack would be much more costly than a limited 120-day attack.
If you don't give each order a unique receiving address, you have no idea which incoming funds are meant to pay for which orders. You give the buyer an address to send funds to; they aren't expected to know which address(es) the funds come from. They just enter the receiving address and amount (or scan a QR code) and tap "send". Some of the smaller clients stick to a single address and private key, but most of them, including the official client, use randomly-generated "change" addresses which aren't shown by default in the UI. Any number of transactions to different addresses ("change" or otherwise) may be combined to fund a single transfer. This doesn't even consider web-wallets (like Coinbase) where the funds come from a shared address controlled by the service provider.
In practice, every merchant accepting bitcoins today already uses unique receiving addresses. It's not nearly as much of a headache as you seem to think. For the buyer it's completely transparent, and for merchants the process is built into standard shopping-cart interfaces. It's all completely automated. (The real headache is processing refunds.)
P.S. No one would hold a customer at a brick-and-mortar store waiting for confirmations; there's less risk of fraud once they've seen the transaction relayed to the network, even with zero confirmations, than there would be from normal credit card chargebacks up to several months later. If they're really concerned, they'll just require ID so that they can track you down later. It's not like you could get very far in 30 minutes anyway.
Beating the network indefinitely would cost about 60 times as much, assuming you can get a reliable 5% APY. (If a 120-day attack costs $X, then the yield from a 60*$X investment at 5% is sufficient to maintain the attack indefinitely.) A factor of 60 is a fairly large difference.
That's assuming you only have 51%. The time required increases asymptotically as you approach 50%. At 60% the attack would take only 12 days, reducing your overall cost by an order of magnitude.
A power supply I'll grant you. I forgot that the Pi boards don't come with one, so that puts us a few dollars over budget. Technical expertise and tools were not included for the $3000 computer in 1985, so it would be unfair to complain that the Pi doesn't include them now. You can get better software for free these days which didn't exist at any price then. And then there's computers like the MK908, which is a bit pricier at $55 but includes a case, WiFi, Bluetooth 4.0, a power supply, and pre-installed software for an essentially plug-and-play experience—just add a cheap USB keyboard and hook it up to your TV.
Businesses will have plenty of incentive to switch to semi-autonomous vehicles for their fleets, provided they're actually safer. That translates into reduced exposure to liability for accidents, less money spent repairing and/or replacing vehicles (and employees), and less lost cargo. If nothing else, their insurance providers will insist on it.
You wouldn't need 51% "indefinitely", just long enough to catch up and make your chain the longest blockchain. After that the rest of the network has a choice: follow the protocol and use your blockchain, or perform a deliberate 51% attack of their own.
Checkpoints and other "community-based mechanisms" are outside of the Bitcoin protocol. In any case checkpoints are inserted into the official client on fairly rare occasions to cover blocks which are already well-established. There won't be any checkpoint protecting the FBI's transaction for some time.
You can't spend someone else's coins without their private key, but you can rewrite history by coming up with a longer blockchain which does not include certain previously-accepted transactions. That would allow DPR, or someone else with his private key, to transfer the funds "before" the FBI moves them to a different account.
At this point it would be really expensive to pull off, since the FBI's transfers are buried 346 blocks behind the head of the blockchain, but you could do it if you controlled 51% or more of the mining network for a long enough time. Assuming you had exactly 51% of the network, and started right now, it should take right at 120 days to overcome the current blockchain's lead. That gets significantly better as you control more of the network; in the best case, if 100% of the network went along with the scheme, it would only take two days.
Publish your account number publicly, like any legitimate business would do to accept payments...
The recommendation is to use a different account for each order, not just for anonymity but so that you can distinguish the payments apart from the amount, which may not be unique, or even an exact match for the order in the event of a mistake. It's fairly rare even for "legitimate" businesses to have just one account number.
Even apart from unique receiving addresses, any business dealing in large quantities of bitcoins will probably want separate "working funds" and offline "cold storage" accounts, and general practice is to generate a new address every time you send funds to receive the "change". Some consider this more secure against cryptoanalysis since the full public key isn't revealed until the funds are spent, meaning that if you do use a new address every time then the only addresses with known public keys contain no funds.
Slashdot Mirror
In theory the state is taxing your use of the good within the state, not the interstate commerce itself. That's why they call it "use tax". Of course, they don't apply "use tax" if you've already paid sales tax, and the rates are always the same. It's an obvious technicality, but one they've managed to get away with.
Maybe I'm just dense, but I still don't see anything in your comment to support the idea that increasing scarcity will render bitcoins less valuable. If the divisibility were limited, sure, then I could buy that argument. It would work for gold, for example, because it's hard to handle small quantities (and there is an ultimate limit at one atom). But bitcoins can adjust to work no matter how many or how few there are. For that matter, the idea that the limit is 21 million BTC rather than 1 BTC or 1 uBTC is just a matter of definition. All the bitcoins in circulation will always have a combined value equal to the total Bitcoin economy. What matters is how many you have relative to the total number in circulation—your fraction of the economy.
... when all the coins have been mined, and nothing new is really being added, the amount of lost coins will overtake the value of the remaining coins.
Lost coins have no value. No one can use them. The fact that some coins are lost makes the remaining ones more valuable, not less. There is a finite limit to the number of bitcoins in existence, but there is no limit to their potential value. One uBTC could be worth the planetary GDP and there would still be plenty of bitcoins to go around (though we would have to adjust the protocol to support more decimal places).
Lastly bit coins are funny. they start at 21 million coins and keep making them smaller and smaller which is possible but really screws with pricing. you sell a service for 1 bit coin and then 1/2 a coin and 1/4 etc. Trying to price out a service and one week later your either charging double, or triple the rate.
It doesn't change that quickly. To get a doubling or tripling of prices you'd need to assume that 1/2 or 2/3 of all the coins in existence are lost in the course of a week. That just isn't going to happen. The change would be gradual, and no more difficult to adjust prices for than the current rate of inflation.
it's ridiculous how easy dodging the sales tax in usa has been. "oh but we're selling online!" yeah...
It's not just online; all out-of-state sales (think "mail-order") have been that way since the country was formed. Online retail just makes "mail-order" much more convenient and commonplace. Sales tax is a matter of state law, and states have no jurisdiction to impose taxes or tax collection duties on anyone outside the state. Amazon wants to change that by making sales tax collection and reporting a matter of federal law rather than state law. Amazon supports this because they would have to collect sales tax everywhere anyway, given their business plans, and they'd prefer to drag their more localized online competitors down with them.
I could see myself backing a uniform national sales tax against the current system, provided it was exclusive at both the state and federal levels. State and local jurisdictions could add their own percentages on top of the federal level, but couldn't vary any of the other details. Tax jurisdiction would be decided on the basis of where the goods are at the time they change ownership, or where the service is rendered. Businesses would only be required to deal with one federal organization, which would handle determination of jurisdiction and distribution of the non-federal portion to state and local governments. I'd even support an unconditional "refund" to every citizen equal to the federal sales tax rate times the poverty level, which should eliminate any concerns about it being a "regressive" tax.
I would insist on some guarantee that they wouldn't just add more taxes later, which probably implies a constitutional amendment.
What I don't understand is why Amazon actually cares about that. ... They are a company that is located in a certain location (well maybe a few)...
Amazon has warehouses in quite a few places. They want to have them everywhere, to facilitate same-day deliveries. Under the current system, that means they would have a presence in every state, meaning that they would always need to collect sales tax anyway (for customers in states with sales taxes). This hurts them much more than most online retailers, who generally have a presence in one or two states and only have to worry about sales taxes for those states. That's why Amazon wants sales tax to be collected nationally: to make things just as expensive for their one- or two-state competitors as it would be for them, given their plans for expansion.
Personally, I have no problems with the "unfairness" of the current system, which is a natural consequence of the simple principle that states have no business taxing someone outside their jurisdiction (with jurisdiction most logically determined by where the property is at the time it changes ownership—either on delivery or at the warehouse—or where the service is rendered). If Amazon wants to subject itself to every state's jurisdiction, that's Amazon's problem.
To say that Bitcoins will experience a "deflation" is misleading, because although the amount of Bitcoins in circulation might become less and less, the amount in the ledger does not change !
When talking about inflation or deflation, it's more appropriate to reference the amount in circulation than the amount in the ledger. Money which isn't in circulation can't impact prices, and money which has become completely inaccessible might as well not exist at all.
The most likely outcome of Bitcoin is that when the amount in circulation gets down too low, people will abandon Bitcoin and start using other kinds of virtual money....
There is no such thing as "too low". Rather than abandoning Bitcoin, people can just use smaller units (mBTC, uBTC). As the amount in circulation decreases, the value of each unit increases to take up the slack. Bitcoin could work equally well with a steady-state limit of 1 BTC rather than 21 million BTC. It's really all just a matter of definition and perspective.
... at one point the amount of bit coins lost will be greater than the remaining ones and the value will plummet.
Care to explain your reasoning here? Scarcity would make the value rise, not plummet. And due to unlimited divisibility (assuming appropriate adjustments to the protocol to allow more than eight decimal places) there will always be enough bitcoins to go around, no matter how many are lost.
Capitalism is driven by greed, it is the basic underpinning of the theory.
Capitalism is driven by demand, which is not the same as greed. It recognizes the existence of greed and doesn't break down in its presence, unlike most other systems, but it doesn't reward greed when it leads to irrational behavior. More than anything else, capitalism rewards rational analysis of costs and benefits and voluntary cooperation for mutual benefit (in short: enlightened self-interest).
If I write my Congressman and say, "stop the dam". I've just lobbied. I think what you're really aiming at is, me writing the Congressman and saying, "Remember me? I'm one of your tier-1 donors who also donated an extra $100,000 to your PAC. Build the dam". ... The former is a legitimate functioning of our system. The latter is bribery that flies under the radar because some lawyers baked just the right logic pretzel so, "money is speech".
Forget about the donations; they're an irrelevant distraction. The real problem is representative acting against the interests of the very people they're supposed to represent. If a politician accepts a bribe and yet still does the right thing (which may or may not be what he was bribed to do) then there is no problem. If the same politician does not take any bribes, but votes against his constituents' interests, that's a problem.
My proposal would be to allow any representative's constituents to hold a vote of no confidence at any time. If that vote passes, the representative is immediately recalled (without any further pay or benefits), and a new election is called to replace them. There could also be civil liability depending on the state's laws, assuming malfeasance can be proved. A no-confidence vote would be a big step, and probably not used often, but it would mean that you either maintain the trust of your constituents or face immediate and permanent consequences. The prospect of losing the next election isn't nearly enough. It's usually several years away, for a start; it doesn't carry any particular note of censure; and after losing your bid for reelection you still get to keep your pension.
Although you're correct about the 1877 case, it has since been expanded by both Congressional amendments to the statute in the 1952 act, and Supreme Court opinions - see Gottschalk v. Benson in 1972, noting in dicta: "It is said that the decision precludes a patent for any program servicing a computer. We do not so hold."
Having recently reviewed the three major USSC cases relating to patentable subject matter ( Gottschalk v. Benson (1972), Parker v. Flook (1978), and Diamond v. Diehr (1981)), I can only conclude that in each case software patents as such were rejected outright. The language generally cited to the contrary seems only to exist to make it clear that an otherwise patentable discovery which happens to include software as a component is not rendered unpatentable merely by the presence of software. (You can patent a novel mousetrap which happens to use software as part of the trigger, but similar software wouldn't violate the patent if used in a context other than a similar mousetrap.)
The common arguments that "software on a computer" (Benson) or "software with an insignificant post-solution step" (Flook) are somehow different from pure software were explicitly rejected.
Regarding Bilski, the USSC still ended up rejecting that particular business method patent using logic similar to that in Benson and Flook. The majority opinion cast some doubt on the exclusive authority of the "machine or transformation" test (as did Benson and Flook), but only because they considered the prohibition on patents on abstract ideas sufficient. The two concurring opinions both rejected the idea that business methods could be patentable subject matter under other circumstances.
In short, I don't see how Bilski could be said to change anything. It upheld the Benson and Flook ruling to the letter, and while they carefully didn't rule that business methods are excluded subject matter, the ruling did strongly imply that such patents would be invalid on the basis that they cover abstract ideas, which amounts to the same thing.
Abolish software and "business method" patents. They're not *things*, just ideas. They're not what patents were *created* to protect.
35 USC 101 ... states that whoever invents or discovers "any new and useful process [...] may obtain a patent therefor..." A process is not a *thing*, just an idea... but clearly, that is what patents were created to protect.
While I agree with you that patents ultimately monopolize the use of ideas rather than things, Cochrane v. Deener (94 US 780 - Supreme Court 1877) explained the term "process" as follows:
A process is a mode of treatment of certain materials to produce a given result. It is an act, or a series of acts, performed upon the subject-matter to be transformed and reduced to a different state or thing.
Software and business methods obviously do not meet this standard. There are no "certain materials" to be transformed, and the goal is not to reduce them to a different state or thing. Only physical processes count as patentable subject matter.
Google has a virtual monopoly in search. Weakening Google's position in search would enhance not diminish competition.
Weakening Google's position in search by providing something better would enhance competition. Weakening their position through bogus patent infringement claims is not competition; that's just dragging a more successful competitor down out of spite, to everyone's detriment. The whole point of competition, and the reason we generally try to encourage it, is that the best product wins. The goal is not simply to divide the market up as evenly as possible.
Anything that stifles consumption (especially among the poorest) is in my opinion economic sabotage. ... The consumption in itself is not the evil here, consumption is the way out of this mess.
If you want to increase consumption sustainably, you need to encourage people to save and invest in the short term to increase their available resources in the long term. Over-consumption on credit amounts to "eating your seed corn"; it solves your immediate hunger problem, but you won't have anything to eat next year.
The mess in (parts of) Europe is the result of economies bankrupted by years of out-of-control consumption. It's the inevitable end result of exactly the policies you advocate. People want to consume, and that desire is the drive behind the entire economy, but if it isn't matched by production (enabled by saving and investment) then pushing people to consume more does nothing but burn capital and drive up consumer prices—"more money chasing fewer goods". Income redistribution, likewise, has the effect of impairing productive capacity while increasing effective demand for consumer goods, bidding prices up further.
You don't have to tell people to want things. They do that on their own. What people need to know is how to get from wanting things to having them, and the secret to that is saving.
Wrong. Only signed overflow and underflow are undefined. Unsigned arithmetic is, indeed, defined as modular. From ISO/IEC9899:TC3:
A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type.
Apparently I know too much for my own good about how binary numbers work.
No, the problem is that you know just enough to be dangerous. The C standard was written to support real architectures which did not use two's complement to represent signed integers; some of the other options include sign-magnitude and biased representation. These architectures are uncommon today, but that is why signed overflow and underflow are undefined. INT_MAX+1 could be INT_MIN, or it could be zero (or even negative zero). It could also cause an exception. Even with two's complement there is the possibility that signed and unsigned integers are not the same width; the standard allows for "padding" bits.
Note that conversion from signed to unsigned is defined to always give the two's complement representation, so if you explicitly cast to an unsigned integer type the problem goes away. (Though you have to use "> INT_MAX" rather than "< 0".)
Actually, ordinary loans from banks are exactly the same as loans from the Fed. ... "borrowing" from a commercial bank (loan, credit card, line of credit) is also not "real borrowing".
Agreed. By "ordinary loans", I meant loans where someone has something and lends it to you for a time, rather than simply making it up out of thin air. Borrowing money from a friend, for example.
Normal banks at least have reserve requirements, meaning that they have to give something up to make their "loans", even if it's only a small fraction of the size of the loan. They are also liable for all their "deposits", and can't just order more paper money from the Treasury on demand. The Federal Reserve has no such restrictions, and the loans they extend to member banks count as "reserves", amplifying the effect.
"if (buf + len < buf)" does make perfect sense, because it catches a bug that is caused precisely by the fact that buf + len can become less that buf due to overflow.
The root cause of this problem isn't overflowing the pointer type, it's overflowing the range of your buffer. Unless your buffer extends all the way to the end of the address space, there are many possible buffer overflow conditions which this code won't catch. You should check len against the size of the buffer, or a pointer to the last element of the buffer (like "if ((0 <= len) && (len <= buff_end - buf))"), both of which are compliant with the standard and won't be eliminated automatically.
Maybe I'm overlooking the obvious, but how could foo = foo++ in a loop ever not be undefined behaviour?
That's the point, it's always undefined behavior. It doesn't even matter whether you're in a loop. It is undefined behavior to modify the stored value of an object more than once between two adjacent sequence points, as this statement does by combining assignment and post-increment of the same variable in the same expression. Even ignoring the fact that this explicitly violates the (C99) standard, the result would depend on which update occurs first; the standard only says that the stored values must be updated before the next sequence point (in any order). If the incremented value is stored first, it will be overwritten by the assignment of the pre-incremented value and nothing will change.
The correct way to write this expression is simply "foo++", with no assignment.
Borrowing money under the "fractional reserve" system adds money to circulation for the duration of the loan. ... Simply printing money to pay off existing debt does not increase the amount of money in circulation and, thus, has no impact on inflation. ... Printing too much leads to inflation. But so does borrowing too much.
This is only because there is no real "borrowing" going on. When the Federal Reserve extends loans to its member banks, those loans don't come out of existing savings like ordinary loans, which would be inflation-neutral. Instead, new money is "printed" (digitally). That's where the inflation comes from. Paying off the debt held by the Federal Reserve (which is only a fraction of the total) with a couple of trillion-dollar platinum coins would just be exchanging one form of "printed" money for another. Paying off the debt to anyone else in the same manner would create inflation, again assuming that the Federal Reserve didn't do something independently to offset the effect.
I did assume a constant difficulty, or rather a constant cost to maintain the attack. In the end the difficulty is going to be determined mainly by the cost of energy, once all the efficiency gains (GPU vs. FPGA vs. ASIC, etc.) have been worked out. It won't keep increasing indefinitely. As difficulty increases, the profitability of mining decreases, which acts as negative feedback. On the other hand, if difficulty does increase, say by 1% per year, that just means you'd need even more seed money to offset the increasing cost. You'd need to pay for the attack with 4% and put the remaining 1% back into growing the investment, meaning you'd need 75 times as much money rather than 60 times. Which, ultimately, only reinforces my argument that a permanent 51% attack would be much more costly than a limited 120-day attack.
If you don't give each order a unique receiving address, you have no idea which incoming funds are meant to pay for which orders. You give the buyer an address to send funds to; they aren't expected to know which address(es) the funds come from. They just enter the receiving address and amount (or scan a QR code) and tap "send". Some of the smaller clients stick to a single address and private key, but most of them, including the official client, use randomly-generated "change" addresses which aren't shown by default in the UI. Any number of transactions to different addresses ("change" or otherwise) may be combined to fund a single transfer. This doesn't even consider web-wallets (like Coinbase) where the funds come from a shared address controlled by the service provider.
In practice, every merchant accepting bitcoins today already uses unique receiving addresses. It's not nearly as much of a headache as you seem to think. For the buyer it's completely transparent, and for merchants the process is built into standard shopping-cart interfaces. It's all completely automated. (The real headache is processing refunds.)
P.S. No one would hold a customer at a brick-and-mortar store waiting for confirmations; there's less risk of fraud once they've seen the transaction relayed to the network, even with zero confirmations, than there would be from normal credit card chargebacks up to several months later. If they're really concerned, they'll just require ID so that they can track you down later. It's not like you could get very far in 30 minutes anyway.
Beating the network indefinitely would cost about 60 times as much, assuming you can get a reliable 5% APY. (If a 120-day attack costs $X, then the yield from a 60*$X investment at 5% is sufficient to maintain the attack indefinitely.) A factor of 60 is a fairly large difference.
That's assuming you only have 51%. The time required increases asymptotically as you approach 50%. At 60% the attack would take only 12 days, reducing your overall cost by an order of magnitude.
A power supply I'll grant you. I forgot that the Pi boards don't come with one, so that puts us a few dollars over budget. Technical expertise and tools were not included for the $3000 computer in 1985, so it would be unfair to complain that the Pi doesn't include them now. You can get better software for free these days which didn't exist at any price then. And then there's computers like the MK908, which is a bit pricier at $55 but includes a case, WiFi, Bluetooth 4.0, a power supply, and pre-installed software for an essentially plug-and-play experience—just add a cheap USB keyboard and hook it up to your TV.
Businesses will have plenty of incentive to switch to semi-autonomous vehicles for their fleets, provided they're actually safer. That translates into reduced exposure to liability for accidents, less money spent repairing and/or replacing vehicles (and employees), and less lost cargo. If nothing else, their insurance providers will insist on it.
You wouldn't need 51% "indefinitely", just long enough to catch up and make your chain the longest blockchain. After that the rest of the network has a choice: follow the protocol and use your blockchain, or perform a deliberate 51% attack of their own.
Checkpoints and other "community-based mechanisms" are outside of the Bitcoin protocol. In any case checkpoints are inserted into the official client on fairly rare occasions to cover blocks which are already well-established. There won't be any checkpoint protecting the FBI's transaction for some time.
You can't spend someone else's coins without their private key, but you can rewrite history by coming up with a longer blockchain which does not include certain previously-accepted transactions. That would allow DPR, or someone else with his private key, to transfer the funds "before" the FBI moves them to a different account.
At this point it would be really expensive to pull off, since the FBI's transfers are buried 346 blocks behind the head of the blockchain, but you could do it if you controlled 51% or more of the mining network for a long enough time. Assuming you had exactly 51% of the network, and started right now, it should take right at 120 days to overcome the current blockchain's lead. That gets significantly better as you control more of the network; in the best case, if 100% of the network went along with the scheme, it would only take two days.
Publish your account number publicly, like any legitimate business would do to accept payments...
The recommendation is to use a different account for each order, not just for anonymity but so that you can distinguish the payments apart from the amount, which may not be unique, or even an exact match for the order in the event of a mistake. It's fairly rare even for "legitimate" businesses to have just one account number.
Even apart from unique receiving addresses, any business dealing in large quantities of bitcoins will probably want separate "working funds" and offline "cold storage" accounts, and general practice is to generate a new address every time you send funds to receive the "change". Some consider this more secure against cryptoanalysis since the full public key isn't revealed until the funds are spent, meaning that if you do use a new address every time then the only addresses with known public keys contain no funds.