|
I'd like to bet on Bitcoin difficulty and dollar trading price, 6 and 12 months in the future.
|
|
|
|
See this analysis by [mike] looking at similar transaction loads and what that would mean for mining servers: http://bitcointalk.org/index.php?topic=2454.msg34469#msg34469Mike astutely identifies the bottleneck as the CPU power to verify transaction signatures. I've been doing some profiling and over 90% of the CPU time of the (non-generating) client is spent in ECDSA_verify. There are plans for lightweight clients that would not download blocks, just headers. Then they would be sent details of transactions involving them. Only the big iron would keep the block chain. |
|
|
|
|
You could tear your banknotes into 5 pieces and hide them separately. As long as you can recover at least 3 pieces you should be able to exchange them for fresh bills.
|
|
|
|
|
How many dots on that map? I lost count.
|
|
|
|
|
I'd like to learn to play poker. Would this be a good place?
|
|
|
|
I agree this can be a problem. Putting in a transaction fee won't help if the next block happens to take an hour to generate. I suggested a technical solution to reduce variability: http://bitcointalk.org/index.php?topic=2968.0We might also consider shortening the ten minute target interval. Making it five minutes would greatly reduce the chance of a long wait. |
|
|
|
|
How about counting the number of people in #bitcoin? That should include almost everyone who's running the client at that moment. I'd like to see stats on how this number is changing.
|
|
|
|
|
This is how I understand transaction fees to work:
- the client offers a fee by creating a tx with a "surplus", ie. the input amount is greater than the output amount
- when a miner creates a block he can create a transaction paying himself up to 50 btc plus the sum of all the tx fees in the block
The miner doesn't have to pay himself that much but the tx fees are lost anyway.
|
|
|
|
I recently moved [to a maximum security prison] and I can't connect to peers with Bitcoin or bittorrent with my new internet. I recently moved [to a home for the insane] and I can't connect to peers with Bitcoin or bittorrent with my new internet. I recently moved [to a college dorm that disallows P2P] and I can't connect to peers with Bitcoin or bittorrent with my new internet. Context is important. |
|
|
|
Almost everyone had transactions from "united". It does NOT mean that your account was compromised. It does mean that the attacker has your username. It was just them using the merchant API to send you 0 BTC.
Does this mean the merchant API has/had a way of discovering account names? And this involved sending a dummy transaction of 0 to each account? Has this been fixed? |
|
|
|
|
I wouldn't be surprised if in 30-50 years they were able to genetically engineer some sea organism to extract gold from seawater and concentrate it in their shell, as they do with calcium and other elements now. I think Bruce is right, in the long run gold is doomed as a source of value.
|
|
|
|
|
Suppose you receive a payment and then immediately spend it. Then there is a block reorganization and the payment to you goes away. It never comes back because it was a double spend. Can the client handle this? How would it appear in the transaction window?
|
|
|
|
Walking the block chain means you don't have to store much data at all. In fact, you only need to store the block locator, a series of block headers that thin out exponentially from the head of the chain. I was planning on having the app download a signed copy of the latest block locator from my own server the first time it runs rather than doing a getheaders walk, as a performance optimization (you already have to trust the author of your wallet software).
What do you mean by walking the block chain? Could you clarify what you would do when you receive a block containing a payment transaction to one of your addresses? Do you need to go back and look at old blocks? Or can you just assume it's valid because it's in a block, possibly waiting for some confirmations, in which case maybe you don't need to save old blocks at all. |
|
|
|
None of the pictures have been showing up at http://bitcoinme.com for a few weeks now. I PM'd Bruce about it a while back but no change. |
|
|
|
|
Ultimately it's good for the network for mining to be expensive. It makes it that much harder for a well financed attacker to dominate the network.
|
|
|
|
I listen to the network (via http://bitcointalk.org/index.php?topic=2808.0), and while transactions generally come pretty randomly, there is occasionally a cluster of a dozen or so transactions, coming very quickly, within a second or two. It took me a while to realize that when these happen, it is always the top of the hour. I don't notice them every hour, but several times a day, always on the hour. Looking at blockexplorer, it looks like these are a series of small payments, a few cents or a few bitcoins, generally from high value transactions near 50 btc. And they each normally have a 0.01 btc transaction fee. An interesting pattern... |
|
|
|
|
Signatures are DER encoded in Bitcoin, and your signature above is in the same format. 30 is a sequence of values, in this case the two ECDSA components, called r and s. 46 is the length of the sequence. Then 02 means integer, 21 is the length, followed by 0x21 bytes which is the r value. Then there's another 02 and length for the s value. If the high bit of r or s is set, they get 00 prepended so it's clear they're positive. Bitcoin sigs have exactly the same format as you can see in any blockexplorer.com dump.
|
|
|
|
|
Well my attempt to verify that sig in openssl failed, it didn't verify. That's no surprise since the two methods also disagreed about the validity of the bitcoin sig. I hoped I'd see something wrong in the data structures, but I didn't. Your pubkey is a valid EC point on the secp256k1 curve. The signature appears to be properly formatted.
I'll see if I can think of anything else...
|
|
|
|
Several people have mentioned they are working on mobile clients (at least Android, don't know about iOS). But I haven't seen much discussion of the design in terms of security and performance issues. In another thread, http://bitcointalk.org/index.php?topic=2957.msg41905#msg41905, [mike] made a provocative comment: "1) Are you trying to make an Android client? You don't want to verify transactions if so." Can mobile clients get away without verifying transactions? Maybe they could just rely on the block chain. Any transaction in a block that has enough confirmations is considered to be good. Checking blocks is both easy and quick, pretty much just hashing. The one problem I see would be a possible delay in knowing that payments to you are valid. It wouldn't matter for payments to merchants who can run regular clients, but payments from one mobile user to another might be slow to be validated. Another possible shortcut would be for mobile clients not to forward blocks, transactions, and addresses the way regular clients do. Network transmissions draw a lot of power. Mobile nodes could just leech. If they don't process transactions, they wouldn't even need to read those. iOS doesn't have true multitasking. I don't think a client could receive the block chain in the background. Android presumably doesn't have this problem, but the question would be impact on battery life to keep the client running all the time. |
|
|
|
|
Show Posts
