what blocks are 90% empty and there is a back log?
Essentially all. None of the last 100 blocks were larger than 400KB. Only 5 were larger than 300KB. The vast majority are 100KB to 250KB. More than 20 are <100KB. The block size limit is 1MB. why are miners creating a back log when they have plenty of space. why not include all the TX's if there is space for them? A large block would increase the odds of being orphaned, so they don't really have incentive to include zero-fee or low-fee transactions. |
|
|
|
|
In addition to coinbase, is it allowed to add inputs in the reward transaction? I think the answer is no but just want to confirm. If this was allowed, we may have something like a CoinJoin mining pool
|
|
|
|
Simple version: blocks are 90% empty, tx wait longer to be included in a block
Pay 0.0001XBT fee, or 0.04USD, will solve the problem |
|
|
|
Money stuck in exchanges keeps the Bitcoin price artificially high. If Mt.Gox ever processes all withdrawals, more people will convert to fiat to get their money out. So prepare for a price drop when they do.
Right, I heard this since June when the price was only 1/5 of the present  |
|
|
|
Difficulty increased and some miners dropped |
|
|
|
|
沒有經過同行評審 (Peer review), 誰知道你所寫的是否真的安全?
|
|
|
|
Anyway, it is not possible to derive the public key and the address without using using a computer
It is quite possible to do this with pen and paper. I don't know the ripdem algorithm, but the sha and key multiplication could be done in a few hours of concentrated work(and a few hours on the next day to check). Nothing you want to do, but otherwise, if you can't trust any of your hardware, it could be the ultima ratio. Before doing the calculation you may want to wrap the room and your head with tinfoil  |
|
|
|
It might be even better to allow users to define the value of insane fee. IMO 1BTC is too high. |
|
|
|
Initially I thought the OP suggestion was bad, but now I think it is good with your comment. This is exactly the reason for us to make it non-standard. Since bitcoind won't broadcast non-standard transactions, we could avoid it locally by making them non-standard
Do you often kill flys with hammers? Bitcoin git was changed so that sendrawtransaction wouldn't emit txn with insane fees without an explicit override flag more than a month ago. This requires nothing about changing relay rules and avoids adversely impacting other parties. Really? I don't notice there is a change but I think this is exactly what I'm proposing |
|
|
|
You know, since the OP talked about lack of experience in programming, there is a simplified method that works with just bitaddress.org
Roll the dice 100 times. Write down the sequence.
Example:
3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224
Then you use that as the brain wallet passphrase in bitaddress.org
Uncompressed
1JGHFyjsnyQHnW29ygv19Qz4p2WRQAqwcs
5KjcaDDnmNhSWG33bt6rQ9LeJyfE2mjrrGPbqbFwJj6ruPnHw2v
And if you want the compressed version, just copy the private key to the wallet details tab.
Compressed
12WQuVvxwbVz17NLjgUJJgwsw5BhgAbqkA
L5h61awSzrmVa9N2UxYq39ohgM5iWpUB2SvkmUCvhEpsFrDLCTVL
Easy. Works. Can not be brute forced. Make sure to roll the dice properly (roll it from far away and make it bounce against the other side.)
I approve of the "generate a shitload of entropy and hash it" method. The reason I recommended my method is because it could be done with pen&paper, without any external functions. You can actually get a full hex private key without touching any external scripts or figuring out how to securely/privately execute hashes. Can be useful in some situations for people with nil programming experience. But I also wasn't aware that many tools will do the hashing for you. Anyway, it is not possible to derive the public key and the address without using using a computer |
|
|
|
Mistakes can be avoided totally locally,
Initially I thought the OP suggestion was bad, but now I think it is good with your comment. This is exactly the reason for us to make it non-standard. Since bitcoind won't broadcast non-standard transactions, we could avoid it locally by making them non-standard its preferable to do things locally because it doesn't constrain what other people can do.
Agreed. We may have separate non-standard criteria: one for broadcasting, one for relaying, one for mining. Most of the time the rules are the same, but we may prohibit the broadcast of some transactions, such as having >0.1BTC miners fee. The rest of the network would still relay and mine these transactions |
|
|
|
It's weaker in the sense that it increases the possibility miners might try and change the rules of the system, like by changing the inflation schedule. We need as many people with economic heft (especially merchants) to validate all the rules, to make them harder to change.
It's weaker in a few other ways too, but the above is the main one.
It is trivial for a merchant to run several copies of bitcoind at different locations with cheap internet connection and storage (e.g. at home), and force his bitcoinj (on a server with very limited bandwidth and storage) to connect to the trusted bitcoind. By the way, the one you mentioned is well known (but I think it's mostly an academic issue as many non-miner, such as early adopter, would have enough incentive to run a full node.) I would like to learn what are the other ways. |
|
|
|
I'm just speculating that most of the information is still there, that maybe only a few bits are wrong, or that something is bit-shifted, or whatever (again, not an expert). It seems much, much less computationally intensive to try to repair the key than crack a wallet blind.
The first few entire sectors of the drive are unreadable. Shit, sorry man. Some kind of nasty hardware failure? I'd have thought the recovery guys could extract the data. Yep, physically unreadable, even with cleanroom work. I've accepted the loss... If I really needed coins, it would be alot easier to hire someone to go beat the stolen ones out of pirateat40. At this point I'm just holding onto the 5k I have left with an iron fist. Would you mind publishing the address(es)? So I can add them to my provably lost bitcoin list: https://docs.google.com/a/ij.hk/spreadsheet/ccc?key=0Ahdy3Je_nYdOdFVocm4yTzhZOW1waWd6SFJIVHUwYUE&usp=drive_web#gid=0 |
|
|
|
But, you get weaker security.
How much weaker (with SPV)? I think this is only weaker in academic sense, especially for low value transactions (relative to block reward) |
|
|
|
BTW, I am running a full bitcoind on a 80USD ARM baord: http://cubieboard.org/ without any problem. So are we facing a big problem? I would say not yet Besides, this mini-PC uses flash disk right? The max flash card size is 32GB right? If so, you will not be able to run bitcoind there soon because out of disk space. It supports SATA and USB hard drive so this is not a concern at all |
|
|
|
lets get to the bottom line here, it is not about BetCoin failure, we all agree on that, the whole thing is about someone holding 24% of the network hash power and using this position with bad attention. I'm not sure it's that simple. BetCoin Dice is currently* a DDoS attack against Bitcoin. GHash.IO's actions here could be construed as a kind of self-defence. * BetCoin has indicated they will correct this problem eventually. I am not going to defend the BetCoin's behavior in any way (starting from copying SD's site nearly byte-by-byte). But the much more appropriate self-defence against blockchain flooding, IMHO, would be to tweak the bitcoind just to drop the transactions related to the BetCoin's addresses off the mempool, not to cheat them as a response. Accepting big-value zero-fee zero-confirmation transaction is stupid. They deserve it. |
|
|
|
so nodes will have an option to store full chain or only its part? So SPV client like MultiBit is what you need Do you read me? SERVER SOFTWARE So that's for your online casino? SPV mode should be good enough. I think even SatoshiDice is running on SPV mode with BitcoinJ |
|
|
|
|
Show Posts
