|
What's the connection between Mallick and Paxum?
|
|
|
|
1) If people make the password complex, more people will lose their funds by forgetting the password than would have their coins stolen by trojan. So are you basically saying that it's better to leave the door to your house open for a potential thief just because you might lose the key? If losing the key meant you could never ever get into your house again, hell yeah! 2) If you require the password to be entered for every operation, the password will easily be captured by a trojan. So you have to allow 'passive' operations (such as checking your balance) to work without a password. You can also think about non-text passwords. Like an image of 25 colored fields where you have to click a color code. If you make a complete proposal, I'll tell you what's wrong with it.  The hard part with things like that is they're much harder to remember or write down. 3) Therefore a trojan author can know which wallets contain the most bitcoins through these passive operations. He can transfer the encrypted wallets, and use compromised machines to brute force the password. Bruteforcing salted passwords? Seriously. The investment in computing power required to do that within your lifetime would be larger than the possible gains from breaking a wallet. It depends on how long the passwords are. Long passwords bring back the lost password problem. You could enforce a minimum password strength. Many websites do this already to avoid "password" or "12345" from being used. I guess making it obvious to a user that his money should be protected the same way isn't that hard. I'm not saying that wallet encryption solves every imaginable problem; but it's a very big step towards security. Besides, if it wouldn't matter, why is there a how-to about using Truecrypt?
Again, it's hard to comment on fragmented ideas. Nobody was able to put a good proposal together. Every design suggestion had upsides and downsides and on balance, none were much better than nothing at all. None really justified the risk of creating a false sense of security. |
|
|
|
Anyway, JoelKatz, have you seen this page? http://keepass.info/help/base/security.html If not, does it affect your opinion on KeePass? For the record, I want to know because I use it and not because I'm involved with the project. I saw a similar page, but it didn't have as much detail as that one. This one does make clear that the hashes are salted and iterations are used. That's good because it means someone trying to brute force passwords can't use a rainbow table and can't gain efficiency (at least not very much) by trying to brute force many different people at the same time. (I'll edit my earlier post.) Just make sure to use a password that's not easily brute forceable. And, of course, you still have to worry about a trojan catching your keystrokes as you enter it. |
|
|
|
|
Sent. Awaiting confirmations.
|
|
|
|
|
I think it's important to separate the issue in two:
1) How would a Libertarian society handle the case where something people benefited from individually in sum caused massive harm to everyone -- a case where each person individual benefits from "defecting" but where everyone would benefit if they could all "cooperate".
2) Is global warming a problem of this type?
I suggest you try to either work on one issue or the other but not both at the same time. When talking about how a Libertarian society would handle warming, assuming that man-made releases of CO2 have a significant risk of causing a global cataclysm. When talking about the actual scientific issues with AGW, forget about politics.
The one point I keep trying to make is this -- regardless of how well or badly a Libertarian society would address global warming (or similar problems like pollution), democracies have done at best a mediocre job and, more typically, a terrible job. The only thing that seems to address these problems effectively is prosperity and technology.
|
|
|
|
|
Post (or pm) a wallet address and I'll give it to you.
|
|
|
|
Disagree. The deflation built into the system is the lack of an expansionary monetary policy tool beyond what is set by the algorithm. Couple that with the increase in demand and you have a large delta between supply and demand. Supply could not be increased to meet demand, thus prices rose. That's virtually impossible. If people know that demand was going to increase, they'd want to hold the currency. So demand will already have increased because of the expected future increase. But if demand has already increased because of a future increase, then there won't be a future increase. This is again the same erroneous reasoning that "bitcoins are worth X today, and they're have some extra value because demand is going to increase". Or, to put it more simply, it's saying "nobody will want bitcoins because the demand will be too high". |
|
|
|
|
You do need CPU power, because you have to complete several SHA-256 hashes for each work unit you generate.
|
|
|
|
How would it matter if there's a delivery of a product that's traceable? The claims in this case aren't that TradeHill didn't do what they said they were going to do, the claim is that the original transfer is unauthorized. The situation would be precisely the same if TradeHill had shipped them a physical product. It matters because Tradehill were offering a service that had the equivalent of a big neon sign on it reading "ideal for laundering stolen money". Of course, they should've reacted by refusing to do business with Bitcoin marketplaces from the start. Excellent point. I don't think Dwolla could have refused to do business with Bitcoin marketplaces from the start. Part of their business model and sales pitch is that they don't care what you do so long as it's legal. |
|
|
|
|
The default bitcoin client has a two second delay after solving a block before it will do anything else. Hopefully, all pool operators have removed it. (It's main.cpp line 2921 or so.)
|
|
|
|
So now it's been a few hours since I bought some bitcoins on MTGox and they still haven't shown up in my wallet software. How long does it take?
Do you see them in block explorer? If your wallet software is the bitcoin client, it has to "catch up" to the network, and that can take many hours. The money may already be yours, your client just hasn't gotten to that transaction yet. The bitcoin client, when you first start it up, has to verify every single bitcoin transaction that has ever taken place to confirm that the coins that were sent to you were done so validly. |
|
|
|
Check your receiving address in blockexplorer. You may already have them but just not know you have them. http://blockexplorer.com/If your client doesn't have at least 138,544 blocks, it isn't caught up to now. |
|
|
|
Hmmm. The consensus seems to be that rather than mess with bitcoin, I should shut up and make my own block chain! Only because your ideas don't improve bitcoins but take them in a completely different direction. Something that would improve bitcoins and would also make your ideas easier to implement would be a secure and distributed way to pull bitcoins out of one hash chain and insert them into a new hash chain in such a way that they could securely be imported back into the bitcoin hash chain. Unfortunately, I'm not clever enough to come up with a way to do that ... yet. (The primary issue is that whoever pulls bitcoins out of the bitcoin hash chain has to specify how they're claimed. There's no good way to say 'they can be claimed by whoever owns so many coins in another hash chain'. One obvious way, to require all bitcoin clients to follow the other hash chain to verify the re-import is a non-starter. And requiring the bitcoins be transferred in the bitcoin hash chain each time they change hands in the other hash chain defeats the point.) |
|
|
|
Disagree, because there is no accurate mechanism today to predict the future value of a bitcoin. For example, if the DEA took down a major money transport network (not laundering) tomorrow, the demand for bitcoins could spike. The market would know this I feel, therefore nobody in their right mind would accept a long term contract that had bitcoins as the currency. That's the essence of the problem I see with bitcoin, it's for short term transactions only because of a lack of confidence in the future stability of the currency. I completely agree that until the behavior of bitcoins is reasonably predictable over at least the moderate term (3 years or so), they will not be useful for many of the applications of a currency because, if nothing else, prices will not be able to be stably denominated in bitcoins. But for those same reasons, the deflation won't do any harm. Businesses won't be dependent on loans denominated in bitcoins and so on anyway. Deflation has happened already. It was fueled ultimately by an increase in demand for bitcoins and a limited supply. I bet more towards the $5000 each statement. Right, but that was because of growth in popularity, not the deflation built into the bitcoin system. Bitcoins can't keep growing in popularity that way forever, you run out of people. So it's not a long-term threat to the viability of bitcoins. I only disagree if the claim is that the deflation built into bitcoins represents a reason bitcoins can't be used long-term as a viable currency. |
|
|
|
The ONLY time we will take funds from your account that you received from someone is if it is flat our blatant fraud on your end. If the user who sent you money is able to do an chargeback on the ACH they sent us that is on us. Awesome. So it sounds like TradeHill has nothing to worry about. But if anyone else is thinking "cool, a system where I can get payments with no chargebacks so my scam is good to go", they're going to get an unpleasant surprise. |
|
|
|
|
This seems to split an x16 slot into two x8 slots. It doesn't seem to a bridge but a splitter. Obviously, it won't work if you put it in a slot that's already wired for x8. But most chipsets should accept a split of an x16 slot to two x8's. The biggest issue I can see is that it might confuse the BIOS.
|
|
|
|
Regarding reversals - here is the exert from our terms of service regarding this.
(e) User acknowledges and accepts that in case of any Transaction disputes, Paxum presumes that all Transactions by User are authorized by and are the liability of the User;
(g) User agrees that all Transactions initiated are final and not reversible;
(i) User agrees that any disputes that arise between Users are not the responsibility of Paxum;
That doesn't answer the biggest question (and your full terms don't seem to either): If I receive a payment through Paxum, under what circumstances, if any, will Paxum want me to give them back the money? In other words, what happens to the recipient(s) if the transaction into Paxum is reversed? If Joe puts $1,500 into Paxum and then sends $1,500 to Jeff, and then Joe reverses the $1,500 payment to Paxum (claiming fraud or whatever), is that considered one of the "disputes that arise between Users" that Paxum takes no responsibility for? Or does Jeff keep the money and the dispute is between Joe and Paxum (since Joe breached rule 'e' above)? I get that you take greater authentication steps than Dwolla does and that there should therefore be less fraud. But the big question is still -- ultimately, if there is fraud or alleged fraud (and no wrongdoing on the part of the recipient), who eats the cost? |
|
|
|
Say Alice wants to send money to Bob. She types his bank account number and bank code into her bank's online banking website. And it's free. She has a regular account, so she pays somewhere around $5 per month for that and nothing per transaction. She could also opt for no monthly fee and $.25 per transaction, but since rent, utilities, insurance, groceries, etc. all goes through that account, she's better off with the former. So the transaction is free and it is non-reversible, once sent it can only be refunded by the payee. Sufficient funds are checked before the transfer is initiated by the bank.
Now when is this going to be a reality? Wow, this has been actually possible for the last 28 years! In a far away country called Germany. And even if you didn't own one of those fancy BTX terminals back in 1983, you could send money on a slip of paper, also free of charge or with a small fee. And what's a check (or cheque)? I've only once got one, in the late 1990s. It felt ancient. So, to be 100% clear, you are saying that if the system tells me that I received some money from Alice, there is no way for Alice to get that money back from me other than to sue me? It doesn't matter if she claims someone hacked into her account? It doesn't matter if she says I promised to ship her a product and never did? The transction is irreversible within the system even if she alleges fraud? If that's true, that's amazing. But I find that very hard to believe. |
|
|
|
Imagine that every individual had the means to protect themselves from any physical attack, kidnapping and therefore coercion. This seems, in theory, to be the ideal for a libertarian. No one would be able to harm you and you also could harm no other individual; no violent crime of any nature could occur.
However, consider for a moment what that would mean for property. There would be no physical means to preventing theft, and property would only be able to exist as an agreement (Don't steal any of my shit and I won't steal yours). Would this reduce property to a theoretical idea that would not actually exist in practice? I can't think of any practical scenario where every individual could defend themselves, even against all the other similarly-armed individuals acting together. Are you imagining a scenario where every individual has sufficient nuclear weapons to blow up the entire world? I don't think people would ever let such a situation happen because one crazy person would end human life. I can't imagine a scenario where every human is capable of defense such that no human is capable of offense. |
|
|
|
|
Show Posts
