BTW nlocktime isn't supported yet. Maybe in the future.
Yes it is. See the two IsFinal() functions in main.h, and the many calls to them in main.h, main.cpp, rpcwallet.cpp, wallet.h and wallet.cpp. What isn't implemented is transaction replacement. |
|
|
|
|
You are quite correct that there is no timestamp available that you can call the timestamp of a transaction.
Bitcoin defines the order in which transactions happen, but does not record when* they happen. If your application depends on timestamps, you'd better rethink it.
* The block timestamp can, at very best, tell you that the transaction existed prior to some time in the rough vicinity of the block timestamp. But this is a wrinkle in the system. Block timestamps are only used to prevent people from cheating the block rate (and thus the difficulty [and thus the subsidy]).
|
|
|
|
In Bitcoin-Qt you can adjust the keypool size to better match your usage and backup patterns. This is— in my opinion— too much to ask of many users, so I'm not defending it as a good setup, but it's perhaps not quite as bad as you're thinking.
A simple change would be that the client wouldn't silently extend the key pool. If you try to send money and the keypool is exhausted, the client informs you that the transaction cannot be processed. The user would have to manually extend they keypool along with a warning to make a new backup immediately.Deterministic wallets which don't support public generation would protect against a fundamental break of elliptic curve maths. That system doesn't seem to be in use anywhere. I much prefer linking the keypool extension to the backup process. As in, the backupwallet RPC command extends the keypool, then does the backup, and there would be no other way to generate new keys. But it probably won't happen because we are moving away from unrelated keys. (FYI, I'm one of those people that dislikes HD keys, but I fully support changing to them because they are safer for 99% of the people to use.) |
|
|
|
|
You can set a lock time, but it isn't as cool as you'd like.
The network won't remember your locked transaction for you, so you have to give them the raw transaction to be broadcast in the future. Oh, and unless you delete the keys, you can always double spend it away during the lock time.
|
|
|
|
See, that is exactly what I'm talking about. People like Bill Gates, Sergey Brin, Steve Jobs, and others like them didn't have jobs, or capital to live off of, yet they live pretty damn well. Capitalism is not finding an employer and hoping he will give you a job. That's the sad brainwashing that you and many others were convinced of. Capitalism is creating wealth and trading it with others. If you can't find employers to give you a job, you be the employer. Sure, it's not easy, and is much more difficult to figure out than just having someone else tell you what to do and give you money for it, but it is way better than starving to death.
I think you understand that people like Steve Jobs and Bill Gates are 0.000001% of the population, other will never repeat their success! For the remaining 99.999999% only one option to not to starve will be fighting, and they no doubt will fight if the economic model won't be adapted to post-labor era! Those are just examples that can be quickly and easily used because they are famous, and they are famous because they are rich. Do you know my mechanic, Bard? He started out with nothing, now owns his own shop. He's modestly rich by most standards, but he makes a lousy example on the internet because you have never heard of him. There is a huge spectrum between starving in the streets and Bill Gates. To get off of one end, you don't need to make it all the way to the other end. Most of the middle is very nice. |
|
|
|
All types of flash memory are a bad idea for long term storage. They discharge over time.
Discharged sd cards? Never heard about it! SD cards are the safest digital storage, much more reliable than CDs or DVDs. But better create an additional paper wallet from your private key, then you're completely covered. They need power every once in a while Get these http://www.newegg.com/Product/Product.aspx?Item=N82E16800995117You're right about the sd cards, only last a few years... did'nt know that!  M-Disks are great or you could take this: http://www.sandisk.com/products/usb/memory-vault/Paper is still king. Stored properly in a cheap firesafe, paper will survive a house fire. I also use M-disc, but I don't trust them yet. The concept seems very solid. The drives suck, I think I've got a 50% failure rate on the LG drives (of about 40 installed) in the first year, but that doesn't seem to be a problem for media lifetime. I also have a few media that have appear to have spontaneously grown what appears to be a thick dust layer despite storage in Tyvek sleeves, but they still read fine. I have no idea about that memory vault. I note that the linked website doesn't give any indication of what it really is, or how it works. Appears to be just flash memory plus marketing. Assuming that they've solved the discharge problem (and I see no reason to believe that they have), you still have the problem that flash drives sometimes just die a sudden and mysterious death. Or am I the only one that occasionally plugs in a USB stick only to find that it has turned itself into a brick since the last time I used it? |
|
|
|
|
SE?
Any other errors popping up in /var/log/* ?
What is your walletnotify= line in your .conf?
|
|
|
|
Messages are not transactions. Messages are verified by checking ECDSA on the message hash, which is very simple. Transactions are verified by executing the two script halves, which is not so simple. https://en.bitcoin.it/wiki/OP_CHECKSIG |
|
|
|
You are wrong, this is just a proprietory service by blockchain. info. Messages are not part of the bitcoin protocol.
Thanks for correcting me. Is there any way we may mark a transaction with a text in Bitcoin protocol so that the receiver can identify the sender if there are multiple claimants to be sender ? Bitcoin is different. You should not attempt to recreate obsolete systems in bitcoin. Bitcoin has no sender. You should not use this concept in your system. If you need to identify someone, do it up front, before providing the payment address. Then your problem is merely watching the address and checking the amount received. |
|
|
|
In five years, the CD's and DVD's you burned may be corrupt. Optical discs' quality isn't what it used to be. Of course, this varies from manufacturer to manufacturer. If you want to digitally store data, the most future-proof way would probably be to use multiple good quality SD cards.
All types of flash memory are a bad idea for long term storage. They discharge over time. |
|
|
|
|
It is hard to beat paper for this application.
|
|
|
|
|
Yeah, the wallet doesn't work the way you think it should. You need to learn how it actually does work rather than wishing someone else would change it.
|
|
|
|
But does it actually reduce the value? You could run the bitcoin network of 1 bitcoin, you would just have to keep making it smaller denominations. Likewise if you just 'lose' coins surely you get to a point where you just make it a smaller demoniation and the end state hasn't changed?
I don't foresee adding the lost coins back in, in 100? years time making a significant difference? if it was put to a vote? everyone agreed. Would it really affect the price? especially if you limited the amount of coins that could be bought back in per block?
If it doesn't do anything, then why do you want to do it? |
|
|
|
As I understand it, the block reward cannot be spent right away. There have to be a certain number of blocks built upon it, 6?, before it can be spent.
100 by protocol. 120 by convention. |
|
|
|
|
The short answer is "no".
The long answer is "How do you measure 3 of {M,V,P,Q} quickly and accurately enough to set the fourth?"
|
|
|
|
Sigh - OK so what you are telling me is that the function in p2pool is flawed and not as specified on the p2pool.info web site.
The hash rate of the pool is simply the accepted difficulty of all the shares over a given period of time divided by that time.
The shorter the time frame, the more unreliable it is i.e. the greater the variance.
The way bitcoin works is it does indeed do what you are suggesting - however it does it over a set of data that is consistent - a set of blocks that have the same difficulty requirement.
Doing it over a set of data that isn't consistent, is, well, saying it's done incorrectly.
Maybe that is part of the reason why it jumps all over the place like crap.
What you are implying is that indeed it has nothing to do with the p2pool hash rate, but rather a set of shares with somewhat random difficulty.
I will also point out that your wording is vague and missing a detail:
The difficulty of the share submitted is only the difficulty that it was requested at, not the actual difficulty of the share itself.
All shares on all pools have varying difficulty, but it is only the difficulty of the work request that can affect anything on any pool payment scheme other than PoT
Edit: this also means the payout scheme could be flawed.
Yes, you should always read difficulty in this discussion as "difficulty of target" rather than "highest difficulty that target could have been and still been satisfied by this block". My apologies for thinking that detail was obvious enough to warrant ommission. I can't really imagine what makes you think that doing something other than the way you think it should be done makes it "wrong". Hubris much? Bitcoin uses long stretches of blocks with static target, and very strict rules for changing that target. Those rules were chosen based on the needs of bitcoin. p2pool has different needs. The rules that make sense for bitcoin do not make sense for p2pool, so p2pool has not blindly copied them. For example, in bitcoin, a large hashing attacker could profit by whipping the difficulty up and down, so we have strict rules about when and how difficulty can change which mitigate those attacks. No such profit is to be had in p2pool. In p2pool, when a block is found, the last N shares are paid out, each share based on that share's fraction of the total. The total is easy to find. The fraction of the total embedded in each share is easy to find. I'm not sure what is "incorrect" about any of this. |
|
|
|
Do you understand that this option is protocol specification change? It effectively forks blockchain.
Heh. This is the sort of nonsense I was talking about. This is local control. You, the node operator, have options. Hardly a new thing. Since day 1, all node operators have had the ability to fork for whatever reason and through whatever means they desire. You have a warped view of "decentralized". It doesn't mean that no one has any authority, it means that no one can stop you. Who can stop you from turning checkpoints off? No one. Who can stop you from stripping them out of the source entirely and running your own pure node? No one. |
|
|
|
|
Show Posts
