|
283
|
Bitcoin / Bitcoin Discussion / Re: Big block support observer
|
on: August 16, 2015, 07:21:40 AM
|
those pools support bigger blocks but they won't switch to a fork like XT, if i remember correctly they said that once.
This thread is NOT about any specific big block implementation |
|
|
|
|
288
|
Bitcoin / Bitcoin Discussion / Re: Big block support observer
|
on: August 16, 2015, 05:53:14 AM
|
Signatures listed here are verified by me. To save space, the signatures, which could be found in the replies to this thread, is not included. Supporting BIP101 (2.45396218 BTC): 17J2X8gcNKAinqsgLLXjLfdYm8bakNDA6H - 2.45396218 BTC Supporting big block (0.58531338 BTC): This address 16mT7jrpkjnJBD7a3TM2awyxHub58H6r6Z with 0.58531338 BTC as of 201508162045UTC supports a combination of BIP 100 and BIP 101 where the voting system and upgrading mechanism from BIP 100 is used as a voting system for voting for the next step increase proposed in the block increase scheme in BIP 101. E.g. for each step up increase proposed in BIP 101, the BIP 100 voting is used to determine whether to go ahead with the increase or postpone for a later date. |
|
|
|
|
289
|
Bitcoin / Bitcoin Discussion / Re: Big block support observer
|
on: August 16, 2015, 05:53:05 AM
|
Proof-of-stake signature The signing address must hold at least 1 satoshi. Please submit your signature by - Sending to me by BitMessage BM-NBaYi7eyNHXfWQ9Piie9PJ8fMJxbUZ8Z (Best for anonymity)
- Posting in this thread (if you don't care anonymity)
- PM to me. I will try my best not to disclose your identity but no guarantee could be made
Please sign a statement with your address with bitcoin, with the following recommended formats: Approval: - This address 1xxx with 1.23BTC supports big block. 201508161810UTC.
- This address 1xxx with 1.23BTC supports BIP100. 201508161810UTC.
- This address 1xxx with 1.23BTC supports 8MB block. 201508161810UTC.
Disapproval: - This address 1xxx with 1.23BTC does not support big block. 201508161810UTC.
Mixed: - This address 1xxx with 1.23BTC supports BIP101 but not BIP102. 201508161810UTC.
- This address 1xxx with 1.23BTC does not support big block until 201703010000UTC. 201508161810UTC.
In you signature please quote the total amount of Bitcoin in the address, and the time of signature. The examples above mean the message is signed at 2015-Aug-16 18:10UTC. If you want to mention a time in your message (like the last example), please use the same format. |
|
|
|
|
292
|
Bitcoin / Bitcoin Discussion / Re: Big block support observer
|
on: August 16, 2015, 05:52:38 AM
|
UPDATE: 201508160615UTC, Big block supporting full nodes: 242/5898 = 4.1%  source: http://**nodes.com BIP101 blocks on mainnet: 0/1000 (block 370078) BIP101 blocks on testnet3: 0/1000 (block 530670) UPDATE: 201508161500UTC BIP101 supporting full nodes has become the top 4 user agent on Bitcoin network  |
|
|
|
|
293
|
Bitcoin / Bitcoin Discussion / Re: Big block support observer
|
on: August 16, 2015, 05:52:29 AM
|
This is a summary of big block proposals I posted earlier on the bitcoin-dev mailing list Currently, there are 4 block size BIP by Bitcoin developers: BIP100 by Jeff: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdfBIP101 by Gavin: https://github.com/bitcoin/bips/blob/master/bip-0101.mediawikiBIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/filesBIP??? by Pieter (called "BIP103" below): https://gist.github.com/sipa/c65665fc360ca7a176a6Should we use a miner voting mechanism to initiate the hardfork? BIP100: Yes, support with 10800 out of last 12000 blocks (90%) BIP101: Yes, support with 750 out of last 1000 blocks (75%) BIP102: No BIP103: No When should we initiate the hardfork? BIP100: 2016-01-11# BIP101: 2 weeks after 75% miner support, but not before 2016-01-11 BIP102: 2015-11-11 BIP103: 2017-01-01 # The network does not actually fork until having 90% miner support What should be the block size at initiation? BIP100: 1MB BIP101: 8MB* BIP102: 2MB BIP103: 1MB * It depends on the exact time of initiation, e.g. 8MB if initiated on 2016-01-11, 16MB if initiated on 2018-01-10. Should we allow further increase / decrease? BIP100: By miner voting, 0.5x - 2x every 12000 blocks (~3 months) BIP101: Double every 2 years, with linear interpolations in between (41.4% p.a.) BIP102: No BIP103: +4.4% every 97 days (double every 4.3 years, or 17.7% p.a.) The earliest date for a >=2MB block? BIP100: 2016-04-03^ BIP101: 2016-01-11 BIP102: 2015-11-11 BIP103: 2020-12-27 ^ Assuming 10 minutes blocks and votes cast before 2016-01-11 are not counted What should be the final block size? BIP100: 32MB is the max, but it is possible to reduce by miner voting BIP101: 8192MB BIP102: 2MB BIP103: 2048MB When should we have the final block size? BIP100: Decided by miners BIP101: 2036-01-06 BIP102: 2015-11-11 BIP103: 2063-07-09 |
|
|
|
|
294
|
Bitcoin / Bitcoin Discussion / Big block support observer
|
on: August 16, 2015, 05:52:15 AM
|
Objectives: 1. To follow the trend of big block approval / disapproval among full nodes 2. To follow the trend of big block approval / disapproval among miners 3. To follow the trend of big block approval / disapproval among major bitcoin economy players, holders, etc. 4. To discuss the strategy of soliciting support for big blocks (or otherwise) 5. This thread is not restricted to any specific big block client / BIP Methods: 1. Follow the number of big block supporting full nodes, e.g. BitcoinXX 2. Follow the number of big block supporting blocks, e.g. version 0x20000007, coinbase message 3. Follow credible news source, twitter/reddit/forum accounts 4. Proof of stake signature. If you hold bitcoins and would like to voice out, please sign a statement with your address with bitcoin. InstructionsRules: 1. This is a self-moderated thread. Posts violating the rules may be removed. 2. This thread is NOT for big block debate, including the discussion of pros and cons of different proposals and implementations. If you want to debate please go somewhere else. I believe there are plenty of places for this. 3. I don't want this tread being censored. Please avoid directly mentioning or linking any specific big block enabling bitcoin client. For sarcasm or not, call them BitcoinXX, Bitcoin**, BitcoinCensored, etc. Welcome to internet censorship (Based on the recent moderation style in this forum, this seems not necessary now) 4. No trolling 5. I will moderate more strictly if you have an ad-sig.If you like this thread, please consider to donate a few mBTC to the address in my signature. |
|
|
|
|
298
|
Bitcoin / Bitcoin Discussion / Re: What is soft folk and hard folk?
|
on: August 13, 2015, 01:45:06 PM
|
There's nothing contradictory because you deliberately ignore my other examples. The other examples are the same. They add new rules that are limiting your abilities of doing something. I think we need gmaxwell to explain what he mean by 'counting on old rules', it's really vague to me. No. Anything before 0.9.5 are not safe because they are not doing full validation. You need to wait for 30 confirmations if you are using anything before 0.9.5, according to https://bitcoin.org/en/alert/2015-07-04-spv-mining . The warning is STILL valid as of this writing. I'm sure you are aware of what caused that split. It was miners who didn't update their software while telling the network that they did. This 'split' wouldn't last that long if it wasn't nearly half the hashrate doing 'SPV' mining, it would've resolved pretty quickly. Well, strictly speaking, pre-BIP66 nodes are not doing full validation as they don't validate DER strictness, I agree. But they are still validating blocks and signatures, it's far from SPV. That's a bit different than BIP16 I guess. Ok, I see what you mean here, and I agree. In our usual understanding, "anyone can mine" is a fundamental rule of bitcoin, while we could change this rule by a softfork. So "all the old rules are still intact (after a softfork)" is not true, unless one tries to distort the meaning of "rules". If a node is relying on the honesty of any miners, it is not a full node. |
|
|
|
|
299
|
Bitcoin / Development & Technical Discussion / Re: Ideas for a new block header format
|
on: August 13, 2015, 01:31:08 PM
|
Why not use the first byte of the version as a header length indicator to give you up to an additional 95 bytes of extended header for clients that are aware? If the version is FF, then the version is in the extended header and clients should look there for it because it is bigger than 1 byte.-> Fully backwards compatible.
If you need more, just keep leapfrogging adding 255 bytes or less whenever you need a bigger header and always maintaining backwards compatibility.
How would you hash the "extended header"? If it is not hashed, it is not a part of the header. If it is hashed, it is not backward compatible |
|
|
|
|
300
|
Bitcoin / Development & Technical Discussion / Re: Ideas for a new block header format
|
on: August 13, 2015, 01:28:24 PM
|
Targets:
1. Existing ASICs must survive the new format. Otherwise, miners won't agree to upgrade
2. To allow more information included in the header
3. Include height in the header so we could have a monotonic indicator in the header.
4. Headers not being too big for SPV clients
What did you have in mind with 2 and 3? Why is a monotonic indicator necessary at all? (besides you could also derive that from the current latest block, if necessary) 1 and 4 are only of concern if we actually need to change the header format, which I seriously doubt. Exactly what is the problem you're trying to solve? Problems to solve: 1. To introduce merkle-sum-tree: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas2. More nonce space for ASIC: 4 bytes are not enough already. 3. More space for miner voting. Currently, there are only 28 bits available in the version field for this purpose. More complicated ideas, e.g. BIP100, require casting votes in coinbase. However, coinbase is not part of the header and is difficult for SPV nodes to follow 4. Recently there is some discussion on the mailing list that whether we should use the timestamp, median time of the past 11 blocks, or block height to determine the activation of a fork, etc. Timestamp is the easiest but it is not monotonic. The rest 2 are monotonic but can't be determined purely but the header of one block. We could solve the problem by putting height in the header. 5. Some space for future expansion I think the first one is the most important as blocks become larger and more people run SPV nodes. The second one is also a common complaint. The rest are beneficial side effects. |
|
|
|
|
Show Posts
? hopefully not. 
