* [bitcoin-dev] BIP 100 repo @ 2015-09-02 23:51 Jeff Garzik 2015-09-02 23:58 ` Jeff Garzik 0 siblings, 1 reply; 7+ messages in thread From: Jeff Garzik @ 2015-09-02 23:51 UTC (permalink / raw) To: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 194 bytes --] Opened a repo containing the full text of BIP 100 discussion document, in markdown format. The BIP 100 formal spec will be checked in here as well, before submitting to upstream bips.git repo. [-- Attachment #2: Type: text/html, Size: 270 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BIP 100 repo 2015-09-02 23:51 [bitcoin-dev] BIP 100 repo Jeff Garzik @ 2015-09-02 23:58 ` Jeff Garzik 2015-09-03 0:17 ` Luke Dashjr 2015-09-03 6:41 ` odinn 0 siblings, 2 replies; 7+ messages in thread From: Jeff Garzik @ 2015-09-02 23:58 UTC (permalink / raw) To: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 351 bytes --] Oops, link paste fail. The repo: https://github.com/jgarzik/bip100 On Wed, Sep 2, 2015 at 7:51 PM, Jeff Garzik <jgarzik@gmail•com> wrote: > Opened a repo containing the full text of BIP 100 discussion document, in > markdown format. > > The BIP 100 formal spec will be checked in here as well, before submitting > to upstream bips.git repo. > > > [-- Attachment #2: Type: text/html, Size: 791 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BIP 100 repo 2015-09-02 23:58 ` Jeff Garzik @ 2015-09-03 0:17 ` Luke Dashjr 2015-09-03 3:38 ` Jeff Garzik 2015-09-03 4:09 ` Jeff Garzik 2015-09-03 6:41 ` odinn 1 sibling, 2 replies; 7+ messages in thread From: Luke Dashjr @ 2015-09-03 0:17 UTC (permalink / raw) To: bitcoin-dev, Jeff Garzik On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev wrote: > The repo: https://github.com/jgarzik/bip100 What is the purpose of the newly added 1 MB floor? It seems clear from the current information available that 1 MB is presently too high for the limit, and it is entirely one-sided to only allow increases when decreases are much more likely to be needed in the short term. Must the new size limit votes use 11 bytes of coinbase? Why not just use a numeric value pushed after height? Since this is a hardfork, I suggest increasing the coinbase length to allow for 100 bytes *in addition* to the pushed height and size-vote. I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32 MB (or whatever value is deemed appropriate) to make it clear that the limit remains a part of the consensus protocol and p2p protocol limits are not to have an effect on consensus rules. Furthermore, I suggest modifying the voting to require 50% to set the limit floor. This has the effect of merely coordinating what miners can already effectively do today by rejecting blocks larger than some collusion- determined limit. Thoughts? Luke ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BIP 100 repo 2015-09-03 0:17 ` Luke Dashjr @ 2015-09-03 3:38 ` Jeff Garzik 2015-09-03 4:09 ` Jeff Garzik 1 sibling, 0 replies; 7+ messages in thread From: Jeff Garzik @ 2015-09-03 3:38 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 1628 bytes --] Luke, - Definitely agree with most of your suggestions on the practical side; several clarification could be made. - The power to decrease the hard limit appears riskier long term in my analysis. This is mitigated somewhat by the ease at which miners may locally or collectively lower the block size at any time, without a vote. On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <luke@dashjr•org> wrote: > On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev > wrote: > > The repo: https://github.com/jgarzik/bip100 > > What is the purpose of the newly added 1 MB floor? It seems clear from the > current information available that 1 MB is presently too high for the > limit, > and it is entirely one-sided to only allow increases when decreases are > much > more likely to be needed in the short term. > > Must the new size limit votes use 11 bytes of coinbase? Why not just use a > numeric value pushed after height? Since this is a hardfork, I suggest > increasing the coinbase length to allow for 100 bytes *in addition* to the > pushed height and size-vote. > > I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32 > MB > (or whatever value is deemed appropriate) to make it clear that the limit > remains a part of the consensus protocol and p2p protocol limits are not to > have an effect on consensus rules. > > Furthermore, I suggest modifying the voting to require 50% to set the limit > floor. This has the effect of merely coordinating what miners can already > effectively do today by rejecting blocks larger than some collusion- > determined limit. > > Thoughts? > > Luke > [-- Attachment #2: Type: text/html, Size: 2191 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BIP 100 repo 2015-09-03 0:17 ` Luke Dashjr 2015-09-03 3:38 ` Jeff Garzik @ 2015-09-03 4:09 ` Jeff Garzik 2015-09-03 4:55 ` Benjamin 1 sibling, 1 reply; 7+ messages in thread From: Jeff Garzik @ 2015-09-03 4:09 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 1481 bytes --] Oh, and answering your question about the 1M: It is a safety rail. It can perform no worse on the low end than the current system. Eliminates unlikely scenarios that squeeze users. On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <luke@dashjr•org> wrote: > On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev > wrote: > > The repo: https://github.com/jgarzik/bip100 > > What is the purpose of the newly added 1 MB floor? It seems clear from the > current information available that 1 MB is presently too high for the > limit, > and it is entirely one-sided to only allow increases when decreases are > much > more likely to be needed in the short term. > > Must the new size limit votes use 11 bytes of coinbase? Why not just use a > numeric value pushed after height? Since this is a hardfork, I suggest > increasing the coinbase length to allow for 100 bytes *in addition* to the > pushed height and size-vote. > > I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32 > MB > (or whatever value is deemed appropriate) to make it clear that the limit > remains a part of the consensus protocol and p2p protocol limits are not to > have an effect on consensus rules. > > Furthermore, I suggest modifying the voting to require 50% to set the limit > floor. This has the effect of merely coordinating what miners can already > effectively do today by rejecting blocks larger than some collusion- > determined limit. > > Thoughts? > > Luke > [-- Attachment #2: Type: text/html, Size: 2012 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BIP 100 repo 2015-09-03 4:09 ` Jeff Garzik @ 2015-09-03 4:55 ` Benjamin 0 siblings, 0 replies; 7+ messages in thread From: Benjamin @ 2015-09-03 4:55 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 3272 bytes --] I would be helpful to describe what is meant by "votes". As far as I understand this would be a semi-automatic process - nodes encode values which in turn are hardcoded in software, or is this completely automated without any intervention at all? Is there the possibility that nodes decide by encode votes, but somehow this decision is not adhered to? Is 4. a 51% rule? Under 2. it might make sense to specify values in the range (1MB steps e.g.). The number of options could have an effect. For example if the vote has 4 possible values or 32 possible values can make a difference in outcomes. With regards to 1. Bitcoin does not have a fee market, although I agree that might be a good goal. There is no price-determination of fees and no definition of quality of service. A fee market would entail some matching of demand and supply to establish a price. Users would adjust fee to win a transaction slow in a deterministic way. However currently the user has no way of knowing what effect a fee might have. So this would necessarily include some kind pricing-mechanism with actual commitments. Bitcoin as a system is quite far away from such a capability. It would mean Bitcoin is capable of adapting to how it is used. For example that would allow to shift transactions from high demand period to low demand period. I'm not aware of any proposal to make an actual functioning fee market in Bitcoin (or even the conceptual primitives). On Thu, Sep 3, 2015 at 5:09 AM, Jeff Garzik via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Oh, and answering your question about the 1M: It is a safety rail. It > can perform no worse on the low end than the current system. Eliminates > unlikely scenarios that squeeze users. > > > On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <luke@dashjr•org> wrote: > >> On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev >> wrote: >> > The repo: https://github.com/jgarzik/bip100 >> >> What is the purpose of the newly added 1 MB floor? It seems clear from the >> current information available that 1 MB is presently too high for the >> limit, >> and it is entirely one-sided to only allow increases when decreases are >> much >> more likely to be needed in the short term. >> >> Must the new size limit votes use 11 bytes of coinbase? Why not just use a >> numeric value pushed after height? Since this is a hardfork, I suggest >> increasing the coinbase length to allow for 100 bytes *in addition* to the >> pushed height and size-vote. >> >> I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32 >> MB >> (or whatever value is deemed appropriate) to make it clear that the limit >> remains a part of the consensus protocol and p2p protocol limits are not >> to >> have an effect on consensus rules. >> >> Furthermore, I suggest modifying the voting to require 50% to set the >> limit >> floor. This has the effect of merely coordinating what miners can already >> effectively do today by rejecting blocks larger than some collusion- >> determined limit. >> >> Thoughts? >> >> Luke >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 4368 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BIP 100 repo 2015-09-02 23:58 ` Jeff Garzik 2015-09-03 0:17 ` Luke Dashjr @ 2015-09-03 6:41 ` odinn 1 sibling, 0 replies; 7+ messages in thread From: odinn @ 2015-09-03 6:41 UTC (permalink / raw) To: Jeff Garzik, Bitcoin development mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Excellent - thank you. Jeff Garzik via bitcoin-dev: > Oops, link paste fail. > > The repo: https://github.com/jgarzik/bip100 > > > On Wed, Sep 2, 2015 at 7:51 PM, Jeff Garzik <jgarzik@gmail•com> > wrote: > >> Opened a repo containing the full text of BIP 100 discussion >> document, in markdown format. >> >> The BIP 100 formal spec will be checked in here as well, before >> submitting to upstream bips.git repo. >> >> >> > > > > _______________________________________________ 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----- iQEbBAEBCgAGBQJV5+uQAAoJEGxwq/inSG8CVBUH9A5GtIj3pLxZRlX0oDxSbIWJ 2830HURoeb40ShBlhbzO1nHiJtPhRPWqByZETQcuElBagMPreSKI5VZxJ1xaNOI3 o6yo9ujeLNlge1j53TOq8uQCXKnwrVsjS3yQkXlo+IX+Vihin5c/D4Xn9y97OqwQ CixVswCJrrRrGHj6YaFsfAx+epaJ/aT4djoB0XjH9PKJI5b0cPGSBDipHbuVn3nd FZidPAS/hHI0Sw3k0EHtYudjBXBbMi2hCad37asrg2cIF/sFbCA/BSkpuIi5agzY 50Wp8xm3gd4WWjEn/svhw2AIgH7R/1Yk2/qFImob5iXMm7sU1OUMHD325kN2dg== =7a0Z -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-09-03 6:41 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-09-02 23:51 [bitcoin-dev] BIP 100 repo Jeff Garzik 2015-09-02 23:58 ` Jeff Garzik 2015-09-03 0:17 ` Luke Dashjr 2015-09-03 3:38 ` Jeff Garzik 2015-09-03 4:09 ` Jeff Garzik 2015-09-03 4:55 ` Benjamin 2015-09-03 6:41 ` odinn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox