|
I'm building a supernode database with 0.93.99.1. Do I need to do it again when 0.94 is finalized and officially released?
|
|
|
|
|
來這裏的水平都比較高. 在這裏吹牛不但沒有宣傳效果, 更只會被恥笑
|
|
|
|
If the majority of nodes agree that for all blocks after block #N (e.g. 400000) the only valid block must contain only the coinbase transaction with zero block reward, and with a alt-block hash attached to the coinbase message, where the alt-block hash is the hash of the block in blockchain 2.0 (transmitted separately), then it is technically only a soft fork because the set of valid blocks accepted by new nodes is a strict subset of that accepted by old nodes. The old nodes will be forced to accept a perma-frozen blockchain where no new coins are generated and no transactions will confirm.
You are right but this is quite obvious and not a new idea |
|
|
|
手动打开了8333端口，有大约20-30个连接  要打開了8333才算真正完整節點. 我的有超過100個連接 |
|
|
|
已经连续无间断运行6个月。见图  今天一看，40g服务器硬盘只剩下1.5g了，明年要是区块上限提高到20m，个人运行一个完整节点成本将提高。 你的設置有問題, 防火牆沒打開8333端口, 所以只能有8個連接, 而且不能有輸入連接 |
|
|
|
以下文章翻譯自 http://gavinandresen.ninja/block-size-and-miner-fees-again . 為了令中文讀者及非技術人員能容易理解, 在不破壞原意下翻譯可能會有改動. 原作者: Gavin Andresen 中文翻譯: XBT.HK 版權: Public Domain 公有領域 ----------------------------------------------------- 我經常看到這個要保留 1MB 區塊容量限制的論點: 保留 1MB 區塊容量限制會增加交易之間的競爭, 令礦工得到更多交易費, 因此令網絡更安全 為此我曾撰寫區塊容量的經濟學 https://blog.bitcoinfoundation.org/blocksize-economics/ 一文, 更邀請了真正的經濟學家評審. 但在此我會以另一角度討論. 礦工的 Bitcoin 收入可以表達為: 其中區塊獎勵由最初每區塊50BTC, 約每4年減半一次. 現在是每區塊25BTC, 於2016年中會下降為12.5BTC. 而平均交易費, 則是進行交易時用戶決定向礦工付出的交易費. 然而現在更多礦工關心的是以法幣 (不論是美元, 歐元, 或人民幣) 計算的收入, 所以應表達如下: (區塊獎勵 + 交易數量 x 平均交易費) x 兌換率 如果隨著區塊獎勵下降, 而交易數量或平均交易費的增長又不足以彌補, 那恐怕礦工就會退出, 令網絡變得不安全, 也令攻擊網絡的成本下降. 但我們不應只著眼於平均交易費, 其實交易數量同樣重要. 如果我們的目標是要把方程中 (交易數量 x 平均交易費) 這部份最大化, 我們需要先知道交易的需求價格彈性, 才能計算出令礦工賺取最大收入的區塊容量上限. 而事實上在可見的將來, 兌換率是更重要的一項. 因此如果我們希望在未來10至15年保證網絡的安全, 就應集中做可以令兌換率上升的事情. 而增加區塊容量可以令更多人使用 Bitcoin, 容許更多更安全的多重簽名交易, 容納更多對區塊鏈的創新應用, 這些正是可以令 Bitcoin 的價格上升的因素. ---------------------------- 以上文章同步發佈在 http://blog.xbt.hk/ |
|
|
|
|
Updated with new format of reporting
|
|
|
|
今后也许会出现专业的比特币公司，把现在的比特币做成像银行卡一样，大家把比特币交给专业的公司保管，而自己不用为比特币的安全而担心。易用性与安全性是不可兼得的，只能娶一个平衡。
大家把比特币交给专业的公司保管，還需要用什麼比特幣? 到中國銀行用人民幣就可以了 |
|
|
|
what has higher chances of finding a block?
Same assuming consistent difficulty In perfect world this would be true. But if you do all in a day, your risk is greater as it's not spread out over the 10 day's assuming dealing with pool with luck and same difficulty. But with 10 day's you are actually spreading out you chance of finding block. So less possibility of a bad streak ruining profits. You can have the average luck based on 10 day's instead off 1. So same ... yes. But if doing one day you are betting a lot of you having good luck with that rental. This is Gambler's fallacy |
|
|
|
既然比特幣選擇了去中心化，那麼交易不可逆也就是必然的結果。既然選擇了POW的挖礦方式來保證去中心化，那麼非即時交易也是必然的結果。任何想在現有的協議上做到可逆交易或即時交易都是瞎折騰。
我相信現在的比特幣網絡已經非常成熟，真正缺少的是類似Apple這樣把用戶體驗做到極致的公司來為比特幣推廣到真正普通人那裡。
從沒聽說過有人投訴鈔票交易不可逆, 但Bitcoin不可逆就罪大惡極了 爬手偷了你的錢包, 劫匪搶了你的手錶, 也來個交易逆轉好不好? |
|
|
|
what has higher chances of finding a block?
Same assuming consistent difficulty |
|
|
|
[This is quite new. No spoilers please] A clip for you all, turn on speaker Background: When: 9 May 2015 Where: Guizhou, China Who: 80 cops What: Rehearsal for the "Chinese Dream" event https://www.youtube.com/watch?v=5TdARfnvSDg |
|
|
|
不可逆是比特币的独特性，不可否认，很多人就是喜欢这种不能反悔的技术。但，如果从安全的角度来说，比特币的防护意识和对黑客的惩处手段也能配合到位的话，这样才能真正的让普通大众也能去应用它了，否则，比特币的使用人群还是会很有限的。
不是什麼獨特不獨特的問題, 也不是喜不喜歡的問題, 而是從沒有人能提出任何可行而有實際意義的方法讓交易逆轉 |
|
|
|
After thinking more carefully, the updated proposal with softfork bears a huge risk when the length of the UTXO digest is not enough. Consider an attacker can mine the following message: 36bytes nonce|2100000000000000|attacker's pk_script|any height in the past As long as the result matches ANY existing digest in the UTXO set, the attacker will generate 21M bitcoin for himself as there is no other way for UTXO-lite nodes to detect it. This is a birthday attack and is much easier than mining for a particular digest. Whether the real UTXO has 1 satoshi or 1M bitcoin is irrelevant. If there is still any legacy nodes, there will be a hard-fork. Therefore, the digest has to be long enough, with 20 or even 32 bytes. But even with 32 bytes I think it might not be as secure as the current model, as I can't see a practical way to generate 21M bitcoin even if I am able to find a SHA256D collision under the current model. Interestingly, your original proposal with node-specific-salt does not have this problem as it is not a consensus rule and the salt ensures that a collision may affect only a few node |
|
|
|
|
I know I sound rude and I'm sorry if anyone feel offended. I am really pissed off when I learn someone lose bitcoin again due to this problem. This is so 2011. It simply should not happen in 2015 because most wallets now have deterministic backup
Fixing Bitcoin Core is like fixing the International Space Station on the orbit. I know most devs are not paid and they have different priority. Improving the Core wallet is probably not the highest priority, which I agree, since we already have so many alternative wallets. But since the security level of Core wallet has not improved for years, it is not up to the 2015 standard. I mean native cold storage support (I know one can do it with some ugly hack) and deterministic backup.
For lay users, however, many of them still start with Bitcoin Core. They believe the Core wallet is the best one just because it is the reference client. They simply don't understand the risk of the lack of deterministic backup, until they lose money.
Actually I think we should still keep the wallet in Core, but disable it by default. Only advanced users, who really understand what they are doing, should use the Core wallet. Lay users should be directed to something else like Armory or Electrum.
|
|
|
|
|
Do you mean we will all have a Bitcoin ASIC in our cell phone?
|
|
|
|
I created a draft BIP for extended transactions. Transactions just point to the transaction outputs that they are spending. No additional information included. This means that the UTXO database of every node has to store the information about the UTXO (value, scriptPubKey and height). An extended transaction is the same as a normal transaction, except that this information is included. It is purely for information purposes. The original transaction format is used for signing and the txid. The advantage is that only the wallet which owns the coin needs to actually store the information about the UTXO. If they want to spend the coin(s), they can create an extended transaction message and broadcast it. Each UTXO entry could be 8 bytes instead of the current average of 36 bytes at the moment. Full nodes already contain the entire UTXO set. If they receive a standard transaction, they can add the extra information to make the extended transaction. Future nodes, which use the reduced UTXO set size, wouldn't be able to process legacy transactions. This would give 3 types of node. - Legacy nodes
- Border nodes
- UTXO-lite nodes
UTXO-lite nodes would only make outgoing connections from legacy nodes, since they can't process their transactions. I am undecided if new message names are the way to go. If each peer is required to either use blocks/txs or eblocks/etxs, then it is a waste making them different. I like this idea but it implicitly contradicts with BIP30 ( https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki) and has a remote risk of hardfork, in theory. As UTXO-lite nodes will not store the index of not-fully-spent txid, they are unable to check whether the txid of new tx is same as any existing not-fully-spent tx. If a collision happens, legacy nodes and UTXO-lite nodes will disagree with the validity of the new tx and lead to hardfork. Of course, as we already have BIP34, a collision like this means a successful preimage attack against SHA256D. Therefore, I'm not sure if this should be considered as really risky. And if we could ignore the theoretical risk, I'd suggest to formally enact your BIP as a soft-fork. Instead of 8 bytes as you suggested, use 10 or 12 bytes. Similar to BIP34, a new consensus rule will require that new tx must not have an UTXO-lite identifier same as an existing unspent UTXO. If there is a collision, miners will just include the tx to the next block, which will change the tx's UTXO-lite identifier. Also, no node_specific_salt is needed and all UTXO-lite nodes will share the same UTXO-lite index. We may even commit the hash of the UTXO-lite set to the blockchain. |
|
|
|
I created a draft BIP relating to etx and eblock messages. If a protocol version number was used, then a new block message name is not strictly required. The updates to the reference client may not be that difficult. Transactions could be stored internally in the new format and translated when sending/receiving from the network. To support legacy blocks, the entire blockchain would have to be reindexed. Some further thoughts for comment...
Given a delta uxto size (whether composite with sigops or not), is it better to:
credit or debit the required fee during tx preparation
or
aggregate delta utxo size at a block level and scale an "allowed" block size which can be mined for the given tx set in it
or
both?
I think setting a required fee as a network rule is the wrong approach. Either have the UTXO limits as a separate rule or folded into size. That way there is some kind of market price effect. I think it's a good idea and should have an new thread for that. |
|
|
|
My formula works with bytes all around, though there is some scaling because signatures tend to be much bigger than outputs and limits because I'm trying to avoid some edge cases like miners bloating the utxo set with cheaply spendable outputs in order to store-and-forward their blocksize.
Do you document your formula somewhere? |
|
|
|
|
Show Posts
