Some comparisons: Hardfork is making some invalid transactions valid Softfork is making some valid transactions invalid Hardfork requires the consensus of vast majority of miners, users, and merchants Softfork requires the consensus of vast majority of miners, but not necessarily non-mining users and merchants Hardfork can change any rules in the protocol or implement any new rules Softfork is usually less powerful (with a trick which I call "Aux block", a softfork could also be very powerful: https://bitcointalk.org/index.php?topic=283746.0) |
|
|
|
The analysis you cite is flawed for 2 reasons: 1. It conveniently ignores the first bubble to $32. 2. If that analysis was performed in early 2012, it would totally miss the bubble to $266 and $1200. 3. During the bubbles, bitcoin was neither linear nor exponential. It was parabolic. But in very long term, the exponential model still gives the best fit. The R-square for linear and exponential model are 0.537 and 0.888 respectively. This thread is for people with long-term interest in bitcoin. Not for day traders. By long-term I mean at least 2 years of patience. i am not sure why the numerical coefficient in your formula keeps changing. this change means that you simply adjust the formula to better fit the data-am I correct or is this change automatic? Just like any technical analysis, the estimates will (of course!) change every day with latest information. |
|
|
|
The analysis you cite is flawed for 3 reasons: 1. It conveniently ignores the first bubble to $32. 2. If that analysis was performed in early 2012, it would totally miss the bubble to $266 and $1200. 3. During the bubbles, bitcoin was neither linear nor exponential. It was parabolic. But in very long term, the exponential model still gives the best fit. The R-square for linear and exponential model are 0.537 and 0.888 respectively. This thread is for people with long-term interest in bitcoin. Not for day traders. By long-term I mean at least 2 years of patience. |
|
|
|
Just discovered this thread, fantastic analysis. Thought I might as well share my long term chart here too. https://www.tradingview.com/x/NGW8Bhkn/If the slope of the trendlines are still holding it looks like price might be at best bargain since 2010 before the first MtGox bubble! Thats only 'IF' trend holds. Interesting line to keep an eye on though. Looking forward to the next bull run! My analysis is a bit different from traditional trendline analysis, as I won't use information in the future to explain the price action in the past. |
|
|
|
wow ... 7 billion people on this planet ... this is the major forum for bitcoin ... and this is the major thread for ongoing price discussion ... and nobody even bothers to post in several hours ... silence speaks volumes ... nobody cares anymore ... the only involved people left are the fanatics ... everyone else is back to living in the real world ...
There are only a few million individuals that are part of bitcoin. a million people using bitcoin out of the global population is 0.000142857 % ... according to my math ... do explain how that counts as a mass adopted global currency ... Your math fails. |
|
|
|
|
update. nothing interesting since last update
|
|
|
|
以前在美国没有比特币交易的监管，所以开办交易所是非法的，也是在美国本土一直没有交易所的原因。
美國不是天朝, 法律沒禁止的行為都是合法. 美國本土一直沒交易所是因為涉及美元匯款需要在每一經營的州份取得牌照, 連聯邦牌照一共是51個, 沒有風投根本不能負擔. 以前难道是非法的？
當然是是. 標題非常誤導, 完全是天朝思維解讀美國政策, Bitcoin交易在美國從來都是合法. |
|
|
|
Why couldn't 2FA be decentralized and integrated into the bitcoin infrastructure? It's already proven that bitcoin is transparent and traceable.
Exactly! "2FA" like Yubikey or Google Authenticator or SMS passcode couldn't be decentralized and integrated into the bitcoin infrastructure BECAUSE bitcoin is transparent. You don't really understand what you are proposing, unless you are talking about something else like multi-sig transaction. |
|
|
|
Is there any added benefit to using SHA256d over SHA256 in Bitcoin?
Maybe satoshi wanted to exclude the chance that there is a SHA256 ASIC in some drawer. The probability for the existence of a single chip piping through two SHA256s was less likely, so the "one CPU one vote" was more likely at the bootstrap of the currency. Good point but this still can't explain the use of SHA256d in the calculation of Merkle Tree and transaction ID, etc. |
|
|
|
One case that isn't covered is if you authored a chain of private-key-destroyed timelocked transactions using invalid encodings. You can fix-up the signature in the first transaction, but doing so changes its txid and thus invalidates its dependents. Of course, if you did this you were already likely to get burned even absent any further change: anyone in the network could mutate your transaction (and with the invalid encoding, all the network would already ignore it and take the mutant instead) and invalidate the child equally well. There already appear to be some parties that mutate any invalid encodings they observe to valid ones. Chiming in to say I agree with jl2012's proposal to have the implementation only enforced on UTXOs after a certain block height. Even though it's not wise, and even though it's suicidal, and even though other people can already mutate the signatures, I very strongly think it's a bad precedent to set to invalidate a tx somebody made that was valid at the time they created it, and we should do everything in our power to keep the ability to spend that nlocked tx. The core principle of Bitcoin is "a valid tx is a valid tx". No matter how unlikely or irresponsible it is, and no matter that other people can already mutate it anyway, we should at least TRY to preserve the ability to have a tx that was valid at the time it was made stay valid, and have those child tx's also be valid if possible. A valid tx is a valid tx. For the reason given by gmaxwell I'd retract my proposal |
|
|
|
I do think we have obligations to all bitcoin users, to keep the promise in the original bitcoin protocol. OK, you have obligations. I do not have. Who will be majority with 51% - wins the game. Otherwise, in order to pump the price we may just declare all of Satoshi's early coins are invalid, for example. We can do it. And we can recover lost coins https://bitcointalk.org/index.php?topic=50206Just vote with 51% of hashing power for hard-fork. (BTW, this will not pump price  ) You're wrong. To create a hard-fork you don't need 51%, not even 1% of hashing power. All alt-coins are hardforks of bitcoin |
|
|
|
The transaction used a non-compliant signature but won't get confirmed until 2020. The private key was lost. Enforcing this rule will burn the locked bitcoin. 1) Isn't it possible to convert non-canonical signature to canonical leaving transaction valid? (Transaction not in block) (Right now I do not think about the transactions which redeem outputs from the tx with non-canonical signature) [/quote] I'm not quite aware of the details of the proposed fork. If this is the case I think it's fine. 2) https://en.wikipedia.org/wiki/Omnipotence_paradoxWe can not create algorithm/rule/law which can not be changed by our children Just do not think about minority and time-locking transactions. You have no obligations either to early adopter or to his children I do think we have obligations to all bitcoin users, to keep the promise in the original bitcoin protocol. Otherwise, in order to pump the price we may just declare all of Satoshi's early coins are invalid, for example. |
|
|
|
You are technically correct. But imagine this: now over 95% of hashing power decide to support the mega-block fork. People sticking to the original fork will have a block every 200 minutes and next adjustment will be in 280 days. So the original fork is essentially dead
Well, if they do I'm sure someone will jump on the original fork and get coins at low cost when the difficulty readjusts. The original fork is already worthless after 280 days of stall. At the same time the remaining 5% miners will keep leaving and an adjustment may never happen. All major exchange and merchants will only accept the mega-block fork. |
|
|
|
Is there any cons worth discussing ? I only see the pros.
Let's consider this:
A bitcoin early adopter signed a time-locked transaction for his heir before he died. He believed that bitcoin would become really big and didn't want his heir spent it early. The transaction used a non-compliant signature but won't get confirmed until 2020. The private key was lost. Enforcing this rule will burn the locked bitcoin.
A possible solution is to enforce this rule only for new UTXO after a certain block height. For old UTXO, we will still follow the existing rules.
Am I just too paranoid?This is not a problem because the signature could be fixed by malleability |
|
|
|
"Core developers" (whoever that creatures are) cannot do anything with the protocol without a majority of the miners supporting it.
This is true for a softfork (a change where new blocks are acceptable to old software, like BIP16, BIP30 and BIP34 were). For a hardfork (like increasing the block size limit), which is changing the rules that all full nodes already validate, you need to get those full node to agree with the upgrade, or they will not accept the change. Whether miners agree with that is not specifically relevant: the network will ignore the old miners anyway. One way of looking at it is saying that it's the network deciding which rules they believe the system should enforce (by choosing to run software that implements those rules). Miners are just clients to the network, who create blocks satisfying the rules the network wants, and are paid for that. Miners can choose to enforce stricter rules than what is demanded by the network, however. You are technically correct. But imagine this: now over 95% of hashing power decide to support the mega-block fork. People sticking to the original fork will have a block every 200 minutes and next adjustment will be in 280 days. So the original fork is essentially dead |
|
|
|
Please don't bump old threads, especially not to propose something new. You can always link to the old thread in a new post. I would strongly recommend against it. If Bitcoin were to deploy a new signature system we'd likely prefer schnorr signatures to pick up efficient multisignature; there are other approaches which much more size reduction (E.g. BLS pairing signatures are half the size); and there are other considerations. I always think bitcoin should support more signature systems and hash algorithms, with different key size. Low value outputs could be protected by a single small key, while high value outputs for long-term storage could be protected by multisig with different signature systems. |
|
|
|
For a decentralized system like Bitcoin, the IO is much more expensive than the CPU. One byte of extra data means transferring to and storing on all nodes. So saving the data storage is very important to Bitcoin.
In the transaction structure of Bitcoin, if removing the public key part in the transaction data, we may save nearly 30% of storage. The cost is we have to check the previous output to check the signature. But still it is worth to do the trim, cause the 30% data saving. (the blockchain data may be decreased from 30GB to 20GB)
Is it possible to do that?
It is technically possible with a fork, but that will cause a much bigger problem. In current design, a node can forget all spent outputs. Also, a node can forget scriptSig after verification, and store the UTXO only. If a new transaction may refer to the information in the historical blockchain, nodes have to store the whole blockchain forever. Satoshi has already addressed this problem in the section 7 of his white paper: https://bitcoin.org/bitcoin.pdf . Please read before you propose a new "solution". -------------------- Alternatively, it is possible to calculate the public key with only the signature and the signed message. The trade-off is spending more CPU time. Read more: https://bitcointalk.org/index.php?topic=6430.0http://www.secg.org/sec1-v2.pdf section 4.1.6 I think we are talking about the full node implementatioin, not SPV And for full nodes, the storage is much more expensive than CPU. Thanks  The section 7 of Satoshi's paper is NOT about SPV |
|
|
|
|
Reviving this thread.
With all the discussion in blocksize fork, could we consider to implement this public-key-free signature? It will save about 15% space for a standard 226 bytes 1-input-2-outputs transaction.
Roughly speaking, CPU speed and network speed doubles every 18 and 21 months respectively. Therefore, it makes sense to shift the burden from the network to CPU. Also, it is always possible to fall back to the traditional signature verification.
|
|
|
|
|
Show Posts
