Pindar Wong [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-03-08 to 2021-04-23
💬 Posted a total of 32 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 22: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:32:13

- reply

📅 Original date posted:2015-08-02
📝 Original message:Dear Jim,
Thank you for sharing your view w.r.t. the so called 'Chinese Miners'.
Diversity of opinion, and mining, are IMHO both good and it's indeed a
free world.... so others who wish to mine bitcoin should be encouraged to
make the capital and technical investments to do so.
May I ask what is your technical suggestion to move this discussion forward
beyond your anti-Chinese/anti-China rhetoric? e.g. I would be
particularly grateful if you could share your views w.r.t. colluding miner
attacks in draft 0.5.9. of Joseph Poon and Thaddeus Dryja's 'Lightning
network' paper, found here:-
http://lightning.network/lightning-network-paper.pdf
Respectfully,
p.
On Mon, Aug 3, 2015 at 4:02 AM, Jim Phillips via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> China is a communist country. It is no secret that all "capitalist"
> enterprises are essentially State controlled, or at the very least are
> subject to nationalization should the State deem it necessary. Most ASIC
> chips are manufactured in China, so they are cheap and accessible to
> Chinese miners. Electricity is subsidized and essentially free. Cooling is
> not an issue since large parts of China are mountainous and naturally cool.
> In short the Chinese miners have HUGE advantages over all other mining
> operations. This is probably why, between just the top 4 Chinese miners,
> the People's Republic of China effectively controls 57% of all the Bitcoin
> being mined.
>
> The ONLY disadvantage the Chinese miners have in competing with the rest
> of the world is bandwidth. China has poor connectivity with the rest of the
> world, and Chinese miners have said that an increase in the block size
> would be detrimental to them. I say, GOOD! Most of the free world has
> enough bandwidth to be able to handle larger blocks. We need to take
> advantage of that fact to get mining out of the centralized control of the
> Chinese.
>
> If you're truly worried about larger blocks causing centralization, think
> about how, by restricting blocksize, you're enabling the Communist Chinese
> government to maintain centralized control over 57% of the Bitcoin hashing
> power.
>
> --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
> <http://www.linkedin.com/in/ergophobe>
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
> -- David Ogilvy*
>
> *This message was created with 100% recycled electrons. Please think
> twice before printing.*
>
> _______________________________________________
> 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/20150803/0d2a5eef/attachment-0001.html>

2023-06-07 15: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 15: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 15: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 15: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 15: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 15: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>