Pindar Wong [ARCHIVE] / is on Nostr

Last Notes

2023-06-08 00:52:04

- reply

📅 Original date posted:2021-04-23
📝 Original message:ACK.
p.
On Fri, Apr 23, 2021 at 10:09 AM Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Unless there are objections, I intend to add Kalle Alm as a BIP editor to
> assist in merging PRs into the bips git repo.
>
> Since there is no explicit process to adding BIP editors, IMO it should be
> fine to use BIP 2's Process BIP progression:
>
> > A process BIP may change status from Draft to Active when it achieves
> > rough consensus on the mailing list. Such a proposal is said to have
> > rough consensus if it has been open to discussion on the development
> > mailing list for at least one month, and no person maintains any
> > unaddressed substantiated objections to it.
>
> A Process BIP could be opened for each new editor, but IMO that is
> unnecessary. If anyone feels there is a need for a new Process BIP, we can
> go
> that route, but there is prior precedent for BIP editors appointing new
> BIP
> editors, so I think this should be fine.
>
> Please speak up soon if you disagree.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210423/0849a63a/attachment.html>

2023-06-07 17:43:19

- reply

📅 Original date posted:2015-07-23
📝 Original message:This looks like the beginnings of some great analysis.
Per Peter's remarks, I think it would be productive to run the test(s) on a
simulated network with worst case network failure(s) so that we can
determine the safety margin needed.
I have potential access to h/w resources that would be available for
running such tests at the necessary scales.
Cheers,
p.
On Fri, Jul 24, 2015 at 1:14 AM, Slurms MacKenzie via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The library used isn't open source, so unfortunately not. It shouldn't be
> too hard to replicate in python-bitcoinlib or bitcoinj though.
>
> *Sent:* Thursday, July 23, 2015 at 6:55 PM
> *From:* "Jameson Lopp" <jameson.lopp at gmail.com>
> *To:* slurms at gmx.us
> *Cc:* bitcoin-dev at lists.linuxfoundation.org
> *Subject:* Re: [bitcoin-dev] Bitcoin Node Speed Test
> Are you willing to share the code that you used to run the test?
>
> - Jameson
>
> On Thu, Jul 23, 2015 at 10:19 AM, slurms--- via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> On this day, the Bitcoin network was crawled and reachable nodes surveyed
>> to find their maximum throughput in order to determine if it can safely
>> support a faster block rate. Specifically this is an attempt to prove or
>> disprove the common statement that 1MB blocks were only suitable slower
>> internet connections in 2009 when Bitcoin launched, and that connection
>> speeds have improved to the point of obviously supporting larger blocks.
>>
>>
>> The testing methodology is as follows:
>>
>> * Nodes were randomly selected from a peers.dat, 5% of the reachable
>> nodes in the network were contacted.
>>
>> * A random selection of blocks was downloaded from each peer.
>>
>> * There is some bias towards higher connection speeds, very slow
>> connections (<30KB/s) timed out in order to run the test at a reasonable
>> rate.
>>
>> * The connecting node was in Amsterdam with a 1GB NIC.
>>
>>
>> Results:
>>
>> * 37% of connected nodes failed to upload blocks faster than 1MB/s.
>>
>> * 16% of connected nodes uploaded blocks faster than 10MB/s.
>>
>> * Raw data, one line per connected node, kilobytes per second
>> http://pastebin.com/raw.php?i=6b4NuiVQ
>>
>>
>> This does not support the theory that the network has the available
>> bandwidth for increased block sizes, as in its current state 37% of nodes
>> would fail to upload a 20MB block to a single peer in under 20 seconds
>> (referencing a number quoted by Gavin). If the bar for suitability is
>> placed at taking only 1% of the block time (6 seconds) to upload one block
>> to one peer, then 69% of the network fails for 20MB blocks. For comparison,
>> only 10% fail this metric for 1MB blocks.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/48d9276d/attachment.html>

2023-06-07 17:40:09

- reply

📅 Original date posted:2015-06-25
📝 Original message:Thank you very much Mark and Warren this is most helpful.
Regards,
p.
On Thu, Jun 25, 2015 at 2:16 PM, Warren Togami Jr. <wtogami at gmail.com>
wrote:
> https://github.com/pstratem/bitcoin/commits/testnet4
>
> See these two commits for an example of changing all the testnet chain
> parameters to create an entirely separate testnet network. This example
> "testnet4" changed to different port numbers, pchMessageStart magic, and
> with stupid large block sizes.
>
> http://rusty.ozlabs.org/?p=509
> Rusty used this to test block propagation latency.
>
> On Wed, Jun 24, 2015 at 11:06 PM, Pindar Wong <pindar.wong at gmail.com>
> wrote:
>
>> In the process of 'mining consensus', perhaps before voting there should
>> be robust system testing and telemetry.
>>
>> May I ask a questions w.r.t. Process BIPs, what is the process for
>> establishing a new testnet (e.g. for testing with 8MB blocks)?
>>
>> p.
>>
>>
>> On Thu, Jun 25, 2015 at 1:41 PM, Milly Bitcoin <milly at bitcoins.info>
>> wrote:
>>
>>> These are the kind of silly responses you often get when this subject
>>> comes up. Mr. Garzik knows how to ignore messages he doesn't want so I see
>>> no need for him to use the list to attack people he doesn't agree with
>>> and/or try to interfere with discussions of others on the list.
>>> He turns it into a personality discussion rather than a discussion of
>>> Systems Engineering. He also tries to intimate anyone who brings up the
>>> discussion and "punish" them as a lesson to anyone else who may raise the
>>> issue.
>>>
>>> It is interesting that people like that are attracted to a decentralized
>>> system. The reply is simply an attempt at protecting turf which is why
>>> Mr. Garzik's vague replies are never taken seriously on the subject of
>>> decision-making process for the software.
>>>
>>> Russ
>>>
>>>
>>>
>>> On 6/25/2015 1:07 AM, Jeff Garzik wrote:
>>>
>>> Ladies & gents, please do not feed the troll. This has been explained
>>> to Milly multiple times in the past, on previous mailing list & github with
>>> no impact.
>>>
>>>
>>> On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly at bitcoins.info>
>>> wrote:
>>>
>>>> I'm sorry but that is the kind of defensive, cultish response
>>>> everyone gets when they ask that question. If you had a well constructed
>>>> documented process then you would be able to point to it ... but you
>>>> can't. While there are a few bits and pieces scattered about in different
>>>> places there is no coherent plan or process.
>>>>
>>>> It is easy to make statements like "consensus must be unanimous" but
>>>> the issue is that you never have true 100% consensus yet you have to move
>>>> forward in some fashion and everyone has to run software with the same
>>>> consensus rules. The issue is how you move forward is the question that
>>>> nobody wants to answer because (a) it is a hard question to answer and (b)
>>>> developers see it as a threat to their authority/position. If people just
>>>> keep shutting down the discussion with a bunch of cultish stock answers
>>>> then you are never going to move forward with developing some kind of
>>>> process.
>>>>
>>>> From what I can see much of the discussion is personality-driven and
>>>> not based on Computer Science or and defined process. The issue is that a
>>>> personality has changed so the process is perceived to be different and
>>>> some people want to hard fork. Previously, the cultish answer is that
>>>> Bitcoin development is decentralized because people can fork the code. Now
>>>> that some developers want to fork the code suddenly it is a big problem.
>>>> Is forking the code part of the consensus process or is it the work of the
>>>> devil? The fact that there is so much diverse opinion on this shows a
>>>> defined process has never been fully vetted or understood.
>>>>
>>>> I have worked on these processes for many years for projects orders of
>>>> magnitudes larger than Bitcoin. I can absolutely assure you the current
>>>> mishmash does not scale and huge amounts of time are wasted. That should
>>>> be readily apparent from the recent discussions and the recent concern it
>>>> has caused from people outside the developer's inner circle.
>>>>
>>>> Lack of defined process = high risk and wasted effort.
>>>>
>>>> Russ
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 6/24/2015 9:50 PM, Mark Friedenbach 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. We talk about
>>>> it quite often in fact as it is a defining characteristic of how bitcoin is
>>>> developed which differs in some ways from how other open source software is
>>>> developed -- although it remains the same in most other ways.
>>>>
>>>> Changes to the non-consensus sections of Bitcoin Core tend to get
>>>> merged when there are a few reviews, tests, and ACKs from recognized
>>>> developers, there are no outstanding objections, and the maintainer doing
>>>> the merge makes a subjective judgement that the code is ready.
>>>>
>>>> Consensus-changes, on the other hand, get merged into Bitcoin Core
>>>> only after the above criteria are met AND an extremely long discussion
>>>> period that has given all the relevant stakeholders a chance to comment,
>>>> and no significant objections remain. Consensus-code changes are unanimous.
>>>> They must be.
>>>>
>>>> The sort of process that exists in standards bodies for example, with
>>>> working groups and formal voting procedures, has no place where changes
>>>> define the nature and validity of other people's money. Who has the right
>>>> to reach into your pocket and define how you can or cannot spend your
>>>> coins? The premise of bitcoin is that no one has that right, yet that is
>>>> very much what we do when consensus code changes are made. That is why when
>>>> we make a change to the rules governing the nature of bitcoin, we must make
>>>> sure that everyone is made aware of the change and consents to it.
>>>>
>>>> Everyone. Does this work? Does this scale? So far, it does.
>>>> Uncontroversial changes, such as BIP 66, are deployed without issue. Every
>>>> indication is that BIP 66 will complete deployment in the very near future,
>>>> and we intend to repeat this process for more interesting changes such as
>>>> BIP65: CHECKLOCKTIMEVERIFY.
>>>>
>>>> This isn't about no one stepping forward to be the "decider." This is
>>>> about no one having the right to decide these things on the behalf of
>>>> others. If a contentious change is proposed and not accepted by the process
>>>> of consensus, that is because the process is doing its job at rejecting
>>>> controversial changes. It has nothing to do with personality, and
>>>> everything to do with the nature of bitcoin itself.
>>>>
>>>>
>>>> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin < <milly at bitcoins.info>
>>>> milly at bitcoins.info> wrote:
>>>>
>>>>> I have seen this question asked many times. Most developers become
>>>>> defensive and they usually give a very vague 1-sentence answer when this
>>>>> question is asked. It seems to be it is based on personalities rather than
>>>>> any kind of definable process. To have that discussion the personalities
>>>>> must be separated out and answers like "such-and-such wouldn't do that"
>>>>> don't really do much to advance the discussion. Also, the incentive for
>>>>> new developers to come in is that they will be paid by companies who want
>>>>> to influence the code and this should be considered (some developers take
>>>>> this statement as an insult when it is just a statement of the incentive
>>>>> process).
>>>>>
>>>>> The other problem you are having is the lead developer does not want
>>>>> to be a "decider" when, in fact, he is a very significant decider. While
>>>>> the users have the ultimate choice in a practical sense the chief developer
>>>>> is the "decider." Now people don't want to get him upset so nobody wants
>>>>> to push the issue or fully define the process. Now you are left with a
>>>>> broken, unwritten/unspoken process. While this type of thing may work with
>>>>> a small group of developers businesses/investors looking in from the
>>>>> outside will see this as a risk.
>>>>>
>>>>> Until you get passed all the personality-based arguments you are going
>>>>> to have a tough time defining a real process.
>>>>>
>>>>> Russ
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 6/24/2015 7:41 PM, Raystonn wrote:
>>>>>
>>>>>> I would like to start a civil discussion on an undefined, or at least
>>>>>> unwritten, portion of the BIP process. Who should get to vote on approval
>>>>>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of
>>>>>> these voters sufficient for approval? If not, then what is?
>>>>>>
>>>>>> Raystonn
>>>>>> _______________________________________________
>>>>>> bitcoin-dev mailing list
>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/51c533b1/attachment-0001.html>

2023-06-07 17:40:07

- reply

📅 Original date posted:2015-06-25
📝 Original message:In the process of 'mining consensus', perhaps before voting there should be
robust system testing and telemetry.
May I ask a questions w.r.t. Process BIPs, what is the process for
establishing a new testnet (e.g. for testing with 8MB blocks)?
p.
On Thu, Jun 25, 2015 at 1:41 PM, Milly Bitcoin <milly at bitcoins.info> wrote:
> These are the kind of silly responses you often get when this subject
> comes up. Mr. Garzik knows how to ignore messages he doesn't want so I see
> no need for him to use the list to attack people he doesn't agree with
> and/or try to interfere with discussions of others on the list.
> He turns it into a personality discussion rather than a discussion of
> Systems Engineering. He also tries to intimate anyone who brings up the
> discussion and "punish" them as a lesson to anyone else who may raise the
> issue.
>
> It is interesting that people like that are attracted to a decentralized
> system. The reply is simply an attempt at protecting turf which is why
> Mr. Garzik's vague replies are never taken seriously on the subject of
> decision-making process for the software.
>
> Russ
>
>
>
> On 6/25/2015 1:07 AM, Jeff Garzik wrote:
>
> Ladies & gents, please do not feed the troll. This has been explained to
> Milly multiple times in the past, on previous mailing list & github with no
> impact.
>
>
> On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly at bitcoins.info>
> wrote:
>
>> I'm sorry but that is the kind of defensive, cultish response everyone
>> gets when they ask that question. If you had a well constructed documented
>> process then you would be able to point to it ... but you can't. While
>> there are a few bits and pieces scattered about in different places there
>> is no coherent plan or process.
>>
>> It is easy to make statements like "consensus must be unanimous" but the
>> issue is that you never have true 100% consensus yet you have to move
>> forward in some fashion and everyone has to run software with the same
>> consensus rules. The issue is how you move forward is the question that
>> nobody wants to answer because (a) it is a hard question to answer and (b)
>> developers see it as a threat to their authority/position. If people just
>> keep shutting down the discussion with a bunch of cultish stock answers
>> then you are never going to move forward with developing some kind of
>> process.
>>
>> From what I can see much of the discussion is personality-driven and not
>> based on Computer Science or and defined process. The issue is that a
>> personality has changed so the process is perceived to be different and
>> some people want to hard fork. Previously, the cultish answer is that
>> Bitcoin development is decentralized because people can fork the code. Now
>> that some developers want to fork the code suddenly it is a big problem.
>> Is forking the code part of the consensus process or is it the work of the
>> devil? The fact that there is so much diverse opinion on this shows a
>> defined process has never been fully vetted or understood.
>>
>> I have worked on these processes for many years for projects orders of
>> magnitudes larger than Bitcoin. I can absolutely assure you the current
>> mishmash does not scale and huge amounts of time are wasted. That should
>> be readily apparent from the recent discussions and the recent concern it
>> has caused from people outside the developer's inner circle.
>>
>> Lack of defined process = high risk and wasted effort.
>>
>> Russ
>>
>>
>>
>>
>>
>> On 6/24/2015 9:50 PM, Mark Friedenbach 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. We talk about it
>> quite often in fact as it is a defining characteristic of how bitcoin is
>> developed which differs in some ways from how other open source software is
>> developed -- although it remains the same in most other ways.
>>
>> Changes to the non-consensus sections of Bitcoin Core tend to get merged
>> when there are a few reviews, tests, and ACKs from recognized developers,
>> there are no outstanding objections, and the maintainer doing the merge
>> makes a subjective judgement that the code is ready.
>>
>> Consensus-changes, on the other hand, get merged into Bitcoin Core only
>> after the above criteria are met AND an extremely long discussion period
>> that has given all the relevant stakeholders a chance to comment, and no
>> significant objections remain. Consensus-code changes are unanimous. They
>> must be.
>>
>> The sort of process that exists in standards bodies for example, with
>> working groups and formal voting procedures, has no place where changes
>> define the nature and validity of other people's money. Who has the right
>> to reach into your pocket and define how you can or cannot spend your
>> coins? The premise of bitcoin is that no one has that right, yet that is
>> very much what we do when consensus code changes are made. That is why when
>> we make a change to the rules governing the nature of bitcoin, we must make
>> sure that everyone is made aware of the change and consents to it.
>>
>> Everyone. Does this work? Does this scale? So far, it does.
>> Uncontroversial changes, such as BIP 66, are deployed without issue. Every
>> indication is that BIP 66 will complete deployment in the very near future,
>> and we intend to repeat this process for more interesting changes such as
>> BIP65: CHECKLOCKTIMEVERIFY.
>>
>> This isn't about no one stepping forward to be the "decider." This is
>> about no one having the right to decide these things on the behalf of
>> others. If a contentious change is proposed and not accepted by the process
>> of consensus, that is because the process is doing its job at rejecting
>> controversial changes. It has nothing to do with personality, and
>> everything to do with the nature of bitcoin itself.
>>
>>
>> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin < <milly at bitcoins.info>
>> milly at bitcoins.info> wrote:
>>
>>> I have seen this question asked many times. Most developers become
>>> defensive and they usually give a very vague 1-sentence answer when this
>>> question is asked. It seems to be it is based on personalities rather than
>>> any kind of definable process. To have that discussion the personalities
>>> must be separated out and answers like "such-and-such wouldn't do that"
>>> don't really do much to advance the discussion. Also, the incentive for
>>> new developers to come in is that they will be paid by companies who want
>>> to influence the code and this should be considered (some developers take
>>> this statement as an insult when it is just a statement of the incentive
>>> process).
>>>
>>> The other problem you are having is the lead developer does not want to
>>> be a "decider" when, in fact, he is a very significant decider. While the
>>> users have the ultimate choice in a practical sense the chief developer is
>>> the "decider." Now people don't want to get him upset so nobody wants to
>>> push the issue or fully define the process. Now you are left with a
>>> broken, unwritten/unspoken process. While this type of thing may work with
>>> a small group of developers businesses/investors looking in from the
>>> outside will see this as a risk.
>>>
>>> Until you get passed all the personality-based arguments you are going
>>> to have a tough time defining a real process.
>>>
>>> Russ
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 6/24/2015 7:41 PM, Raystonn wrote:
>>>
>>>> I would like to start a civil discussion on an undefined, or at least
>>>> unwritten, portion of the BIP process. Who should get to vote on approval
>>>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of
>>>> these voters sufficient for approval? If not, then what is?
>>>>
>>>> Raystonn
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/1f890e9e/attachment-0001.html>

2023-06-07 17:39:51

- reply

📅 Original date posted:2015-06-24
📝 Original message:Dear Gavin,
Thank you for your kind consideration and for working within the
established BIP process.
http://cointelegraph.com/news/114657/chinese-mining-pools-call-for-consensus-refuse-switch-to-bitcoin-xt
p.
On Wed, Jun 24, 2015 at 9:44 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> This BIP has been assigned number 101 by the BIP editor. I plan on filling
> in the TODOs and will submit it as a pull request to the BIP repository
> today.
>
> > Title: Increase Maximum Block Size
>
> --
> --
> Gavin Andresen
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/74e70804/attachment.html>

2023-06-07 17:38:17

- reply

📅 Original date posted:2015-06-16
📝 Original message:On Tue, Jun 16, 2015 at 9:33 PM, Peter Todd <pete at petertodd.org> wrote:
> On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote:
> > On Tue, Jun 16, 2015 at 2:03 AM, Adam Back <adam at cypherspace.org> wrote:
> > Dear Adam, All:
> >
> > At the community's convenience, it would be an honour to arrange an
> initial
> > open summit to meet with representatives of the Chinese miners in Hong
> Kong
> > (UTC+8) to facilitate a better understand between the different
> > stakeholders of the Bitcoin ecosystem on this important issue. This
> could
> > be arranged for this October, or earlier, if deemed necessary.
>
> Great!
>
> FWIW there Constance Choi and Primavera De Filippi (CC'd) are holding a
> blockchain-tech conference October 14th-15th in Hong Kong as well;
> coordinating your summit with that conference could be useful.
>
> http://blockchainworkshops.org/
>
> This workshop series has been attracting audiences of people looking to
> use blockchain tech in general; many of these use-cases will likely
> involve the Bitcoin blockchain in unpredictable ways. Importantly, these
> ways can drive demand significantly beyond our current assumptions based
> on most demand being consumer-merchant transactions.
>
> In addition, many of the attendees have significant experience with
> regulatory issues and interacting with governments on regulation of
> blockchain tech. Bitcoin faces existential risks to its existence by
> these regulation efforts, which include things like efforts to setup
> industry wide Anti-Money-Laundering/Know-Your-Customer programs,
> including programs that would tie on-chain transactions to identity
> information. Any blocksize discussion needs to be informed by these
> potential threats to usage of the technology, as well as challenges to
> using scaling solutions.
>
> > Remote online participation would be welcome from those who might not be
> > able to attend in person.
> >
> > However, it is hoped that such a meeting would be primarily document
> > driven to facilitate orderly translation, discussion and decision.
>
> Agreed. Pieter Wuille's recent work is a great example of the kind of
> science-driven investigations that need to be done - and haven't been
> done very much - to get us some hard data to make decisions on.
>
Thank you very much Peter for pointing this out! That is very kind of you.
It would be great to work with Constance Choi, Primavera De Filippi, your
goodself and others to make this happen.
As you may know, the Hong Kong Monetary Authority considers bitcoin a
virtual 'commodity' and not a currency per se.
Regards,
p.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/2bb69fb3/attachment.html>

2023-06-07 17:38:16

- reply

📅 Original date posted:2015-06-16
📝 Original message:On Tue, Jun 16, 2015 at 2:03 AM, Adam Back <adam at cypherspace.org> wrote:
> Hi Mike
>
> Well thank you for replying openly on this topic, its helpful.
>
> I apologise in advance if this gets quite to the point and at times
> blunt, but transparency is important, and we owe it to the users who
> see Bitcoin as the start of a new future and the$3b of invested funds
> and $600m of VC funds invested in companies, we owe it to them that we
> be open and transparent here.
>
> I would really prefer on a personal nor professional basis to be
> having this conversation period, never mind in public, but Mike - your
> and Gavin's decision to promote a unilateral hard-fork and code fork
> are extremely high risk for bitcoin and so there remains little
> choice. So I apologise again that we have to have this kind of
> conversation on a technical discussion list. This whole thing is
> hugely stressful and worrying for developers, companies and investors.
>
> I strongly urge that we return to the existing collaborative
> constructive review process that has been used for the last 4 years
> which is a consensus by design to prevent one rogue person from
> inserting a backdoor, or lobbying for a favoured change on behalf of a
> special interest group, or working for bad actor (without accusing you
> of any of those - I understand you personally just want to scale
> bitcoin, but are inclined to knock heads and try to force an issue you
> see, rather than work collaboratively).
>
> For you (and everyone)
>
> - Should there be a summit of some kind, that is open attendance, and
> video recorded so that people who are unable to attend can participate
> too, so that people can present the technical proposals and risks in
> an unbiased way?
>
>
Dear Adam, All:
At the community's convenience, it would be an honour to arrange an initial
open summit to meet with representatives of the Chinese miners in Hong Kong
(UTC+8) to facilitate a better understand between the different
stakeholders of the Bitcoin ecosystem on this important issue. This could
be arranged for this October, or earlier, if deemed necessary.
Remote online participation would be welcome from those who might not be
able to attend in person.
However, it is hoped that such a meeting would be primarily document
driven to facilitate orderly translation, discussion and decision.
p.
> (It is not theoretical question, I may have a sponsor and host - not
> Blockstream, an independent, its a question for everyone, developers,
> users, CTOs, CEOs.)
>
>
>
> So here I come back to more frank questions:
>
> Governance
>
> The rest of the developers are wise to realise that they do not want
> exclusive control, to avoid governance centralising into the hands of
> one person, and this is why they have shared it with a consensus
> process over the last 4 years. No offence but I dont think you
> personally are thinking far enough ahead to think you want personal
> control of this industry. Maybe some factions dont trust your
> motives, or they dont mind, but feel more assured if a dozen other
> people are closely reviewing and have collective review authority.
>
> - Do you understand that attempting to break this process by
> unilateral hard-fork is extremely weakening of Bitcoin's change
> governance model?
>
> - Do you understand that change governance is important, and that it
> is important that there be multiple reviewers and sign-off to avoid
> someone being blackmailed or influenced by an external party - which
> could potentially result in massive theft of funds if something were
> missed?
>
> - Secondarily do you understand that even if you succeed in a
> unilateral fork (and the level of lost coins and market cap and damage
> to confidence is recoverable), that it sets a precedent that others
> may try to follow in the future to introduce coercive features that
> break the assurances of bitcoin, like fungibility reducing features
> say (topically I hear you once proposed on a private forum the concept
> of red-lists, other such proposals have been made and quickly
> abandoned), or ultimately if there is a political process to obtain
> unpopular changes by unilateral threat, the sky is the limit - rewrite
> the social contract at that point without consensus, but by
> calculation that people will value Bitcoin enough that they will
> follow a lead to avoid risk to the system?
>
>
> Security
>
> As you probably know some extremely subtle bugs in Bitcoin have at
> times slipped past even the most rigorous testings, often with
> innocuous but unexpected behaviours, but some security issues Some
> extremely intricate and time-sensitive security defect and incident
> response happens from time to time which is not necessarily publicly
> disclosed until after the issue has been rolled out and fixed, which
> can take some time due to the nature of protocol upgrades,
> work-arounds, software upgrade via contacting key miners etc. We
> could take an example of the openSSL bug.
>
> - How do you plan to deal with security & incident response for the
> duration you describe where you will have control while you are
> deploying the unilateral hard-fork and being in sole maintainership
> control?
>
> - Are you a member of the bitcoin security reporting list?
>
> On 15 June 2015 at 11:56, Mike Hearn <mike at plan99.net> wrote:
> > I will review both and mostly delegate to Gavin's good taste around the
> > details, unless there is some very strong disagreement. But that seems
> > unlikely.
> > ...
> > Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests
> > aren't scored in any way. The final decision rests with the maintainer
> as in
> > ~all open source projects.
>
> As you know the people who have written 95% of the code (and reviewed,
> and tested, and formally proved segments etc) are strenuously advising
> not to push any consensus code into public use without listening to
> and addressing review questions which span beyond rigorous code &
> automated guided fuzz testers, simulation and sometimes formal proofs,
> but also economics, game-theory and critically very subtle
> determinism/consensus safety that they have collectively 4-5 years
> experience of each.
>
> - Will you pause your release plans if all of the other developers
> insist that the code or algorithm is defective?
>
> - Please don't take this the wrong way, and I know your bitcoinj work
> was a significant engineering project which required porting bitcoin
> logic. But If the answer to the above question is no, as you seemed
> to indicate in your response, as you not have not written much bitcoin
> core code yourself (I think 3 PRs in total), do you find yourself more
> qualified than the combination of peer review of the group of people
> who have written 95% of it, and maintained it and refactored most of
> it over the last 4-5 years?
>
> I presume from your security background you are quite familiar with
> the need for review of crypto protocol changes & rigorous code review.
> That is even more the case with Bitcoin given the consensus
> criticality.
>
> >> - On the idea of a non-consensus hard-fork at all, I think we can
> >> assume you will get a row of NACKs. Can you explain your rationale
> >> for going ahead anyway? The risks are well understood and enormous.
> >
> > If Bitcoin runs out of capacity it will break and many of our users will
> > leave. That is not an acceptable outcome for myself or the many other
> > wallet, service and merchant developers who have worked for years to
> build
> > an ecosystem around this protocol.
>
> That you are frustrated, is not a sufficient answer as to why you are
> proposing to go ahead with a universally acknowledged extreme network
> divergence danger unilateral hard-fork, lacking wide-spread consensus.
> People are quite concerned about this. Patience, caution and prudence
> is necessary in a software system with such high assurance
> requirements.
>
> So I ask again:
>
> - On the idea of a non-consensus hard-fork at all, I think we can
> assume you will get a row of NACKs. Can you explain your rationale
> for going ahead anyway? The risks are well understood and enormous.
>
> Note the key point is that you are working on a unilateral hard-fork,
> where there is a clear 4 year established process for proposing
> improvements and an extremely well thought out and important change
> management governance process. While there has been much discussion,
> you nor Gavin, have not actually posted a BIP for review. Nor
> actually was much of the discussion even conducted in the open: it was
> only when Matt felt the need to clear the air and steer this
> conversation into the open that discussion arose here. During that
> period of private discussion you and Gavin were largely unknown to
> most of us lobbying companies with your representation of a method
> that concerns everyone of the Bitcoin users. Now that the technical
> community aware aware they are strenuously discouraging you on the
> basis of risks.
>
>
> Openness
>
> - Do you agree that bitcoin technical discussions should happen in the
> open?
>
> - As this is a FOSS project, do you agree that companies should also
> be open, about their requirements and trade-offs they would prefer?
>
> - Can you disclose the list of companies you have lobbied in private
> whether they have spoken publicly or not, and whether they have
> indicated approval or not?
>
> - Did you share a specific plan, like a BIP or white paper with these
> companies, and if so can we see it?
>
> - If you didnt submit a plan, could you summarise what you asked them
> and what you proposed, and if you discussed also the risks? (If you
> asked them if they would like Bitcoin to scale, I expect almost
> everyone does, including every member of the technical community, so
> that for example would not fairly indicate approval for a unilateral
> hard-fork)
>
> I and others will be happy to talk with the CTO and CEOs of companies
> you have lobbied in private, for balance to assure ourselves and the
> rest of the community that their support was given - and with full
> understanding of the risks of doing it unilaterally, without peer
> review, benefit of maintenance and security inidence management, and
> what exactly they are being quoting as having signed up for.
>
> (This maybe more efficiently and openly achieved by the open process,
> on a mailing list, maybe a different one even special purpose to this
> topic, with additional option of the open public meeting I proposed at
> the top).
>
> - Do you agree that it would be appropriate, that companies be aware
> of both the scaling opportunities (of course, great everyone wants
> scalability) as well as the technical limits and risks with various
> approaches? And that these be presented by parties from a range of
> views to ensure balance?
>
> - Do you consider your expression of issues to hold true to the ideal
> of representing balanced nuanced view of all sides of a technical
> debate, even when under pressure or feeling impatient about the
> process?
>
> You may want to review the opening few minutes of your epicenter 82
> bitcoin for example where you claimed and I quote "[the rest of the
> technical community] dont want capacity to ever increase and want it
> to stay where it is and when it fills up people move to other
> systems".
>
> - Do you think that is an accurate depiction of the complex trade-offs
> we have been discussing on this list?
>
> (For the record I am not aware of a single person who has said they do
> not agree with scaling Bitcoin. Changing a constant is not the
> hard-part. The hard part is validating a plan and the other factors
> that go into it. It's not a free choice it is a security/scalability
> tradeoff. No one will thank us if we "scale" bitcoin but break it in
> hard to recover ways at the same time.)
>
> - Were you similarly balanced in your explanations when talking to
> companies in private discussions?
>
> - Do you understand that if we do not work from balanced technical
> discussion, that we may end up with some biased criteria?
>
> Authority
>
> Neither you nor Gavin have any particular authority here to speak on
> behalf of Bitcoin (eg you acknowledge in your podcast that Wladimir is
> dev lead, and you and Gavin are both well aware of the 4 year
> established change management consensus decision making model where
> all of the technical reviewers have to come to agreement before
> changes go in for security reasons explained above). I know Gavin has
> a "Chief Scientist" title from the Bitcoin Foundation, but sadly that
> organisation is not held in as much regard as it once was, due to
> various irregularities and controversies, and as I understand it no
> longer employs any developers, due to lack of funds. Gavin is now
> employed by MIT's DCI project as a researcher in some capacity. As
> you know Wladimir is doing the development lead role now, and it seems
> part of your personal frustration you said was because he did not
> agree with your views. Neither you nor Gavin have been particularly
> involved in bitcoin lately, even Gavin, for 1.5 years or so.
>
> - Do you agree that if you presume to speak where you do not have
> authority you may confuse companies?
>
> > If Bitcoin runs out of capacity it will break and many of our users will
> > leave. That is not an acceptable outcome for myself or the many other
> > wallet, service and merchant developers who have worked for years to
> build
> > an ecosystem around this protocol.
>
> But I think this is a false dichotomy. As I said in previous mail I
> understand people are frustrated that it has taken so long, but it is
> not the case that no progress has been made on scalability.
>
> I itemised a long list of scalability work which you acknowledged as
> impressive work (CPU, memory, network bandwidth/latency) and RBF, CPFP
> fee work, fee-estimation, and so on, which you acknowledged and are
> aware of.
>
> There are multiple proposals and BIPs under consideration on the list
> right now.
>
> - what is the reason that you (or Gavin) would not post your BIP along
> side the others to see if it would win based on technical merit?
>
> - why would you feel uniquely qualified to override the expert opinion
> of the rest of the technical community if your proposal were not
> considered to have most technical merit? (Given that this is not a
> simple market competition thing where multiple hard-forks can be
> considered - it is a one only decision, and if it is done in a
> divisive unilateral way there are extreme risks of the ledger
> diverging.)
>
> Network Divergence Risk
>
> >> - How do you propose to deal with the extra risks that come from
> >> non-consensus hard-forks? Hard-forks themselves are quite risky, but
> >> non-consensus ones are extremely dangerous for consensus.
> >
> > The approach is the same for other forks. Voting via block versions and
> then
> > when there's been >X% for Y time units the 1mb limit is lifted/replaced.
>
> But this is not a soft-fork, it is a hard-fork. Miner voting is only
> peripherally related. Even if in the extremis 75% of miners tried a
> unilateral hard-fork but 100% of the users stayed on the maintained
> original code, no change would occur other than those miners losing
> reward (mining fork-coins with no resale value) and the difficulty
> would adjust. The miners who made an error in choice would lose money
> and go out of business or rejoin the chain.
>
> However if something in that direction happens with actual users and
> companies on both sides of it users will lose money, the ledger will
> diverge as soon as a single double-spend happens, and never share a
> block again, companies will go instantly insolvent, and chaos will
> break out. This is the dangerous scenario we are concerned about.
>
> So the same question again:
>
> - How do you propose to deal with the extra risks that come from
> non-consensus hard-forks? Hard-forks themselves are quite risky, but
> non-consensus ones are extremely dangerous for consensus.
>
>
> Being sensitive to alarming the market
>
> It is something akin to Greece or Portugal or Italy exiting the euro
> currency in a disorderly way. Economists and central bank policy
> makers are extremely worried about such an eventuality and talk about
> related factors in careful, measured terms, watch Mario Draghi when he
> speaks.
>
> Imagine that bitcoin is 10x or 100x bigger. Bitcoin cant have people
> taking unilateral actions such as you have been proposing. It is not
> following the consensus governance process, and not good policy and it
> is probably affecting bitcoin confidence and price at this moment.
>
> >> - Do you have contingency plans for what to do if the non-consensus
> >> hard-fork goes wrong and $3B is lost as a result?
> >
> > Where did you get the $3B figure from? The fork either doesn't happen,
> or it
> > happens after quite a long period of people knowing it's going to happen
> -
> > for example because their full node is printing "You need to upgrade"
> > messages due to seeing the larger block version, or because they read the
> > news, or because they heard about it via some other mechanisms.
>
> This is not a soft-fork, and the community will not want to take the
> risks once they understand them, and they have months in which to
> understand them and at this point you've motivated and wasted 100s of
> developer man hours such that we will feel impelled to make sure that
> no one opts into a unilateral hard-fork without understanding the
> risks. It would be negligent to allow people to do that. Before this
> gets very far FAQs will be on bitcoin.org etc explaining this risk I
> would imagine. Its just starting not finished.
>
> What makes you think the rest of the community may not instead prefer
> Jeff Garzik's BIP after revisions that he is making now with review
> comments from others?
>
> Or another proposal. Taken together with a deployment plan that sees
> work on decentralisation tying into that plan.
>
> - If you persisted anyway, what makes you think bitcoin could not make
> code changes defensively relating to your unilateral fork?
> (I am sure creative minds can find some ways to harden bitcoin against
> a unilateral fork, with a soft-fork or non-consensus update can be
> deployed much faster than a hard-fork).
>
> I tried to warn Gavin privately that I thought he was under-estimating
> the risk of failure to his fork proposal due to it being unilateral.
> Ie as you both seem sincere in your wish to have your proposal
> succeed, then obviously the best way to do that is to release a BIP in
> the open collaborative process and submit it to review like everyone
> else. Doing it unilaterally only increases its chance of failure.
>
> The only sensible thing to do here is submit a BIP and stop the
> unilateral fork threat.
>
> Scalability Plans
>
> > Let me flip the question around. Do you have a contingency plan if
> Bitcoin
> > runs out of capacity and significant user disruption occurs that results
> in
> > exodus, followed by fall in BTC price? The only one I've seen is "we can
> > perform an emergency hard fork in a few weeks"!
>
> Yes people have proposed other plans. Bryan Bishop posted a list of them.
>
> Jeff Garzik has a proposal, BIP-100 which seems already better than
> Gavin's having benefit of peer review which he has been incorporating.
>
> I proposed several soft-fork models which can be deployed safely and
> immediately, which do not have ledger risk.
>
> I have another proposal relating to simplified soft-fork one-way pegs
> which I'll write up in a bit.
>
> I think there are still issues in Jeff's proposal but he is very open
> and collaborating and there maybe related but different proposals
> presently.
>
> >> As you can probably tell I think a unilateral fork without wide-scale
> >> consensus from the technical and business communities is a deeply
> >> inadvisable.
> >
> > Gavin and I have been polling many key players in the ecosystem. The
> > consensus you seek does exist. All wallet developers (except Lawrence),
> all
> > the major exchanges, all the major payment processors and many of the
> major
> > mining pools want to see the limit lifted (I haven't been talking to
> pools,
> > Gavin has).
>
> It does not seem to me that you understand the issue. Of course they
> want to increase the scalability of bitcoin. So does everyone else on
> this mailing list.
>
> That they would support that is obvious. If you presented your
> unilateral action plan without explaining the risks too.
>
> I think I covered this further above. If you would like to share the
> company list, or we can invite them to the proposed public physical
> meeting, I think it would be useful for them to have a balanced view
> of the ledger divergence risks, and alternative in-consensus proposals
> underway, as well as the governance risks, maintenance risks, security
> incident risks.
>
> Note that other people talk to companies too, as part of their day to
> day jobs, or from contacts from being in the industry. You have no
> special authority or unique ability to talk with business people. Its
> just that the technical community did not know you were busy doing
> that.
>
> I can not believe that any company that would listen to their CTO, CSO
> or failing that board would be ok with the risks implied by what you
> are proposing on full examination.
>
> > This notion that the change has no consensus is based on you polling the
> > people directly around you and people who like to spend all day on this
> > mailing list. It's not an accurate reflection of the wider Bitcoin
> community
> > and that is one of the leading reasons there is going to be a fork. A
> small
> > number of people have been flatly ignoring LOTS of highly technical and
> > passionate developers who have written vast amounts of code, built up the
> > Bitcoin user base, designed hardware and software, and yes built
> companies.
>
> I know you want scale bitcoin, as I said everyone here does. I think
> what you're experiencing is that you've had more luck explaining your
> pragmatic unilateral plan to non-technical people without peer review,
> and so not experienced the kind of huge pushback you are getting from
> the technical community. The whole of bitcoin is immensely
> complicated such that it takes an uber-geek CS genius years to
> catchup, this is not a slight of any of the business people who are
> working hard to deploy Bitcoin into the world, its just complicated
> and therefore not easy to understand the game-theory, security,
> governance and distributed system thinking. I have a comp sci PhD in
> distributed systems, implemented p2p network systems and have 2
> decades of applied crypto experience with a major interest in
> electronic cash crypto protocols, and it took me a several years to
> catchup and even I have a few hazy spots on low-level details, and I
> addictively into read everything I could find. Realistically all of
> us are still learning, as bitcoin combines so many fields that it
> opens new possibilities.
>
> What I am expecting that yourself and Gavin are thinking is that
> you'll knock heads and force the issue and get to consensus.
>
> However I think you have seriously misjudged the risks and have not
> adequately explained them to companies you are talking with. Indeed
> you do not fully seem to acknowledge the risks, nor to have a well
> thought out plan here of how you would actually manage it, nor the
> moral hazards of having a lone developer in hugely divisive
> circumstances in sole control of bitcoins running code. Those are
> exactly the reasons for the code change governance process!
>
> Even though you are trying to help, the full result is you are not
> helping achieve anything by changing a constant and starting a
> unilateral hard-fork (not to trivialise the work of making a patch to
> do that).
>
> The work to even make the constant change be feasible was a result of
> 1000s of hours of work by others in the development community, that is
> emphatically and unilaterally telling you that hard-forks are hugely
> inadvisable.
>
> You are trying to break the code change governance security procedure
> that were put in place for good reason for the security of $3b of
> other peoples money, even if you have a pragmatic intent to help, this
> is flat out unacceptable.
>
> There are also security implications to what you are proposing, which
> I have heard you attempting to trivialise, that are core to Bitcoins
> security and core functionality.
>
> > the overwhelming impression I get from a few
> > others here is that no, they don't want to scale Bitcoin. They already
> > decided it's a technological dead end.
>
> I think this is a significant mischaracterisation, and I think almost
> everybody is on board with a combination plan:
>
> 1. work to improve decentralisation (specific technical work already
> underway, and education)
> 2. create a plan to increase block-size in a slow fashion to not cause
> system shocks (eg like Jeff is proposing or some better variant)
> 3. work on actual algorithmic scaling
>
> In this way we can have throughput needed for scalability and security
> work to continue.
>
> As I said you can not scale a O(n^2) broadcast network by changing
> constants, you need algorithmic improvements.
>
> People are working on them already. All of those 3 things are being
> actively worked on RIGHT NOW, and in the case of algorithmic scaling
> and improve decentralisation have been worked on for months.
>
> You may have done one useful thing which is to remind people that
> blocks are only 3x-4x below capacity such that we should look at it.
>
> But we can not work under duress of haste, nor unilateral ultimatums,
> this is the realm of human action that leads to moral hazard, and
> ironically reminds us of why Satoshi put the quote in the genesis
> block.
>
> Bitcoin is too complex a system with too much at stake to be making
> political hasty decisions, it would be negligent to act in such a way.
>
> Again please consider that you did your job, caused people to pay
> attention, but return to the process, submit a BIP, retract the
> unilateral hard-fork which is so dangerous and lets have things be
> calm, civil and collaborative in the technical zone of Bitcoin and not
> further alarm companies and investors.
>
> Adam
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/0d9b09eb/attachment.html>

2023-06-07 17:36:32

- reply

📅 Original date posted:2015-06-03
📝 Original message:On Wed, Jun 3, 2015 at 10:33 AM, Stephen Morse <stephencalebmorse at gmail.com>
wrote:
> Pindar,
>
> yes and it's a good idea to separate the hard/soft fork upgrades. The
>> point being here is that we're also establishing a process for the
>> community to self-determine the way forward in a transparent and verifiable
>> manner.
>>
>> What's not to like? :)
>>
>> I'll probably have some time on Sunday to help hack something up but I
>> don't think this is that heavy a coding lift? What am I missing?
>>
>
> As Matt mentioned, many members of the bitcoin community would be hesitant
> about giving miners this much power.
>
I understand this concern and it's a valid one, including other dimensions
such as better decentralization. Some might argue that the mining pools in
China currently have such power and that's a bad thing:-
https://blockchain.info/pools
I happen to think that it's unhealthy for the network but the irony is
that they are huge bitcoin fanbase that perhaps should be involved in this,
and other, decisions. The question is how.
Thus far our friends from f2pool have chimed in with some data from their
perspective. It would be interesting to hear from the others and I'm
finding ways to do exactly that.
So let's find a way to involve, and not alienate them or others. Let's find
a way to get more data and test assumptions and boundaries.
It essentially lets them vote to change the rules of the system.
>
It's data and yes, it gives then a very visible, verifiable 'vote' ...
though I prefer to think of this as 'voice' as in a ' hummmm. '
But miners are not the only part of this ecosystem, and they are not the
> only ones affected by the choice of block size limit, so they probably
> shouldn't be the only ones with a vote.
>
I fully agree and it doesn't have to be the only voice ... think 'choir'
... after all this is an ecosystem with each party playing their
respective roles. But sustainable ecosystems have 'keystone' species, and I
believe these to be the 'honest' miners that help secure the network.
Instead, we vote with the software we run, and all upgrade.
>
or not as the case may be. I think we're trying to find a level of rough
consensus where members of the community feel comfortable enough to do this
upgrade in their respective codebase.
>
> So, while I think an idea like this has its merits, I would bet that it's
> fairly unlikely to get enough support to be merged into bitcoin core.
>
Bitcoin was 'unlikely' ... yet it happened.
Nevertheless you raise the possibility of a different possible path forward
and that's positive. So thank you for doing that!
Bitcoin's humming in China, behind an GFW ... who could have guessed?
'Connect and Liberate' :)
p.
>
> Best,
> Stephen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150603/addc9f1d/attachment.html>

2023-06-07 17:36:04

- reply

📅 Original date posted:2015-06-01
📝 Original message:I think it would be helpful if we could all *chill* and focus on the solid
engineering necessary to make Bitcoin succeed.
p.
On Mon, Jun 1, 2015 at 7:02 PM, Chun Wang <1240902 at gmail.com> wrote:
> On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn <mike at plan99.net> wrote:
> > Whilst it would be nice if miners in China can carry on forever
> regardless
> > of their internet situation, nobody has any inherent "right" to mine if
> they
> > can't do the job - if miners in China can't get the trivial amounts of
> > bandwidth required through their firewall and end up being outcompeted
> then
> > OK, too bad, we'll have to carry on without them.
> >
> > But I'm not sure why it should be a big deal. They can always run a node
> on
> > a server in Taiwan and connect the hardware to it via a VPN or so.
>
> Ignorant. You seem do not understand the current situation. We
> suffered from orphans a lot when we started in 2013. It is now your
> turn. If Western miners do not find a China-based VPN into China, or
> if Western pools do not manage to improve their connectivity to China,
> or run a node in China, it would be them to have higher orphans, not
> us. Because we have 50%+.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/e773ec57/attachment.html>

2023-06-07 17:36:03

- reply

📅 Original date posted:2015-06-01
📝 Original message:Two very valid and important points. Thank you for making these
observations Peter.
p.
On Mon, Jun 1, 2015 at 7:26 PM, Peter Todd <pete at petertodd.org> wrote:
> On Mon, Jun 01, 2015 at 06:42:05PM +0800, Pindar Wong wrote:
> > On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn <mike at plan99.net> wrote:
> >
> > > Whilst it would be nice if miners in China can carry on forever
> regardless
> > > of their internet situation, nobody has any inherent "right" to mine if
> > > they can't do the job - if miners in China can't get the trivial
> amounts of
> > > bandwidth required through their firewall and end up being outcompeted
> then
> > > OK, too bad, we'll have to carry on without them.
> > >
> >
> > I'd rather think of mining as a responsibility than a right per se, but
> > you're right in so far as it's competitive and self-correcting.
>
> It's important to remember that the service Bitcoin miners are providing
> us is *not* transaction validation, but rather decentralization.
> Validation is something every full node does already; there's no
> shortage of it. What's tricky is designing a Bitcoin protocol that
> creates the appropriate incentives for mining to remain decentralized,
> so we get good value for the large amount of money being sent to miners.
>
> I've often likened this task to building a robot to go to the grocery
> store to buy milk for you. If that robot doesn't have a nose, before
> long store owners are going to realise it can't tell the difference
> between unspoilt and spoilt milk, and you're going to get ripped off
> paying for a bunch of spoiled milk.
>
> Designing a Bitcoin protocol where we expect "competition" to result in
> smaller miners in more geographically decentralized places to get
> outcompeted by larger miners who are more geographically centralized
> gets us bad value for our money. Sure it's "self-correcting", but not in
> a way that we want.
>
> > > But I'm not sure why it should be a big deal. They can always run a
> node
> > > on a server in Taiwan and connect the hardware to it via a VPN or so.
> > >
> > >
> > Let's agree to disagree on this point.
>
> Note how that VPN, and likely VPS it's connected too, immediately adds
> another one or two points of failure to the whole system. Not only does
> this decrease reliability, it also decreases security by making attacks
> significantly easier - VPS security is orders of magnitude worse than
> the security of physical hardware.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000e187b95a9159d04a3586dd4cbc068be88a3eafcb5b885f9
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/495ef5e9/attachment.html>

2023-06-07 17:36:02

- reply

📅 Original date posted:2015-05-31
📝 Original message:On Mon, Jun 1, 2015 at 7:58 AM, Ricardo Filipe <ricardojdfilipe at gmail.com>
wrote:
> 2015-06-01 0:40 GMT+01:00 Pindar Wong <pindar.wong at gmail.com>:
> >
> >
> > On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe <
> ricardojdfilipe at gmail.com>
> > wrote:
> >>
> >> He also said that the equation for miners has many variables, as it
> >> should. There is no disadvantage if the network speed is the same
> >> between the miners.
> >
> >
> > Hi,
> >
> > Is that an assumption?
> no, let me rephrase: The disadvantage alex refers to only exists if
> miners do not have the same network speed.
>
> >
> >> If there is a difference in network speed, the
> >> miner is incentivized to invest in their network infrastructure.
> >
> >
> > Perhaps it's best not to assume that investing in Internet network
> > infrastructure's a free or open market everywhere.
> Just like easy ASIC access, low price electricity, etc are not a free
> and open market.
>
-- point well made and taken.
p.
>
> >
> > p.
> >
> >>
> >>
> >> 2015-05-31 23:55 GMT+01:00 Alex Mizrahi <alex.mizrahi at gmail.com>:
> >> >> Yes, if you are on a slow network then you are at a (slight)
> >> >> disadvantage.
> >> >> So?
> >> >
> >> >
> >> > Chun mentioned that his pool is on a slow network, and thus bigger
> >> > blocks
> >> > give it an disadvantage. (Orphan rate is proportional to block size.)
> >> > You said that no, on contrary those who make big blocks have a
> >> > disadvantage.
> >> > And now you say that yes, this disadvantage exist.
> >> >
> >> > Did you just lie to Chun?
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >
> >> > _______________________________________________
> >> > Bitcoin-development mailing list
> >> > Bitcoin-development at lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/80dd82e6/attachment.html>

2023-06-07 17:35:59

- reply

📅 Original date posted:2015-05-31
📝 Original message:On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe <ricardojdfilipe at gmail.com>
wrote:
> He also said that the equation for miners has many variables, as it
> should. There is no disadvantage if the network speed is the same
> between the miners.
Hi,
Is that an assumption?
If there is a difference in network speed, the
> miner is incentivized to invest in their network infrastructure.
>
Perhaps it's best not to assume that investing in Internet network
infrastructure's a free or open market everywhere.
p.
>
> 2015-05-31 23:55 GMT+01:00 Alex Mizrahi <alex.mizrahi at gmail.com>:
> >> Yes, if you are on a slow network then you are at a (slight)
> disadvantage.
> >> So?
> >
> >
> > Chun mentioned that his pool is on a slow network, and thus bigger blocks
> > give it an disadvantage. (Orphan rate is proportional to block size.)
> > You said that no, on contrary those who make big blocks have a
> disadvantage.
> > And now you say that yes, this disadvantage exist.
> >
> > Did you just lie to Chun?
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/913e7526/attachment.html>

2023-06-07 17:35:57

- reply

📅 Original date posted:2015-05-30
📝 Original message:Thank you very much Chun Wang for the details below.
While I'm based in HK, but I'd like to propose that the miners in China
work together with Gavin and others to run an experiment of sorts next
month to gather more details for the community.
p.
On Sun, May 31, 2015 at 9:31 AM, Chun Wang <1240902 at gmail.com> wrote:
> On Sat, May 30, 2015 at 9:57 PM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
> >> Bad miners could attack us and the network with artificial
> >> big blocks.
> >
> >
> > How?
> >
> > I ran some simulations, and I could not find a network topology where a
> big
> > miner producing big blocks could cause a loss of profit to another miner
> > (big or small) producing smaller blocks:
> >
> > http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
> >
> > (the 0.3% advantage I DID find was for the situation where EVERYBODY was
> > producing big blocks).
>
> If someone propagate a 20MB block, it will take at best 6 seconds for
> us to receive to verify it at current configuration, result of one
> percent orphan rate increase. Or, we can mine the next block only on
> the previous block's header, in this case, the network would see many
> more transaction-less blocks.
>
> Our orphan rate is about 0.5% over the past few months. If the network
> floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB
> block could contain an average of 50000 transactions, hundred of
> thousands of sigops, Do you have an estimate how long it takes on the
> submitblock rpccall?
>
> For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars
> per month. We also use Aliyun and Linode cloud services for block
> propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for
> 100Mbps connectivity at Aliyun. For a single cross-border TCP
> connection, it would be certainly far slower than 12.5 MB/s.
>
> I think we can accept 5MB block at most.
>
> (sorry forgot to cc to the mailing list)
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150531/0a109f73/attachment.html>

2023-06-07 17:33:44

- reply

📅 Original date posted:2015-05-30
📝 Original message:On Sat, May 30, 2015 at 9:57 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> On Fri, May 29, 2015 at 7:42 PM, Chun Wang <1240902 at gmail.com> wrote:
>
>> Hello. I am from F2Pool. We are currently mining the biggest blocks on
>> the network.
>
>
> Thanks for giving your opinion!
>
>
>
>> Bad miners could attack us and the network with artificial
>> big blocks.
>
>
> How?
>
> I ran some simulations, and I could not find a network topology where a
> big miner producing big blocks could cause a loss of profit to another
> miner (big or small) producing smaller blocks:
>
> http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
>
> (the 0.3% advantage I DID find was for the situation where EVERYBODY was
> producing big blocks).
>
>
>> We think
>> the max block size should be increased, but must be increased
>> smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
>> and so on. Thanks.
>
>
> Why 2 MB ? You said that server bandwidth is much more expensive in
> China; what would be the difference in your bandwidth costs between 2MB
> blocks and 20MB blocks?
>
Perhaps we should arrange to run some more 'simulations' with miners from
China and elsewhere?
Let me know there's interest to do.
p.
>
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150530/527c779b/attachment.html>

2023-06-07 17:31:47

- reply

📅 Original date posted:2015-03-11
📝 Original message:Understood... perhaps just add something like:
'After copy-editing and acceptance,* a BIP number is assigned* and it will
be published here.'?
https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals
p.
On Thu, Mar 12, 2015 at 7:34 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, Mar 11, 2015 at 11:24 PM, Pindar Wong <pindar.wong at gmail.com>
> wrote:
> > Perhaps at some point consider introducing something akin to a
> > 'Bitcoin-Draft' (BD) status with some autoexpiry period?
> >
> > I understand that the Internet Engineering Task Force (IETF) has the
> > concept of 'Internet Drafts" (ID) and this looks like it has worked for
> them
> > so far.
>
> Thats more or less what posting to the list is supposed to be.
> Creating a draft document requires no approval, beyond filling out the
> right form.
>
> Perhaps calling out that as a distinct step would be better, indeed.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/35027fd0/attachment.html>

2023-06-07 17:31:42

- reply

📅 Original date posted:2015-03-08
📝 Original message:*Spendid* work Andrew (and all the other authors). Well done.
This is a timely paper that deserves significantly wider circulation and
comment.
FWIW, Joichi Ito, from the MIT media Lab, made reference to your work
during yesterday's MIT Bitcoin Expo
<https://www.youtube.com/watch?v=lIgjogLipvk>[@ 2:46:54]
p.
On Wed, Mar 4, 2015 at 11:28 PM, Mike Hearn <mike at plan99.net> wrote:
> Nice, Andrew.
>
> Just one minor point. SPV clients do not need to maintain an ever growing
> list of PoW solutions. BitcoinJ uses a ring buffer with 5000 headers and
> thus has O(1) disk usage. Re-orgs past the event horizon cannot be
> processed but are assumed to be sufficiently rare that manual intervention
> would be acceptable.
>
> On Mon, Mar 2, 2015 at 8:48 AM, Andrew Miller <amiller at cs.umd.edu> wrote:
>
>> We (Joseph Bonneau, myself Arvind Narayanan, Jeremy Clark, Ed Felten,
>> Josh Kroll -- from Stanford, Maryland, Concordia, Princeton) have
>> written a “systemization” paper about Bitcoin-related research. It’s
>> going to appear in the Oakland security conference later this year
>> (IEEE Security and Privacy) but we wanted to announce a draft to this
>> community ahead of time.
>>
>> http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf
>>
>> One of the main goals of our work is to build a bridge between the
>> computer science research community and the cryptocurrency community.
>> Many of the most interesting ideas and proposals for Bitcoin come from
>> this mailing list and forums/wikis/irc channels, where many academic
>> researchers simply don’t know to look! In fact, we started out by
>> scraping all the interesting posts/articles we could find and trying
>> to figure out how we could organize them. We hope our paper helps some
>> of the best ideas and research questions from the Bitcoin community
>> bubble up and inspires researchers to build on them.
>>
>> We didn’t limit our scope to Bitcoin, but we also decided not to
>> provide a complete survey of altcoins and other next-generation
>> cryptocurrency designs. Instead, we tried to explain all the
>> dimensions along which these designs differ from Bitcoin.
>>
>> This effort has roughly been in progress over two years, though it
>> stopped and restarted several times along the way.
>>
>> If anyone has comments or suggestions, we still have a week before the
>> final version is due, and regardless we plan to continue updating our
>> online version for the forseeable future.
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150308/204de424/attachment.html>