So before deciding to do ClearCoin, I was thinking I was going to clone one or more of the PayPal shopping cart / payment APIs. The advantage would that all of the existing shopping cart interfaces that know how to talk to PayPal would "just work" with bitcoins (the PayPal APIs can already deal with multiple currencies) -- just replace the https://api.paypal.com/ URL (or whatever it is) and specify amounts in BTC instead of USD or EUR. The short-term business model would be an E-Wallet for businesses (like PayPal). The medium/long-term business plan would be to get acquired by PayPal when PayPal decided they need to support bitcoin. If you don't like PayPal, then replace "PayPal" by "Google Checkout" or whatever other, popular payment processing gateway API is already being used by lots of websites. I still think this is a good idea, but I'm busy, so I'm throwing it out here and hoping somebody decides to do it. |
|
|
|
|
All this endless talking about the Perfect URI Scheme is very nice.
So is anybody, you know, actually working on IMPLEMENTING something?
You'll need to know how to write browser plugins for Firefox/Safari/Chrome/IE and figure out how to pass arguments to a running bitcoin/bitcoind and know how the bitcoin/bitcoind will prompt the user to confirm the transaction. Oh, and figure out how to get the browser plugin(s) installed when bitcoin is installed.
Deciding on whether it is bitcoin:address or bitcoin://amount/address is the easy part, and I think whoever actually does the work of making this happen should define the standard.
|
|
|
|
ClearCoin requires 3 confirmations before coins are available to be released; the sender will see something like: Received: 0 (20.00 still waiting for confirmation)
... while they're in the process of being confirmed. I'll change the receiver's status page so it shows the amount awaiting confirmation, too. |
|
|
|
One way to analyze these is via a threat model. What can the attacker do, that we will try to defend against? And what will we not defend against?
We can distinguish three levels of attacker:
1. Can read user files
2. Can read/write user files but only read system files
3. Can read/write everything, root privileges
I think that's the right way to think about it. And I think Jeff actually implementing a straw-man proposal is exactly the right thing to do. So: I say we don't try to defend against (3), at least not right now. If you have root then you can install a keylogger, read memory, intercept any system call, etc etc etc. (I would like to see somebody implement a bitcoin client that required payment verification using a cell phone app or telephone call or PIN-sent-to-email and did all the magic key management to make that work securely, but I think that's beyond the scope of what we can reasonably do right now). Defending against (1) and (2) would help with: a) you forget to logout so attacker sits down at your computer, starts bitcoin and empties your wallet. b) attacker gets a hold of a filesystem backup that is not encrypted. c) sysadmin sets file permissions incorrectly so attacker on multi-user system can read your wallet.dat d) attacker guesses or finds out your ssh password, logs in remotely and steals your wallet.dat. It won't help with: - sysadmin with root privileges is evil - system compromised by rootkit/trojan/keylogger RE: encrypt everything: I say maybe later. Just encrypt everything isn't trivial: users would have to wait a minute or two or ten for Berkeley DB to rewrite all of blkindex.dat (bottleneck will be disk I/O, not the encryption), and we have to deal with "my disk filled up when I changed my password, things are half-encrypted and half-not, what do I do now?" And I don't see a lot of value in encrypting all of wallet.dat; forget to shutdown bitcoin and an attacker that wants to know your public addresses can just open up the address book and take a screenshot. |
|
|
|
I'd assume they have rules and try to make them as clearly written as possible.
So one of my pet peeves is the United States Legal System. It has lots of rules. The problem is nobody can possibly read them all. And yet "ignorance of the law is no excuse!" I'm a big fan of a few general, fuzzy rules and common sense. |
|
|
|
Sirius runs the website.
... and we're looking for volunteers. See http://bitcointalk.org/index.php?topic=5052.0Quick "why no proper SSL cert" : because it never made it near the top of anybody's TODO list. The task is: + Figure out where the bitcoin.org domain is registered and make sure the MX records/etc are pointing somewhere so verification emails from the certificate authority don't get lost. + buy the cert and jump through the 'verify you are who you say you are' hoops. + replace the self-signed cert on the web server |
|
|
|
|
eideteker: Can you ask the skeptics what we, the Bitcoin Community, could do to be less "smelly" or "sketchy" ?
I find people are much more sympathetic if instead of saying "What's your problem?" you instead ask "What am I doing wrong, and how can I fix it?"
And then you can get all jujitsu on them and praise their great ideas and gently suggest that you'd only screw up whatever it is they are suggesting (and you're busy doing other stuff already) so maybe they should just go ahead and do it...
|
|
|
|
There needs to be some sort of awareness campaign to repair the perception people have to Bitcoin.
If only somebody would create a really nice animated video explaining what bitcoin is.... |
|
|
|
|
What theymos said. Miners have a strong incentive to be well-connected (as do big merchants and exchangers and anybody else who generates or processes lots of transactions).
|
|
|
|
Why did you put paytxfee=0.00 in your bitcoin.conf? Is it possible you had another value in the past?
... and also remember that command-line switches override values set in the bitcoin.conf file, so if you'd modified your Windows shortcut to -paytxfee that would stick. |
|
|
|
|
No, there is no 'mixed_debit' in my pull request. Coins are 'immature' until they have 120+ confirmations, then they are 'generate'.
|
|
|
|
|
RE: botnets: if the botnet operator is economically rational, then their best strategy to make money is to just follow the rules, mine coins, and then sell them on the exchanges.
RE: the original poster's question on "can somebody with lots of money and a willingness to spend it to mess with the bitcoin exchange rate and cause fear, uncertainty and doubt" :
Yes. Yes, they can. That will be true while the bitcoin economy is small, and that is why I tell people not to 'invest' money in bitcoins that they can't afford to lose.
I still predict that there will be natural price bubbles and artificial ponzi schemes and all sorts of other things causing wild swings in the value of bitcoins. Next time I talk to an economist who knows something about currency markets I'll have to ask how big a currency has to be before it is mostly immune from speculative bubbles and price manipulation...
|
|
|
|
If this backward incompatible change will have to be done one day, why not make it only once (by setting an automatic adjustment rule), and why not considering making it now, while it's still easy?
Patches welcome. But be aware that any patch that is vulnerable to denial-of-service attacks will be rejected, and I can't think of a way to automatically adjust the block size that wouldn't be vulnerable to some big, anti-social miner (think "jerk with a botnet") deciding it would be fun to artificially drive up transaction volume, drive up the block size, and create a few gigabytes of worthless blocks we all get to download forevermore. When we get close to bumping into the block size limitation it will be easy to convince a majority of the network to upgrade-- that's one problem that is obvious and easy to fix. |
|
|
|
Pull request: https://github.com/bitcoin/bitcoin/pull/138/filesFrom a testnet-in-a-box test, here's what mature/immature blocks look like: {
"account" : "",
"category" : "generate",
"amount" : 50.00000000,
"confirmations" : 120,
"txid" : "14da5ea78b6a1451ba11445be08c520808ddd185cf55d550f012dd4c16e2f67d",
"time" : 1300074965
},
{
"account" : "",
"category" : "immature",
"amount" : 50.00000000,
"confirmations" : 119,
"txid" : "8181f1760c208c84f06183f1145d3ad5a142340fd331e63466d5de8c406435aa",
"time" : 1300075032
},
PS: There is a feature in the core bitcoin code that bothers me because I don't completely understand it: coinbase transactions are technically spend-able after 100 confirmations (COINBASE_MATURITY in the code), but they aren't counted as spendable by the GUI or the RPC until 120+ confirmations (GetBlocksToMaturity() in the code). I suppose a big block-chain re-org could run into problems if a just-barely-mature generation was spent at exactly the wrong time, but I need to think about that a bit more (and maybe ping satoshi...). |
|
|
|
|
So... I'm working on a patch to add < COINBASE_MATURITY-confirmation generation transactions to standard listtransactions, and trying to figure out the right way to handle immature generation transactions.
Either:
a) list them as 'generate' -- they'll just happen to have confirmations < 100 (100 is the COINBASE_MATURITY, although the GUI doesn't show them until confirmations>= 120).
b) list them as 'immature' -- a new transaction category.
I'm leaning towards (b), because that way apps don't have to know that COINBASE_MATURITY is 100, and it is easier to double-check that listtransactions agrees with the getbalance API calls (immature coins are never counted in balances, because they can't be spent until they mature).
The only drawback I can think of is that adding a new transaction category might confuse existing code.
|
|
|
|
|
You can't see less-than-100-confirmation generations in listtransactions, but I agree, you should.
|
|
|
|
|
Does anybody have experience with valgrind -helgrind or other automated tools for finding potential deadlocks?
Running it on bitcoind I'm getting a huge number of false positives...
Should we just document every method that holds one or more locks? I'm worried there are other possible deadlocks lurking.
|
|
|
|
|
Show Posts
