[bitcoin-dev] Bitcoin governance
(sorry for the long post, I tried) I've been thinking about how we could build an effective Bitcoin governance, but couldn't come up with anything remotely plausible. It seems we might go a different way, though, with Core and XT continue co-existing in parallel, mostly in a compatible state, out of the need that there can be only one. Both having the same technical protocol, but different people, structure, processes and political standing; serving as a kind of two-party system and keeping each other in check. Their respective power will be determined by the number of Core vs XT nodes running and people/businesses on board. They will have to negotiate any significant change at the risk of yet another full fork. And occasionally the full forks will still happen and the minority will have to concede and change their protocol to match the winning side. Can there be any other way? Can you really control a decentralized system with a centralized governance, like Core Devs or TBF? In this view, what's happening is a step _towards_ decentralization, not away from it. It proves that Bitcoin is indeed a decentralized system and that minority cannot impose its will. For the sides to agree now would actually be a bad thing, because that would mean kicking the governance problem down the road. And we _need_ to go through this painful split at least once. The block size issue is perfect: controversial enough to push the split, but not controversial enough so one side couldn't win. If this is where we're heading then both sides should probably start thinking of themselves as opposition parties, instead of whatever they think of themselves now. People and businesses ultimately decide and they need a way to cast a Yes/No vote on proposed changes. Hence the two-party system. If the split in power is, say, 60/40 and the leading party introduces an unpopular change, it can quickly lose its advantage. We already have the democratic party on the left with Gavin and Mike representing the wish of the majority and the conservative party on the right, who would prefer things to stay the way they are. Finally, I propose to improve the voting mechanism of Bitcoin to serve this new reality better. Using the upcoming fork as an opportunity, we could add something like 8-byte votes into blocks: * first 4 bytes: fork/party ID, like 'CORE' or 'XT' * second 4 bytes: proposition number (or at least add the ID somewhere so the parties wouldn't have to negotiate block version numbers). Miners are in the business of mining coins, so they are good sensors of where the economic majority will be. We will have a representative democracy, with miners serving as 'hubs', collecting all the noise and chatter and casting it into a vote. This is not perfect, but nothing ever is. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin governance
It is a common misconception that the core devs govern Bitcoin; They set standards rather than govern. It is an important standard, but it is a voluntary standard. How important that standard in terms of defining the consensus rules is subject to speculation and the amount of influence depends on the specific circumstances. Maybe some wording can be changed to reflect that it is a voluntary standard. Russ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Bitcoin core 0.11.0 release candidate 3 available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, I've just uploaded Bitcoin Core 0.11.0rc3 executables to: https://bitcoin.org/bin/bitcoin-core-0.11.0/test/ The source code can be found in the source tarball or in git under the tag 'v0.11.0rc3' Preliminary release notes can be found here: https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md Changes since rc2: +- #6319 `3f8fcc9` doc: update mailing list address +- #6303 `b711599` gitian: add a gitian-win-signer descriptor +- #6246 `8ea6d37` Fix build on FreeBSD +- #6282 `daf956b` fix crash on shutdown when e.g. changing -txindex and abort action +- #6233 `a587606` Advance pindexLastCommonBlock for blocks in chainActive +- #6333 `41bbc85` Hardcoded seeds update June 2015 +- #6354 `bdf0d94` Gitian windows signing normalization Thanks to everyone that participated in development, translation or in the gitian build process, Wladimir -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVk9IfAAoJEHSBCwEjRsmmm84H/AoBHiKKEIuT/86+VSs+1ICY sUTXF5Q0qeAELSKO2auq1wOAA62UuhUd46S+lAWe3cL3G2UJzFt0WWXq2fOUjKur 27HTutmY9Oy/7fGLGT0CNCuXJ8bKGoUzIx4nhNEMvaucangaKpHtSCPAzqkEY4mW cCuAh3pHR3xgfA5EYfBxq2jGUEC5iUzmsvEL4LXoBKt60f9AI/H08IFSa9uyJZAS f5HyVtYF5/OZxD1GUyAfSfeSteBRBkoqRNww0LE6b0PQE9ZHLZzsUxngsOkPKMQU OJGgDMkgO/7c6gfpHCBLdWkSQEJuRfH/EeVnM5poOjwrGiWewc0O/+svT2WdfRo= =rESk -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin governance
On 07/01/2015 03:54 AM, Jeffrey Paul wrote: could we please limit ourselves to posting about the research and development of Bitcoin Core? If that's the purpose of this list, then it is misleadingly named. If development of Bitcoin Core, the application, is to be considered independent from development of Bitcoin, the protocol, then Bitcoin Core development needs its own list. 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
Hi Justus, What are the potential applications for this BIP? -Kr On Jun 30, 2015 1:53 PM, Justus Ranvier justus.ranv...@monetas.net wrote: Monetas has developed a Bitmessage address derivation method from an HD seed based on BIP-43. https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki We're proposing this as a BIP per the BIP-43 recommendation in order to reserve a purpose code. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Reaching consensus on policy to continually increase block size limit as hardware improves, and a few other critical issues
This is great: Adam agrees that we should scale the block size limit discretionarily upward within the limits of technology, and continually so as hardware improves. Peter and others: What stands in the way of broader consensus on this? We also agree on a lot of other important things: -- block size is not a free variable -- there are trade-offs between node requirements and block size -- those trade-offs have impacts on decentralization -- it is important to keep decentralization strong -- computing technology is currently not easily capable of running a global transaction network where every transaction is broadcast to every node -- we may need some solution (perhaps lightning / hub and spoke / other things) that can help with this We likely also agree that: -- whatever that solution may be, we want bitcoin to be the hub / core of it -- this hub needs to exhibit the characteristic of globally aware global consensus, where every node knows about (awareness) and agrees on (consensus) every transaction -- Critically, the Bitcoin Core Goal: the goal of Bitcoin core is to build the best globally aware globally consensus network, recognizing there are complex tradeoffs in doing this. There are a few important things we still don't agree on though. Our disagreement on these things is causing us to have trouble making progress meeting the goal of Bitcoin Core. It is critical we address the following points of disagreement. Please help get agreement on these issues below by sharing your thoughts: 1) Some believe that fees and therefore hash-rate will be high by limiting capacity, and that we need to limit capacity to have a healthy fee market. Think of the airplane analogy: If some day technology exists to ship a hundred million people (transactions) on a plane (block) then do you really want to fight to outlaw those planes? Airlines are regulated so they have to pay to screen each passenger to a minimum standard, so even if the plane has unlimited capacity, they still have to pay to meet minimum security for each passenger. Just like we can set the block limit, so can we regulate the airline security requirements and set a minimum fee size for the sake of security. If technology allows running 100,000 transactions per second in 25 years, and we set the minimum fee size to one penny, then each block is worth a minimum of $600,000. Miners should be ok with that and so should everyone else. 2) Some believe that it is better for (a) network reliability and (b) validation of transaction integrity, to have every user run a full node in order to use Bitcoin Core. I don't agree with this. I'll break this into two pieces of network reliability and transaction integrity. Network Reliability Imagine you're setting up an email server for a big company. You decide to set up a main server, and two fail-over servers. Somebody says that they're really concerned about reliability and asks you to add another couple fail-over servers. So you agree. But at some point there's limited benefit to adding more servers: and there's real cost -- all those servers need to keep in sync with one another, and they need to be maintained, etc. And there's limited return: how likely is it really that all those servers are going to go down? Bitcoin is obviously different from corporate email servers. In one sense, you've got miners and volunteer nodes rather than centrally managed ones, so nodes are much more likely to go down. But at the end of the day, is our up-time really going to be that much better when you have a million nodes versus a few thousand? Cloud storage copies your data a half dozen times to a few different data centers. But they don't copy it a half a million times. At some point the added redundancy doesn't matter for reliability. We just don't need millions of nodes to participate in a broadcast network to ensure network reliability. Transaction Integrity Think of open source software: you trust it because you know it can be audited easily, but you probably don't take the time to audit yourself every piece of open source software you use. And so it is with Bitcoin: People need to be able to easily validate the blockchain, but they don't need to be able to validate it every time they use it, and they certainly don't need to validate it when using Bitcoin on their Apple watches. If I can lease a server in a data center for a few hours at fifty cents an hour to validate the block chain, then the total cost for me to independently validate the blockchain is just a couple dollars. Compare that to my cost to independently validate other parts of the system -- like the source code! Where's the real cost here? If the goal of decentralization is to ensure transaction integrity and network reliability, then we just don't need lots of nodes or every user running a node to meet that goal. If the goal of decentralization is something else: what is it? 3) Some believe that we should make Bitcoin Core to run as a
[bitcoin-dev] Defining a min spec
Hi folks, I’m a game developer. I write time critical code for a living and have to deal with memory, CPU, GPU and I/O budgets on a daily basis. These budgets are based on what we call a minimum specification (of hardware); min spec for short. In most cases the min spec is based on entry model machines that are available during launch, and will give the user an enjoyable experience when playing our games. Obviously, we can turn on a number of bells and whistles for people with faster machines, but that’s not the point of this mail. The point is, can we define a min spec for Bitcoin Core? The number one reason for this is: if you know how your changes affect your available budgets, then the risk of breaking something due to capacity problems is reduced to practically zero. One way of doing so is to work backwards from what we have right now: Block size (network / disk I/O), SigOps/block (CPU), UTXO size (memory), etc. Then there’s Pieter’s analysis of network bottlenecks and how it affects orphan rates that could be used to set some form of cap on what transfer time + verification time should be to keep the orphan rate at an acceptable level. So taking all of the above (and more) into account, what configuration would be the bare minimum to comfortably run Bitcoin Core at maximum load and can it be reasonably expected to still be out there in the field running Bitcoin Core? Also, can the parameters that were used to determine this min spec be codified in some way so that they can later be used if Bitcoin Core is optimized (or extended with new functionality) and see how it affects the min spec? Basically, with any reasonably big change, one of the first questions could be: “How does this change affect min spec? For example, currently OpenSSL is used to verify the signatures in the transactions. The new secp256k1 implementation is several times faster than (depending on CPU architecture, I’m sure) OpenSSL’s implementation. So it would result in faster verification time. This can then result in the following things; either network I/O and CPU requirements are adjusted downward in the min spec (you can run the new Bitcoin Core on a cheaper configuration), or other parameters can be adjusted upwards (number of SigOps / transaction, block size?), through proper rollout obviously. Since we know how min spec is affected by these changes, they should be non-controversial by default. Nobody running min spec is going to be affected by it, etc. Every change that has a positive effect on min spec (do more on the same hardware) basically pushes the need to start following any of the curve laws (Nielsen, Moore) forward. No need for miners / node operators to upgrade. Once we hit what we call SOL (Speed Of Light, the fastest something can go on a specific platform) it’s time to start looking at periodically adjusting min spec upwards, or by that time maybe it’s possible to use conservative plots of the curve laws as a basis. Lastly, a benchmark test could be developed that can tell everyone running Bitcoin Core how their setup compares to the min spec and how long they can expect to run on this setup. What do you guys think? jp signature.asc Description: Message signed with OpenPGP using GPGMail ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
PR#1647 only addresses miner policy, though, right? I believe the BIP is addressing the user-facing side of this functionality. CPFP mining policy does very little good if wallets don't offer any way for users to goose up incoming transactions. On Wednesday, 1 July 2015, at 9:52 pm, Mark Friedenbach wrote: This is called child pays for parent and there is a three year old pull request implementing it: https://github.com/bitcoin/bitcoin/pull/1647 The points regarding sweep transaction UI is out of scope for a BIP I'm afraid. I suggest talking with wallet authors, and if agreement can be found writing a pull request. On Jul 1, 2015 9:44 PM, Dan Bryant dkbry...@gmail.com wrote: This is a process BIP request to add functionality to the Bitcoin-Core reference implementation. If accepted, this could also add flexibility into any future fee schedules. https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
This is called child pays for parent and there is a three year old pull request implementing it: https://github.com/bitcoin/bitcoin/pull/1647 The points regarding sweep transaction UI is out of scope for a BIP I'm afraid. I suggest talking with wallet authors, and if agreement can be found writing a pull request. On Jul 1, 2015 9:44 PM, Dan Bryant dkbry...@gmail.com wrote: This is a process BIP request to add functionality to the Bitcoin-Core reference implementation. If accepted, this could also add flexibility into any future fee schedules. https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki Note, left the formatting in, since mediawiki is a fairly light markup. == pre BIP: nn Title: Sweep unconfirmed transactions by including their outputs in high fee transactions Author: Dan Bryant dkbry...@gmail.com Status: Draft Type: Process Created: 2015-07-01 /pre ==Abstract== This BIP describes an enhancement to the reference client that addresses the need incentive inclusion of unconfirmed transactions. This method will create new high fee (or bounty) transactions that spend the desired unconfirmed transactions. To claim the high fee (bounty) transactions, miners will need to include the desired unconfirmed transactions. ==Motivation== There are times when an individual receives a payment from someone that is in a poorly crafted transaction. This transaction may include no fees, or insufficient fees to be included by many miners. The recipient would be willing to pay a nominal transaction fee to have the payment transaction swept into the next block, but has no simple way to craft this incentive. This BIP could be highly desirable for merchants who may have little control over the type of wallets their customers use. A merchant will want to ensure that all POS transactions to their hot wallet be given a high probability of inclusion in the next block. This BIP would allow the merchant to sweep all their POS transactions currently in the mempool into one high fee sweep, thus greatly increasing the chance that they are in the next block. Although many wallets have the ability to tailor the transaction fees of payments that are sent, this BIP is unique in the sense that it allows people to offer a bounty for transactions that are incoming. ==Specification== This BIP would have two implementations; an automatic sweep of incoming unconfirmed transaction setting, and a manual sweep of unconfirmed transaction setting. Both would have the ability to set the fee amount the user would like to pay for the sweep. Automatic sweep of incoming unconfirmed transactions An automatic sweep configuration may be ideal for merchants who want to ensure that their incoming transactions are not skipped over by miners. An automatic sweep setting would consist of four fields, tt'''sweep_fee'''/tt, tt'''skipped_count'''/tt, and tt'''btc_threshold'''/tt Currently, the standard transaction fee is 0.0001 BTC, a generous sweep bounty would be 0.001 BTC. Skipped-count will control the age of unconfirmed transactions to include in the sweep. If skipped-count is set to three, then any incoming transaction that remains unconfirmed for 3 blocks would trigger a sweep. A skipped-count of 0 would trigger a sweep whenever any transaction is skipped, or if it reaches an age of 10 minutes, regardless of how long the current block is taking. As a safeguard to paying a bounty for small dust transactions, a minimum btc-threshold would be required for any automatic configuration. A good starting threshold would be 0.10 BTC. These automatic settings would allow a wallet implementing this BIP to automatically perform a sweep of unconfirmed transactions whenever more than 0.10 BTC of incoming transactions were detected in the mempool. Furthermore, no more than one automatic sweep would be performed in any 10 minute window. Whenever a sweep is triggered, all incoming unconfirmed transactions should be swept, not simply the ones that triggered the sweep. These would include new transactions as well as dust transactions. Each sweep transaction would go to a new wallet address since recycling wallet addresses is poor practice. Manual sweep of incoming unconfirmed transactions A manual sweep of incoming unconfirmed transactions would be a special type of Send in the current reference implementation. A manual sweep would auto-fill a send transaction with all currently unconfirmed incoming transactions in the mempool. The fee field would be completely settable by the user and would auto-fill with the suggestions of 0.001 BTC A manual sweep would also be available as a context option when selecting any unconfirmed transaction. ==Compatibility== Wallet software that does not support this BIP will continue to operate without modification. ==Examples== pre //unconf_tx =
[bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
This is a process BIP request to add functionality to the Bitcoin-Core
reference implementation. If accepted, this could also add
flexibility into any future fee schedules.
https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki
Note, left the formatting in, since mediawiki is a fairly light markup.
==
pre
BIP: nn
Title: Sweep unconfirmed transactions by including their outputs in
high fee transactions
Author: Dan Bryant dkbry...@gmail.com
Status: Draft
Type: Process
Created: 2015-07-01
/pre
==Abstract==
This BIP describes an enhancement to the reference client that
addresses the need incentive inclusion of unconfirmed transactions.
This method will create new high fee (or bounty) transactions that
spend the desired unconfirmed transactions. To claim the high fee
(bounty) transactions, miners will need to include the desired
unconfirmed transactions.
==Motivation==
There are times when an individual receives a payment from someone
that is in a poorly crafted transaction. This transaction may include
no fees, or insufficient fees to be included by many miners. The
recipient would be willing to pay a nominal transaction fee to have
the payment transaction swept into the next block, but has no simple
way to craft this incentive.
This BIP could be highly desirable for merchants who may have little
control over the type of wallets their customers use. A merchant will
want to ensure that all POS transactions to their hot wallet be given
a high probability of inclusion in the next block. This BIP would
allow the merchant to sweep all their POS transactions currently in
the mempool into one high fee sweep, thus greatly increasing the
chance that they are in the next block.
Although many wallets have the ability to tailor the transaction fees
of payments that are sent, this BIP is unique in the sense that it
allows people to offer a bounty for transactions that are incoming.
==Specification==
This BIP would have two implementations; an automatic sweep of
incoming unconfirmed transaction setting, and a manual sweep of
unconfirmed transaction setting. Both would have the ability to set
the fee amount the user would like to pay for the sweep.
Automatic sweep of incoming unconfirmed transactions
An automatic sweep configuration may be ideal for merchants who want
to ensure that their incoming transactions are not skipped over by
miners. An automatic sweep setting would consist of four fields,
tt'''sweep_fee'''/tt, tt'''skipped_count'''/tt, and
tt'''btc_threshold'''/tt
Currently, the standard transaction fee is 0.0001 BTC, a generous
sweep bounty would be 0.001 BTC. Skipped-count will control the age
of unconfirmed transactions to include in the sweep. If skipped-count
is set to three, then any incoming transaction that remains
unconfirmed for 3 blocks would trigger a sweep. A skipped-count of 0
would trigger a sweep whenever any transaction is skipped, or if it
reaches an age of 10 minutes, regardless of how long the current block
is taking.
As a safeguard to paying a bounty for small dust transactions, a
minimum btc-threshold would be required for any automatic
configuration. A good starting threshold would be 0.10 BTC. These
automatic settings would allow a wallet implementing this BIP to
automatically perform a sweep of unconfirmed transactions whenever
more than 0.10 BTC of incoming transactions were detected in the
mempool. Furthermore, no more than one automatic sweep would be
performed in any 10 minute window.
Whenever a sweep is triggered, all incoming unconfirmed transactions
should be swept, not simply the ones that triggered the sweep. These
would include new transactions as well as dust transactions. Each
sweep transaction would go to a new wallet address since recycling
wallet addresses is poor practice.
Manual sweep of incoming unconfirmed transactions
A manual sweep of incoming unconfirmed transactions would be a special
type of Send in the current reference implementation. A manual
sweep would auto-fill a send transaction with all currently
unconfirmed incoming transactions in the mempool. The fee field would
be completely settable by the user and would auto-fill with the
suggestions of 0.001 BTC
A manual sweep would also be available as a context option when
selecting any unconfirmed transaction.
==Compatibility==
Wallet software that does not support this BIP will continue to
operate without modification.
==Examples==
pre
//unconf_tx = ef7c0cbf6ba5af68d2ea239bba709b26ff7b0b669839a63bb01c2cb8e8de481e
//hifee_tx = f5a5ce5988cc72b9b90e8d1d6c910cda53c88d2175177357cc2f2cf0899fbaad
//rcpt_addr = moQR7i8XM4rSGoNwEsw3h4YEuduuP6mxw7 # recipient controlled addr.
//chng_addr = mvbnrCX3bg1cDRUu8pkecrvP6vQkSLDSou # recipient controlled addr.
// UNCONF_TX - Assume a zero fee TX that miners are refusing in mempool
{
txid : $unconf_tx,
//...
vin : [
//...
],
vout : [
[bitcoin-dev] BIP 68 Questions
Hi Mark, It looks like the code in BIP 68 compares the input's nSequence against the transaction's nLockTime: if ((int64_t)tx.nLockTime LOCKTIME_THRESHOLD) nMinHeight = std::max(nMinHeight, (int)tx.nLockTime); else nMinTime = std::max(nMinTime, (int64_t)tx.nLockTime); if (nMinHeight = nBlockHeight) return nMinHeight; if (nMinTime = nBlockTime) return nMinTime; So if transaction B spends the output of transaction A: 1. If A is in the blockchain already, you don't need a relative locktime since you know A's time. 2. If it isn't, you can't create B since you don't know what value to set nLockTime to. How was this supposed to work? Thanks, Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Process and Votes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Possibly relevant to this discussion (though old) https://gist.github.com/gavinandresen/2355445 (last changed in 2012 I think?) and https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork (which cites gavin's gist shown above) On 06/25/2015 05:42 PM, Milly Bitcoin wrote: That description makes sense. It also makes sense to separate out the hard fork from the soft fork process. Right now some people want to use the soft fork procedure for a hard fork simply because there is no other way to do it. I am under the impression that most users expect changes/improvements that would require a hard fork so I think some kind of process needs to be developed. Taking the responsibility off the shoulder of the core maintainer also makes sense. The hard fork issue is too much of a distraction for people trying to maintain the nuts and bolts of the underlying system. I saw a suggestion that regularly scheduled hard forks should be planned. That seems to make sense so you would have some sort of schedule where you would have cut off dates for hard-fork BIP submissions. That way you avoid the debates over whether there should be hard forks to what should be contained within the hard fork (if needed). It makes sense to follow the BIP process as close as possible. Possibly adding another step after Dev acceptance to include input from others such as merchants/exchanges/miners/users. It will only be an approximation of decentralization and the process won't be perfect but if you want to move forward then you need some way to do it. Russ On 6/25/2015 4:05 PM, Tier Nolan wrote: On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach m...@friedenbach.org mailto:m...@friedenbach.org wrote: I'm sorry but this is absolutely not the case, Milly. The reason that people get defensive is that we have a carefully constructed process that does work (thank you very much!) and is well documented. There is no process for handling hard forks, which aren't bug fixes. Soft forks have a defined process of something like - BIP proposal + discussion - Proposed code - Dev acceptance - Release - Miner vote/acceptance The devs have a weak veto. If they refuse to move forward with changes, miners could perform a soft fork on their own. They don't want to do that, as it would be controversial and the devs know the software better. The miner veto is stronger (for soft forks) but not absolute. The devs could checkpoint/blacklist a chain if miners implemented a fork that wasn't acceptable (assuming the community backed them). When ASICs arrived, it was pointed out by some that the devs could hit back if ASICs weren't made publicly available. If they slightly tweaked the hashing algorithm, then current generation of ASICs would be useless. The potential threat may have acted as a disincentive for ASIC manufacturers to use the ASICs themselves. Moving forward with agreement between all involved is the recommended and desirable approach. Consensus between all parties is the goal but isn't absolutely required. This escape valve is partly what makes consensus work. If you dig your heels in, then the other side can bypass you, but they have an incentive to try to convince you to compromise first. The outcome is better if a middle ground can be found. Hard forks are different. The checks and balances of weak vetoes are not present. This means that things can devolve from consensus to mutual veto. Consensus ceases to be a goal and becomes a requirement. This is partly a reflection of the nature of hard forks. Everyone needs to upgrade. On the other hand, if most of the various groups upgrade, then users of the legacy software would have to upgrade or get left behind. If 5% of the users decided not to upgrade, should they be allowed to demand that nobody else does? There is clearly some kind of threshold that is reasonable. The fundamental problem is that there isn't agreement on what the block size is. Is it equal in status to the 21 million BTC limit? If Satoshi had said that 1MB was part of the definition of Bitcoin, then I think people would accept it to the same extent as they accept the 21 million coin limit. It might cause people to leave the coin though. It was intended to be temporary, but people have realized that it might be a good idea to keep it. In effect both sides could argue that they should be considered the status quo. I wonder if a coin toss would be acceptable :). Come to an agreement or we decide by coin toss ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org
Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (My replies below) On 06/26/2015 06:47 AM, Tier Nolan wrote: On Thu, Jun 25, 2015 at 3:07 PM, Adam Back a...@cypherspace.org mailto:a...@cypherspace.org wrote: The hard-cap serves the purpose of a safety limit in case our understanding about the economics, incentives or game-theory is wrong worst case. True. Yep. BIP 100 and 101 could be combined. Would that increase consensus? Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100 is a better alternative to Gavin's proposal(s), but that I didn't think that this should be taken to mean that I am saying one thing is superior to Gavin's work, rather, I emphasized that Gavin work with Jeff and Adam. At least, at this stage the things are in a BIP process. If the BIP 100 and BIP 101 would be combined, what would that look like on paper? - Miner vote threshold reached - Wait notice period or until earliest start time - Block size default target set to 1 MB - Soft limit set to 1MB - Hard limit set to 8MB + double every 2 years - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB minimum) Block size updates could be aligned with the difficulty setting and based on the last 2016 blocks. Miners could leave the 1MB limit in place initially. The vote is to get the option to increase the block size. Legacy clients would remain in the network until 80% of miners vote to raise the limit and a miner produces a 1MB block. If the growth rate over-estimates hardware improvements, the devs could add a limit into the core client. If they give notice and enough users update, then miners would have to accept it. The block size becomes min(miner's vote, core devs). Even if 4 years notice is given, blocks would only be 4X optimal. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev - -- http://abis.io ~ a protocol concept to enable decentralization and expansion of a giving economy, and a new social good https://keybase.io/odinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC 5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ 0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog= =rtTH -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
