|
It's almost new, bought 6 days ago... It has a character with a bit of play time, I think.
24 days of free play remaining plus 1 card for 1 month.
|
|
|
|
Create or copy a shortcut to bitcoin. Right click -> properties and in the target box, go to the end, add a space and -rescan so it looks like this: "C:\Program Files\Bitcoin\bitcoin-qt.exe" -rescan Run bitcoin once with that shortcut and then you can remove it. Note: I don't use windows so I don't know the exact path. |
|
|
|
|
Blockchain size was not a problem for almost 3 years. Satoshi dissapeared much before this. He didn't implement tree prunning because there was much more important issues to think about.
|
|
|
|
I still think you are underestimating the number of hashes that will need to be done, and how often.
Please enlighten me. Show me the numbers. You would still need to fetch the block body for any block involved in a transaction that you care about.
Only the transactions used as inputs, the merkle tree and MTUT verification hashes. Unless you want to validate those transactions too, in that case you need the full blockchain. It shouldn't be needed if implemented correctly. I see your objection that you would then have to trust a third party to do the search to make sure that the transaction hasn't already been spent, but that really isn't a big deal.
It is a big deal. Unless new users are encoruaged to download electrum before trying the official client. Let's change bitcoin.org, bitcoin.it, weusecoins, wikipedia, etc, to point to electrum instead of the full client. I mean, the idea of thin clients is great, but such functionality is not built in the official client because it somewhat defeats the purpose of decentralization (and it's a different protocol/API, etc). Why do you think Satoshi didn't choose to keep the entire current state present?
I don't understand the question. |
|
|
|
Double that, since the standard hashing that we do is highly optimized in ways that aren't useful for hashing a tree. But something that takes 6 minutes on a high end GPU is no longer a lightweight, or even middleweight client, since it will exclude 99.9% of all current nodes. And you are talking about something that every node must do.
By the time we have a 100 TB blockchain (I repeat: 100 TERABYTES), I'm sure you'll need much less than 6 minutes. And again, that's an operation for the whole tree. A single change only needs approx 11 hashes (in my 10 year example). This isn't a threat to the network, this is a threat to one node. Without the whole block chain, you can't add up the difficulty sum by tracing it all the way back to the genesis block.
You can, just the block headers is what you need (40 mb for 10 years of headers). Satoshi already thought of that. Read his paper again if unsure. Edit: s/10/100/g |
|
|
|
Interesting, but I see a couple of things.
1. All of the unspent transactions on the network since the beginning of time is a lot of hashing to have to do for every block.
2. You can't really trust the blockchain unless you've verified it all yourself. You are taking a big risk if you grab a recent block and just assume that it is good. There are ways to mitigate this risk to some extent, but the only way to eliminate it entirely is to do all of the math yourself.
1. It's 105120000000*2 hashes for the theorical 10 year period I've calculated. 6 minutes with a current GPU. It's almost nothing for a blockchain of almost 100 TB. According to this there are ~1.2 million of unspent transactions (2 months ago); let's assume we have 2 million, so we need about 4 million hashes (assuming the same number of tx per block). How much does need your GPU to hash that? Typical mining GPUs does it in 0.01 seconds. My CPU maybe a couple of seconds. Much less than the time it needs to check all ECDSA signatures. 2. If the majority of hashing power rejects blocks with an invalid MTUT, it's impossible for a block with 6 confirmations to be wrong. Even if you take a bogus MTUT, what are you risking? That a transaction you're doing is rejected? As a paranoid you would wait a transaction to have 6 confirmations anyway. Compare this solution with the current protocols for "thin" clients being in development (not one or two, but three!). MTUT doesn't require trusting a third party. The only issue with not downloading the whole chain is anonimity. |
|
|
|
Because it is NOT a feature that can be toggled on and off. We're talking of protocol-level changes.
Why does trust in the core devs seem to have evaporated out of a sudden?
I'm hearing newbie members with a dozen or so posts raise the BIP16/17 issue... that's straight laughable.
Did you actually read what I wrote? What I wrote is to implement the feature in such a way it's irreversibly enabled for everyone at the same time, only after the majority of hashing power supports it instead of a fixed date. Similarly as the feature I described in this proposal (which nobody reviewed or commented yet). edit: The trust in the core devs seems to have evaporated because there isn't a consensus between them. They should choose between 16 or 17 and we'll be in peace again. |
|
|
|
Why can't we just enable the feature automatically and permanently only after it's safe as I suggested here? |
|
|
|
This is a stressful war because they set hard dates again and again, rushing to tell miners when most of them aren't even aware of this (and some didn't see BIP 17 that replaces the CHC idea), or just don't care. Check out this soft schedule proposal. |
|
|
|
Why the hard dates?You both are struggling and rushing because the dates you set keep coming again and again, before miners notice and upgrade. Here's an alternate idea: - Have P2SH* implemented, and announce P2SH support in the coinbase, but it's disabled until a certain condition is met.
- The condition is to have 55% or more blocks in any 2016-block span announcing support for P2SH.
- When that condition is met, the remaining 45% hashing will have two weeks to update.
- Remove the P2SH announcement and just reject blocks with invalid P2SH transactions. Also the changes in the block limits will be made effective here.
- A future version of the software will remove the automatic switch logic.
* With P2SH I'm referring to both BIP 16 and 17. I have no preference for any of them if a soft schedule is chosen. Unless I'm entirely mistaken there was a rather nasty vulnerability in OP_EVAL caused by this added bit of complexity, one that BIP 16 would've inherited if you hadn't spotted and fixed it. While technically it was only a denial of service vulnerability that prevented nodes that supported it from mining any blocks, a denial of service vulnerability of this kind is enough to create transactions spending other people's bitcoins from their P2SH addresses and get non-upgraded nodes to accept them even after the switch-on date, which is kind of a big deal.
BIP 16 was made specifically to address this. All concerns expressed in this thread are solved IMHO with a soft schedule with an automatic 55% switchover, as long as clients honors the 6-confirmation convention.
|
|
|
|
|
For that reason it's better to have a "sweep funds" option instead of a "import private key".
Btw, what I said about the dates of saved transactions doesn't apply when you import a key with pywallet and use -rescan, as it records the date of the rescan instead. At least you would know which is the first transaction and look for the block it's located in.
|
|
|
|
|
Our bogus "last year" counter affect us on january...
|
|
|
|
|
Yep, that has been my motivation to write this proposal. But much worse than disk space is the problem of bandwith, specially in this P2P fashion. I've written this because is possible to have a fully functional and decentraliced client that just downloads a couple of megabytes to start working. If you read my proposal you'll see I've done the math as if bitcoin already had the volume of big payment processors.
|
|
|
|
Hello, I've written this proposal. C&P of the overview: Satoshi's original paper describes a way of prunning spent transactions in the blockchain to save storage space while it remains consistent and verifiable, but it's useless for partial blockchain downloads: while you can know if a given transaction is in the blockchain, you can't know if it has been spent in a subsequent transaction.
This proposal describes how to add a hash-tree based check in the blockchain that allows to verify if a transaction is unspent without downloading and checking all the blockchain. The idea is not new, but at the time of this writing there isn't any technical description of how this should be done. Aditionally, this solution is rather simple. Read the rest here: https://en.bitcoin.it/wiki/User:DiThi/MTUTCheers |
|
|
|
|
Don't forget the mybitcoin fiasco. Since then no one trusts an eWallet which stores your private keys unencrypted.
Also several wallets with lots of coins were stolen (with trojans, or from online backups, etc), as the official client didn't have wallet encryption at the time.
|
|
|
|
|
Yes, it saves all transactions for each address, so just check the date of the first transaction.
|
|
|
|
We should remove all dead links. Each of us should revise one section. |
|
|
|
|
It's from a friend who wants to sell it because it's a hardcore gamer and he thinks it's a bit too much like other games he played. I personally don't play any MMORPG. I need as much time as possible to develop my own games.
|
|
|
|
Yo uso https://bitmarket.eu/ directamente. Quien vaya y vea a alguien vendiendo y comprando con una banderita española, posiblemente sea yo. Hay una opción más rápida que la transferencia nacional, y es ir directamente al banco de quien te vende los bitcoin e ingresarle el dinero. |
|
|
|
|
Show Posts
