Building the bitcoin chain in parallel and reversing all transactions from, say, last week would, for instance, cripple bitcoin exchanges if they would be required to refund the reversed purchases. And it can be done in a stealth way so the community cannot do any countermeasures until after it happens.
They can only invalidate transactions that they made (or further transactions that spend transactions that they made). That makes the attack a lot less likely in practice; if they had a lot of bitcoins, and purchased a lot of good or services (or exchanged them for dollars or euros) with a lot of people, then some of those people are likely to know WHO "they" are. And if they're in the same legal jurisdiction, it seems to me you'd have a pretty good case for suing them for fraud. Even if 'they' decided to do this just to try to mess up the bitcoin network it might be messy for the exchanges to clean up but I don't think it would cripple them. The bitcoin client already trys to select "old money" when it creates transactions, so assuming that the exchange has a good cushion of bitcoins on deposit all the attacker is likely to accomplish is to invalidate their own deposits at the exchange. All that said: I'm not going to advise people to hold money they can't afford to lose in bitcoins until the network has a lot more hashing power. There is still some risk while bitcoin is young. |
|
|
|
The bitcoin integration/testing source tree is at GitHub, and we (jgarzik/tcatm/gavinandresen right now) use GitHub's "pull request" feature to keep track of patches that people think are ready for integration into mainline bitcoin. This post is a walk-through of how to create a pull request. 1. You'll need a GitHub account; sign up for free, and set up git and ssh to work with GitHub. 2. You need a fork of the main bitcoin source tree. Login to your GitHub account, browse to the bitcoin project, then poke the little 'Fork' button near the top of the screen. 3. Connect that fork at GitHub with source code on your development machine. The easiest way to do that is to clone your github fork, using the SSH Read+Write URL github shows you on your fork's page. For example: git clone git@github.com:your_github_name/bitcoin-git.git
cd bitcoin-git
git checkout -b niftynewfeature # Create a feature branch
... edit, test, re-edit, re-test...
git commit -a
git push git@github.com:your_github_name/bitcoin.git niftynewfeature:niftynewfeature You might already have a clone of the bitcoin git tree that you've modified; you should push those changes into your new GitHub fork. Assuming you made your changes in the 'master' branch on your machine (next time you should create a specific feature branch), the command would be: git commit -a
git rebase -i remotes/origin/HEAD # optional: lets you tidy up commits to create a clean patch
git push git@github.com:your_github_name/bitcoin.git master:niftynewfeature 4. Submit a PULL request by going to your fork's GitHub page, selecting the branch containing the changes you want pulled ("niftynewfeature" in the above example), and then poking the "Pull Request" button. Enter a good description of what your changes do and why they're a good idea and how everybody and their brother is already using them to make the world a better place . Eventually, if all goes well, after discussion and argument and nit-picking and revision, your changes will get pulled into the bitcoin repository. If all doesn't go well, you (or the core developers) can close your pull request and resubmit it when the feature is perfect. |
|
|
|
Well, I'm guessing Gavin has access to the website server. Someone needs to turn that design into usable code first, though. That may be difficult or not so difficult depending on the CMS bitcoin.org is using, if any.
Sirius and I both have access to the webserver, although Sirius knows a lot more about Drupal than I do. But if somebody puts together Drupal templates (theme? what does Drupal call them/it?) with the spiffy new look I'd be happy to upload them. Or, even better, create a Drupal account for that somebody so they can update the look and content themself and fix the bugs that are almost certainly going to happen. |
|
|
|
I got this question from an editor at TechWorld.com.au : You are originally from Melbourne, and I noticed an Australian was prepared to trade a car for Bitcoins. Any other stories like that you can share? Any news on Bitcoin activity in Australia?
... and I'm looking for good answers. |
|
|
|
Actually, falling asleep last night I realized what I proposed would be yet another variation on an 'anybody can claim' transaction (anybody can just choose an r1 that make r1 XOR hash_xor_r1 evaluate to a hash that they own). I think this would work: OP_OVER OP_ADD OP_HASH160 <hash160(r1+public_key)> OP_EQUALVERIFY OP_CHECKSIG
... supply <scriptsig> <public_key> <r1> to claim. I'm not suggesting anything like this get implemented any time soon, I started this thread just to explore what is possible. |
|
|
|
Very nice! The 'sig opcount <= 2' rule for tx relaying is slated to change with the 'sendmany' patch I pulled on Monday. The new rule will be 'sig opcount <= size/34 // Checking ECDSA signatures is a CPU bottleneck, so to avoid denial-of-service
// attacks disallow transactions with more than one SigOp per 34 bytes.
// 34 bytes because a TxOut is:
// 20-byte address + 8 byte bitcoin amount + 5 bytes of ops + 1 byte script length
if (GetSigOpCount() > nSize / 34 || nSize < 100)
return error("AcceptToMemoryPool() : nonstandard transaction");
|
|
|
|
Can't you work out how many order and the value the merchant was getting just by looking in the block chain at the number and value of payments to the publicly posted "pay me" address? Surely there's no way around this other than the merchant using a new receiving address for every sale he makes?
Yeah... I can imagine clever ways of obfuscating it such that you can't tell who's getting paid until they actually sign the transaction and spend the output. Make the txout something like: OP_OVER OP_HASH160 OP_XOR <hash160_xor_r1> OP_EQUALVERIFY OP_CHECKSIG
... and to spend the txin is: <scriptsig> <public_key> <r1> (where r1 is a random number used to obfuscate the publicly visible hash160). Or something like that (I shouldn't be thinking about cryptography when I'm this tired). |
|
|
|
|
Thanks for the link to the wikipedia page in the other thread... so receiver CAN recover 'k' given the public key and signature.
Cool!
That doesn't solve the problem I'd like to solve (because you still need to generate a new keypair for every transaction), but it is cool.
|
|
|
|
You CAN encode a message in a currently accepted transaction using the broadband subliminal channel inherent to DSA (and ECDSA).
Googling for 'ECDSA broadband subliminal channel' to figure out what the heck you're talking about... ... doesn't that require that the recipient (as well as the sender) know the private key? (you encode the message in the 'k' param, which the recipient can only recover using the private key?) |
|
|
|
|
It depends on how much you pay for electricity, what kind of computer you own (and what kind of graphics card it has), and whether or not you can figure out how to install and run "GPU mining" software.
|
|
|
|
If order IDs are put in transactions the next most common question will become "so how do I stop my competitors finding out my sales volume?".
Right, that was the problem I was hoping to brainstorm about. I didn't want to re-open the "add data to the transaction database" discussion (I think "add data to the block chain" is misleading, since transaction data isn't actually part of the block-header-chain or transaction-merkle-tree). I'm still wondering if there is a way to create transactions on the web server, without talking to bitcoind, using a small-ish number of pregenerated public keys, such that each transaction is unique and competitors can't tell how many transactions belong to any particular merchant. Pre-generating a bunch of keys works, assuming that competitors don't know the pre-generated keys (bad assumption long-term if they keys are re-used, since they could just order a bunch of stuff and note the keys used for paying). |
|
|
|
|
RE: opening up the "store random stuff in the block chain" argument:
Several things make me not worried about that:
1. OP_CHECKSIG drives network-wide costs (see the thread on network-wide transaction cost back-of-the-envelope calculations).
2. New -limitefreerelay code will, I'm pretty confident, mitigate penny-flooding.
3. 512 bytes plus inputs plus outputs will will make these either "very-low-priority-free" or over 1K non-free transactions.
4. We're past the point where block chain download size is 'convenient' for new users. We should implement lightweight client mode (download only block headers until you start solo mining) as soon as possible.
RE: pregenerate a bunch of addresses to use for payment:
I like that idea! If you're getting, say, 20 bitcoin orders a day then 1,000 addresses would last you a month. And even if you recycled them when you ran out it should be easy to match orders to addresses based on the transaction date and amount...
The whole "click to pay" feature needs to be figured out, and should work nicely in all four cases of (customer,merchant) using (bitcoin,online wallet). My brain isn't up to it today, though...
|
|
|
|
It is more complicated to implement but what about signing the order id with the bitcoin private key and sending that. It could be easily checked on the server side, but this is a larger question of do we really want to use the bitcoin private keys for other signing?
The web server doesn't have the bitcoin private key, and the problem I'm trying to solve is an order process where the web server doesn't have to communicate with bitcoin at all to generate the "pay me" address/link. |
|
|
|
|
So I got email today from a merchant asking the most-frequently-asked question: if I just put a bitcoin address on my "pay me" page, how do I know who paid me?
Which got me to wondering... can we do better than answer "run a bitcoin daemon and ask it for a new address for every order" or "use a shopping cart interface from your online wallet provider" ?
Ideally, the web software could generate a payment URI without talking to bitcoind, and copying/pasting or clicking on the URI would generate a transaction tagged with the right order ID.
Adding another transaction type that allows (say) an extra, arbitrary 512 bytes of data mostly solves the problem; the web software could encrypt or hash the order ID and generate a transaction that is the store's public bitcoin address and the encrypted/hashed order ID (or customer number or whatever).
Can we do better? It would be nice if it was impossible to tell how many orders the merchant was getting...
|
|
|
|
Focusing on the use cases is the right approach. 4. Export selected keys for transferring their funds to someone else; the recipient imports the keys and gains access to the funds.
Any others?
One variation: 5. Export keys to transfer funds to somebody else. Recipient is expected to import and then immediately send-to-self. Sender keeps the keys 'set aside' in the wallet until they are spent by recipient, or, if not spent by recipient (lost in transit maybe, or recipient chokes on a lollipop before having a chance to redeem), may be added back into the sender's balance. And one usability comment: Is "selected keys" the right way to go? Just selecting an amount of bitcoins to export/send seems like a better way to go (with a send-to-self transaction generated, if necessary, to create the right amount), with maybe an "advanced" option later that lets you select specific inputs to export/send. |
|
|
|
So every bitcoin connection must use asymmetric cryptography and conform a so-called normal distribution. Or else everyone will be statistically detected and...
Preventing that type of statistical network analysis attack is what Tor and i2p are for. If you require that level of anonymity, run bitcoin via a proxy to communicate over those networks. |
|
|
|
I'd suggest using a standard, existing format instead of inventing a new one. Either get rid of the version number and do standard CSV: 91iwnurxhWmDF9gqwc4CbuLCB4HxuMXf5B2vEhTPDftY3rkMgDY,10806,moura6ybHvwzMtrWdyqiEN6n2mMakf8HxD,"50.01 BTC"
92JsNVMJgG4RiC2ARxpduJp8DXKgdDMj9WREE5jo66Hg8UMdr3L,10870,mmFPR1oaDExBfJqpRohWBvbE2aCg86Kwcx,"0.00 BTC"
... etc (always 4 columns)
Or maybe .ini-format, with each private key a different section: version=1
[91iwnurxhWmDF9gqwc4CbuLCB4HxuMXf5B2vEhTPDftY3rkMgDY]
block=10806
publickey=moura6ybHvwzMtrWdyqiEN6n2mMakf8HxD
amount=50.01
[92JsNVMJgG4RiC2ARxpduJp8DXKgdDMj9WREE5jo66Hg8UMdr3L]
block=10870
... etc
(bitcoin already contains .ini-file-parsing code, from boost) I think there are lots of advantages to using an already-standard file format. |
|
|
|
PHP 5.3.3. on my mac gives: object(stdClass)#1 (1) {
["e"]=>
float(5.01)
}
Please be specific about what platform you're running on, what version of PHP are you running, are you running with a standard php.ini or have you tweaked it, etc. |
|
|
|
It does not work that way .. printf("%.8f") behaviour is inconsistent across platform. If you don't believe, try -- some platform give -999.03, some give -999.04. I tried it... got -999.04 on my Mac and Linux machines. What platform gives the wrong answer? |
|
|
|
As far as getting started, I'd like to see a sticky walking through the steps to create a pull request. But yeah, you can check out from sourceforge using svn, get your changes working, and post the output of svn diff as a patch.
Sticky for creating a pull request: good idea. JollyGreen: if you know, or are willing to learn, git then working from the git repo ( https://github.com/bitcoin/bitcoin )is smoother. github has built-in support for turning a development branch into a pull request. |
|
|
|
|
Show Posts
