This simple idea is obviously not new but no one tries to implement it. It is because the "COLD" cannot calculate the transaction fee without first knowing the full details of the inputs. You will need lots of qr codes to do this. If you omit this, a malicious or buggy "HOT" could trick the "COLD" to pay a huge amount of transaction fee. Learn more: https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki1. Modern operating systems on mobile phones like iOS and Android run apps in sandboxes. One app can hardly become malicious if the user has not rooted or jailbroke his device. 2. The hacker who do his best effort to get control over HOT can not benefit directly from his work. He can only give the miners more bitcoins but leave no extra income for himself. If a sandbox is so safe you don't even need a cold wallet. How about a bug in the HOT? And in your protocol you say "transaction fee" will be part of the QR code. You should realize that's completely pointless if you understand the bitcoin protocol. You make the users feel like they could endorse the amount tx fee while they actually couldn't. That's very misleading. This defeats the purpose of using cold wallet. Please do not develop snake oil bitcoin wallet which people will put their real money in. Unfortunately Satoshi did not consider this and we can't fix this without a fork. This has been discussed before: https://bitcointalk.org/index.php?topic=181734.0 |
|
|
|
Ah, it is built into the protocol/reference client? I had assumed it was something people had implemented on-top - but admit I have not looked into that in enough detail.
To me, it feels like the network would be more secure if every node was mining for themselves rather than forming pools - although I guess we would have less hashing power because the reward would be extremely rare for each node.
There is pros and cons, and is discussed many times already. As you noted, with the current model, people could still maintain a small scale mining farm in their garage. If pooled mining is forbidden, mining could be even more centralized. |
|
|
|
Anyone knows loaded's stance on bitcoin these days?
I know he had a shit load of coins, probably around 80k
Must feel pretty shitty to lose all that money when price is going down lol. unless he sold
He bought the majority of his coins WELL below these prices. 40K of them are still in one address, that I think he still owns, unless he sold them all at once 11 months ago before the bubble. https://blockchain.info/address/14j6jLececs66ZQ8ew6vTFNiEn2NupacWJHe only verified his ownership of the 40k in that address and if they're still in the same address then he must still own them. He was also managing another 160k for other people. Would be interesting to hear from him again He disappeared since mtgox's collapse, which "ruined his weekend". He did log-in once in June but said nothing. Actually, I suspect he's among us, posting with a different name. Anyway, I'd be nice to here from him again. Not for any investment advice, just want to know he's okay after the mtgox mess |
|
|
|
Enlighten me then, why is it that when PoS is taking over in Peercoin, and checkpointing is fading out at the same time? I can only form a logical conclusion of PoS don't need checkpointing from my observation.
You aren't addressing the cited flaws in the research paper. Here it is if you fear clicking on the link: What is wrong with this mechanism for consensus? On a high level, by tying our stake to (temporarily) sacrificed cryptographic resources, we are begging the question of consensus on who is in possession of what resources. Proof of stake advocates attempt to evade this accusation by pointing out that false histories can only be created by stakeholders, and their power is limited to a short interval of time (the time when they are the chosen signers) during which they are incentivized not to do so. Therefore conflicting histories simply will not appear, and we can appeal to synchronicity of the network to obtain consensus on the one existing history. The problem with this argument is simple: the “short interval of time” is only short as mea- sured by the consensus history, which only corresponds to a short interval in real time if there exists a consensus history. So we are still begging the question. In fact, if a stakeholder later
irreversibly sells his stake for some resource outside the system (e.g. at an exchange), he no
longer has incentive not to fork the history (or worse, expose his keys and let others fork the
history) at the point in consensus time when he had control.This is a bit abstruse. We can illustrate it with an example. Suppose that at some early point in consensus time, a single person has the ability to extend history. (For example, they have control over every key which a new block is required to be signed by.) This may have happened organically, if this person’s keys were chosen randomly by the stake-choosing algorithm, but it could also happen if this person tracks down the other keyholders and buys their keys. This may happen much later in consensus time (and real time), so there is no reason to believe these keyholders are still incentivized to keep their keys secret. Alternately, they may have revealed the keys through some honest mistake, the chances of which increase as time passes, backups are lost, etc. Now, we have a consensus history and an attacker who is able to fork it at some early time. To actually replace the entire consensus history, he needs to produce an alternate history, starting from his fork, which is longer than the existing history. But every block needs a new random selection of signers, so is this possible? The answer is absolutely yes: we have been using this word “random”, but in fact we have required consensus on the set of signers (otherwise forks would trivially happen), so even a random selection must be seeded from past consensus history. Therefore, an attacker with enough past signing keys can modify the history he has direct control over, causing future signer selections to always happen in his favour. (It is likely he needs to “grind” through many choices of block before he finds one which lets him keep control of the signer selection. In effect, he has replaced proof-of-stake with proof-of-work, but a centralized one.) Further, this ability to control the future selection of stakeholders (and even the set of stake-holders, by controlling which transactions appear in blocks) has serious consequences. This is because even without a deliberate attacker, the signers who extend the history at every point have an incentive to direct the history toward one in which they have more stake (and there- fore more reward), which causes the system to trend toward centralization. They may do this by skewing the stake selection of future blocks, or more insidiously by censoring transactions which (may eventually) increase the set of stakeholders. This is a great theory, but still doesn't explain why it haven't happened in reality. You can make up scenarios and theories all day of "what may happen", but when it doesn't actually happen in reality, you have to question your theory, not question reality. BS. They are all protected by centralized checkpoint. (And you KNOW that) |
|
|
|
I am not the best person to discuss the technical details here, but how do you explain PoW altcoins are easily 51% attacked to death. But then PoS altcoins all avoided this fate, and most of them (the non scammy ones), works and works well. Clearly when put in a equal competition (altcoins), the PoS system came out on top in an equal competitive environment (without early start advantage etc...).
I think we'll see non-clone coins being broken after two things happen: 1. They become valuable enough for attackers to bother, and there is some way for them to cash out. 2. The attackers have some time to do what they need to do to mount an attack-- write code, deploy botnets, hack into some big exchange(s), get their hands on some early-adopter's wallet backups, or whatever. Once the tools and techniques are developed, then I think we'll see what we see in PoW 51% attacks: attacks against even mostly-worthless clonecoins, because if they've already got the tools then they might just attack for the lulz. I'm surprised you count peercoin a PoS success-- they're still running with centralized checkpoints, aren't they? In peercoin 0.4 (current available version), yes still checkpoints. Though Sunny King has stated in 0.5 (future version coming out soon, hopefully), checkpoint will become optional and user can opt out checkpoints. Btw, at least 90% PoW altcoin use checkpoints too, otherwise they get instantly 51% attacked to death. Actually I think having checkpoints in Peercoin is due to the PoW part of the network. Since PoS is now taking over in Peercoin, producing majority of the blocks, checkpoints is no longer needed.You THINK? Please read and learn the basic knowledge on this topic before you think. I'm quite sure you didn't read the article I cited, or you simply don't care and just want to promote the coins that you have invested in. Enlighten me then, why is it that when PoS is taking over in Peercoin, and checkpointing is fading out at the same time? I can only form a logical conclusion of PoS don't need checkpointing from my observation. Btw, am I pumping Peercoin now? lol, I guess if you mention any altcoin in a discussion, you are pumping it... I have no fxxking connection with PPC's dev. How do I know their intention? You should ask them to provide a reason, not me. |
|
|
|
I am not the best person to discuss the technical details here, but how do you explain PoW altcoins are easily 51% attacked to death. But then PoS altcoins all avoided this fate, and most of them (the non scammy ones), works and works well. Clearly when put in a equal competition (altcoins), the PoS system came out on top in an equal competitive environment (without early start advantage etc...).
I think we'll see non-clone coins being broken after two things happen: 1. They become valuable enough for attackers to bother, and there is some way for them to cash out. 2. The attackers have some time to do what they need to do to mount an attack-- write code, deploy botnets, hack into some big exchange(s), get their hands on some early-adopter's wallet backups, or whatever. Once the tools and techniques are developed, then I think we'll see what we see in PoW 51% attacks: attacks against even mostly-worthless clonecoins, because if they've already got the tools then they might just attack for the lulz. I'm surprised you count peercoin a PoS success-- they're still running with centralized checkpoints, aren't they? In peercoin 0.4 (current available version), yes still checkpoints. Though Sunny King has stated in 0.5 (future version coming out soon, hopefully), checkpoint will become optional and user can opt out checkpoints. Btw, at least 90% PoW altcoin use checkpoints too, otherwise they get instantly 51% attacked to death. Actually I think having checkpoints in Peercoin is due to the PoW part of the network. Since PoS is now taking over in Peercoin, producing majority of the blocks, checkpoints is no longer needed.You THINK? Please read and learn the basic knowledge on this topic before you think. I'm quite sure you didn't read the article I cited, or you simply don't care and just want to promote the coins that you have invested in. |
|
|
|
Is there a rebuttal from the PoS crowd to this: https://download.wpsoftware.net/bitcoin/pos.pdf... other than "sure, the original PoS ideas were flawed, but the latest MegaUberPoS system gets it right and nobody has figured out exactly how to break it!" I am not the best person to discuss the technical details here, but how do you explain PoW altcoins are easily 51% attacked to death. But then PoS altcoins all avoided this fate, and most of them (the non scammy ones), works and works well. Clearly when put in a equal competition (altcoins), the PoS system came out on top in an equal competitive environment (without early start advantage etc...). Currently top 6 marketcap: 1. Bitcoin (early start) 2. Litecoin (early start) 3. Ripple (not PoW nor PoS, possibly a scam) 4. BitsharesX (PoS) (DPoS) 5. NxT (PoS) (possibly scam distribution) 6. Peercoin (PoS) (PoW initial distribution) The answer is here at section 6.4: https://download.wpsoftware.net/bitcoin/alts.pdf |
|
|
|
What is happening with Ripple ? it did almost 10% the last 24 hours and around 30% the last 7 days ?!!! Darkcoin also seem to be doing very well 20% in 24 hours...
A famous Chinese investor announces that he bought "some" XRP. Just an obvious pump-and-dump |
|
|
|
This simple idea is obviously not new but no one tries to implement it. It is because the "COLD" cannot calculate the transaction fee without first knowing the full details of the inputs. You will need lots of qr codes to do this. If you omit this, a malicious or buggy "HOT" could trick the "COLD" to pay a huge amount of transaction fee. Learn more: https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki |
|
|
|
|
ASIC are specialized in mining and mining only, i.e. looking for SHA256(SHA256) with many leading 0-bits. They are not used for general SHA256.
|
|
|
|
... in order to adhere to an abstract principle that not everyone agrees with or thinks about. Where the abstract principle you are talking about is address reuse. I don't consider this an "abstract" issue. Address reuse is the single largest internal threat to the long term viability of Bitcoin. It is the single largest threat that we can do something about within the Bitcoin community. Address reuse should be discouraged by any and all means possible. Companies, individuals, charities, etc. who continue to reuse addresses should be boycotted until they change their ways. Deterministic key pair generation should be used for all periodic payments, all donation addresses, all mining pool payouts, and all other times when multiple payments are made from one entity to another entity. Ideally all addresses would be used only once and contain only two transactions: a single funding transaction followed by an eventual single spending transaction. All change should go to a fresh address every time. I wish the protocol enforced these rules. If it were possible to make this change it is the only change to the protocol I personally would support at this time. Do you know the implication of your wish? That means miners and full nodes have to keep ALL transaction record FOREVER because they have to make sure the addresses in a new block have never been used before. . It just requires some extra work by the sender and receiver. I haven’t thought it through but it would be based on creating a new public key from another one similar to the way that HD wallets (BIP32) allow the SAFE derivation of child public keys from parent public keys. Let’s see: 1. The sender looks up the address he wants to send to. If it is unspent, he sends to it. 2. If it is spent (and remember we only spend ONCE. The full amount...) he can derive the public key from the spending transaction, call it Y. 3. He creates a new shared secret (Diffie Hellman) between his key and Y. 4. He uses the shared secret and Y to generate a new public key, Y’, for the recipient and calculates an address from it. 5. He sends to that new address. The recipient can check every transaction to see whether it is his: 1. He knows the sender’s public key (it was a spending transaction for the sender). 2. He calculates the shared secret. This allows him to recreate BOTH his new public key and his new private key. 3. He can spend the coins at a later time. In all of this, what’s important is that ONLY the sender and receiver know the shared secret. Also the shared secret is unique to each transaction by the assumption of only one spend, hence only one use of the transmitter’s public key. This is all a lot of work and probably could be made more efficient. Finally, if you don’t want people sending more than once to your address, publish a RECEIVING public key that remains constant long term. It is never sent-to but is used in generating all the shared secrets the senders will need. I am not sure what you mean by "enforce". If you mean "transactions with address re-use are invalid", I have already explained why it won't work. What you describe is essentially "stealth address". It facilitates no re-use but not enforces it. |
|
|
|
... in order to adhere to an abstract principle that not everyone agrees with or thinks about. Where the abstract principle you are talking about is address reuse. I don't consider this an "abstract" issue. Address reuse is the single largest internal threat to the long term viability of Bitcoin. It is the single largest threat that we can do something about within the Bitcoin community. Address reuse should be discouraged by any and all means possible. Companies, individuals, charities, etc. who continue to reuse addresses should be boycotted until they change their ways. Deterministic key pair generation should be used for all periodic payments, all donation addresses, all mining pool payouts, and all other times when multiple payments are made from one entity to another entity. Ideally all addresses would be used only once and contain only two transactions: a single funding transaction followed by an eventual single spending transaction. All change should go to a fresh address every time. I wish the protocol enforced these rules. If it were possible to make this change it is the only change to the protocol I personally would support at this time. Do you know the implication of your wish? That means miners and full nodes have to keep ALL transaction record FOREVER because they have to make sure the addresses in a new block have never been used before. |
|
|
|
I can see Bitshares eventually overtake Bitcoin.
You are not even accepting donation in Bitshares /thread |
|
|
|
it is an absolutely stupid idea to discard a private key.
That is an opinion, not a fact. My opinion differs from yours on that matter. And differs from Satoshi's, too: Oct. 3, 2010: Sigh… why delete a wallet instead of moving it aside and keeping the old copy just in case? You should never delete a wallet. source: https://bitcointalk.org/index.php?topic=1327.msg15136#msg15136 |
|
|
|
Isn't re-using the same address not regarded as questionable?
i.e not the recommended best practice?
Well it's not recommended as the best practice but I don't see anything dangerous in doing so. I think it's just a precautionary measure. I'm sure DannyHamilton will now tell me otherwise, though hehe. You mean because of this ? Do not re-use an address I've given you in the past. I use a new address for every transaction and I discard the private keys once I send/spend the bitcoins that I received at an address. Therefore it is very important that you get a new address from me and do not re-use an address to send bitcoins to me in the future if we ever engage in another transaction. Yes, it's a bad idea to re-use address, but it is an absolutely stupid idea to discard a private key. |
|
|
|
Sorry, I meant " I don't think it would become a real problem."
However, if someone with massive hashing power could push it over the boundary, then blocks would stop, and stop forever. The next difficulty adjustment will happen after 2160 blocks are found, which will never happen.
That's under this assumption of yours: Let say due to defect in SHA256 it is impossible to find a block if more than 160 leading 0-bits are required. I don't see any basis for the assumption? Why might there be a certain threshold? Just a pure academic discussion based on OP's idea |
|
|
|
Actually, I suspect that it would become a real problem.
Let's assume that it is impossible to have more than 100 leading 0-bits in an SHA-256 hash. When the target becomes 97 leading 0-bits, 1/8 of the eligible hashes are actually impossible. Therefore, the actual difficulty will become 1.14x of the apparent difficulty. 1.33x for 98 bits, 2x for 99 bits, 3.41x for 99.5 bits, 5.33x for 99.7bits, 14.93x for 99.9bits, etc. This will seriously hinder the growth of the apparent difficulty and we may never hit the boundary of 100 bits (unless someone with massive hashing power suddenly push it over the boundary).
Perhaps I am missing something, but didn't you just demonstrate why it might NOT be a problem? The actual difficulty would rise above the apparent difficulty, but the apparent difficulty would never rise to the point where a valid hash would be impossible, thus allowing the network to continue functioning. If someone with massive hashing power could push it over the boundary, then blocks would stop until the next difficulty adjustment after which mining blocks would resume. Am I right? Sorry, I meant " I don't think it would become a real problem." However, if someone with massive hashing power could push it over the boundary, then blocks would stop, and stop forever. The next difficulty adjustment will happen after 2160 blocks are found, which will never happen. Remember: difficulty adjustment happens every 2160 blocks, not every 2 weeks |
|
|
|
|
Actually, I don't think it would become a real problem.
Let's assume that it is impossible to have more than 100 leading 0-bits in an SHA-256 hash. When the target becomes 97 leading 0-bits, 1/8 of the eligible hashes are actually impossible. Therefore, the actual difficulty will become 1.14x of the apparent difficulty. 1.33x for 98 bits, 2x for 99 bits, 3.41x for 99.5 bits, 5.33x for 99.7bits, 14.93x for 99.9bits, etc. This will seriously hinder the growth of the apparent difficulty and we may never hit the boundary of 100 bits (unless someone with massive hashing power suddenly push it over the boundary).
|
|
|
|
I don't believe it would happen but if it does happen we have no choice but hardfork. To make sure existing ASIC will still work, we can change the requirement from HASH256(version|prev_block|merkle_root|timestamp|bits|nonce) < target to HASH256(version|prev_block|merkle_root|timestamp|bits|nonce) < target
AND
HASH256(HASH256(version|prev_block|merkle_root|timestamp|bits)|nonce) < target
Let say due to defect in SHA256 it is impossible to find a block if more than 160 leading 0-bits are required. With the new scheme, the target will become 80 leading 0-bits while the probability of success remains 1/2^160 (Currently, the lowest hash found is 80 leading 0-bits: https://bitcointalk.org/index.php?topic=29675.msg8131780#msg8131780) |
|
|
|
|
Show Posts
