|
I was in Vienna 3 days ago. If only I had known about this...
|
|
|
|
|
I think the confusion comes from what you understand under "miner".
Originally, it meant a bitcoind node that ran generation routines. After time, the generation code was split off to specialized programs that communicate with bitcoind using getwork. After time, that bitcoind became hidden behind a pool interface, and the only thing miners did was connect somewhere to request a candidate block, and check nonces.
However, when you're mining using p2pool, you need to run that bitcoind yourself. The fact that miners do verify transactions before putting them in a block is essential to the bitcoin system. You risk creating a block that will not be accepted by other nodes.
|
|
|
|
|
Wthout the full blockchain database, you cannot verify whether incoming blocks are valid. As a miner, it is exactly your task to do that.
If you'd use a more lightweight bitcoin node, you would potentially create blocks which contain invalid transactions, which would cause your generated blocks to be stale.
|
|
|
|
|
Recent versions of bitcoind also report this information via the gettransaction RPC call.
|
|
|
|
|
It seems you have transactions in your wallet that conflict wih others in the blockchain (i.e., attempted double spends). Have you sent transactions from an instance that used a copy of the wallet.dat as well as from an instance running the original? That could explain the behaviour.
The only solution for now is removing those transactions from your wallet. I suppose tools like pywallet can do this, or manual tinkering using the bdb tools to dump/remove/load the wallet file.
There are plans for adding logic to the wallet for detecting transactions that conflict with the blockchain, and at least temporarily disable them, and eventually delete them if the transactions that they conflict with are buried too deep in the chain.
|
|
|
|
The number one advantage of IPv6 over IPv4 is the much larger address space. To quote Vint Cerf, one of the "fathers of the internet", a few weeks ago: The other thing that is very important for the last decade or so, is the introduction of mobile technology. There are 5.5 billion or so mobiles in use today; not all of them are internet-capable, but probably 20% to 25% are, and over time that percentage will go up. The reason that's important, is that for many people their first introduction to the internet comes through a mobile as opposed to a desktop or a laptop or an iPad. For many it will stay that way, and for others: they will begin to accumulate other devices that they will use in addition to their mobiles. But that adds a huge demand for address space on the network, because if every mobile that is internet-enabled has to have an IP address assigned, eventually you start to run out of IP addresses. And in fact, that's what we're faced with today.
We chose a 32-bit address space in 1973, in order to carry out an experiment. And I want to emphasize that this was an experiment. What I though was that if the experiment succeeded, then we would design a production version of the system. Well the problem is that the experiment never ended, and so we're still using the experimental internet which only has 4.3 billion terminations built into its design. So in 1996 in a great panic, we developed, and here "we" in this case is not Bob (Kahn) and me but rather the IETF, developed an alternative packet format called IPv6. It has 128 bits of address space and if you do the math that's 3.4*10^38 addresses. This is a number only the (?) can appreciate. We are now in the process of introducing in parallel with IPv4 the IPv6 formats. So on june 8th last year (2011), many of us in the internet community turned on the IPv6 capabilities that we had in addition to IPv4. On june 6th this year, all of us are going to turn on IPv6 and leave it on. So this is a very important year for the internet because IPv6 will be launched on june 6th. Google and many other have been preparing for this for several years and we're all looking forward to seeing what happens when we turn it on and leave it on permanently.
On a more practical note: bcause of IPv6 much larger address space, addresses are much cheaper, and typical home internet connections are intended to provide many - enough to give each household device its own public address (though firewalled) without needing atrocities like NAT (creating a separate independent local network, and translate addresses between them) and UPnP to overcome it. |
|
|
|
They can keep track of income per public address you create, but only the balance of the entire wallet that matters to you if you are looking at the wallet abstraction (i.e., the amount you're able to spend). Maybe not. Maybe we have different addresses in a single wallet with btc coming from different sources and we want to keep them divided, and don't mix them. That's certainly useful sometimes and very educational. It's also planned to be included in the client. But it doesn't fit in the wallet abstraction provided by the client. Breaking that abstraction would confuse people who only want to use it, and do not care about the internal functioning. It's something for an expert mode, and belongs in what I call micro-management. Certainly people will want this, but it doesn't fit in what the client currently provides (the abstraction that it represents a wallet with money in). |
|
|
|
|
The long answer:
Assume the entire current bitcoin hashing power switches to mining addresses. Assume it consists of all GPU's. Assume a GPU doing EC math can produce 1 address per 10 bitcoin hashes. This results in roughly 1 TAddr/s (tera address per second). This results in about 3*10^19 addresses per year.
Assume all bitcoins are mined and in circulation, and perfectly distributed and thus there are 21M addresses that each hold 1BTC. This is equivalent to saying that one in 7*10^40 addresses is interesting.
This means that each year of mining by the entire network would result in a chance of 1 in 2*10^21 for finding *at least* one interesting address. This means that after about 1.5*10^21 years (120000000000 times the age of the universe), there is a chance of around 50% of having hit one.
In other words: never.
|
|
|
|
1) There are 2^160 = 1461501637330902918203684832716283019655932542976 valid normal addresses. 2) In januari, there had about 3 million addresses been used, with 123000 holding a >1BTC balance. 3) never |
|
|
|
|
The core issue here is that the abstractions provided by the wallet and what you can see on blockchain explorers differs.
Wallets manage a set of keys, and a set of unspent coins available for those keys to spend. They can keep track of income per public address you create, but only the balance of the entire wallet that matters to you if you are looking at the wallet abstraction (i.e., the amount you're able to spend).
Internally, wallet create change addresses, and coins can be assigned to either public or change keys in the wallet. Blockchain explorer can however not see the entire wallet, they only see the individual addresses.
I think that when people want to know "the balance of an address", they really want the balance of a wallet, but have learnt to observe this through the only publically observable piece of information available: the individual addresses in it. The real solution is using watch-only deterministic wallets here, in my opinion (being worked on ...). That allows you to keep working in the wallet abstraction, without needing to be bothered with individual addresses and keys.
The alternative is using a lower-level wallet abstraction, where you micro-manage all keys and addresses yourself. There are certainly useful applications for this (for example satoshidice uses the specific input coins you sent them in your payouts, so they don't take a risk allowing low numbers of confirmations). This way of working is currently not supported in the reference client. There are plans to include this functionality, but it will only be the preferred solution for particular instances in my opinion. That said, it can be very educational.
|
|
|
|
|
That would require an index from each address to all blocks/transactions that spend to or from it. Since this is not required for normal operations, and quite expensive, it is not (yet?) implemented in the reference client.
|
|
|
|
|
First of all, which bitcoin version is this?
Second, what error do you get before the crash? (look on the command-line, in debug.log, ...)
If the wallet file is corrupted at the BDB level, you can try using db4.8_dump | db4.8_load in recovery mode.
|
|
|
|
Seems decent, except for the "public key cryptography 101" box: analogy with a pair of keys is confusing and wrong. My favorite explanation is the one I stumbled upon on this forum (not sure if Netrin came up with it or he adopted it) -
Yeah. Here's a magical analogy for public key cryptography: I generate a private key and numerous public unlocked treasure chests. I give these open treasure chests to all of my friends (it's easy to copy them). Whenever a friend wants to send me a message, they just put the message in my public treasure chest and close the lid. Now even they can not open it again. Only I, with my unique private key, can open the chest.
After I generated the public keys, I don't really need them any more, unless I want to send messages to myself. But no one needs the private key to lock a message. The private key is only required to open a message.
I don't see anything that is technically incorrect about the PKI explanation in the graphic. Do you care to explain what is wrong with it? netrin's quote is cool for the noobs, but it doesn't mean that what is in the graphic is incorrect at all. Both quotes are very correct and explained differently. It's also not really relevant, as it describes public-key encryption (which isn't used in bitcoin) instead of signing. |
|
|
|
|
You cannot disassemble the script address without knowing the script. That's both an advantage and a disadvantage.
It means people do need to be told what keys are involved in a transaction, they can send a payment with just the script address. On the other hand, spending from a script address implies knowing the script.
|
|
|
|
|
And the attacker will just run the custom hashing executable.
|
|
|
|
|
He doesn't need to understand them - he can just execute them.
|
|
|
|
|
Show Posts
