R E Broadley [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-06-02 to 2021-05-09
💬 Posted a total of 4 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 22:52:41

- reply

📅 Original date posted:2021-05-09
📝 Original message:According to this paper:
https://www.cs.umd.edu/projects/coinscope/coinscope.pdf
PoW is also only resilient to 1/3rd of the network.
On Sat, 8 May 2021 at 14:46, Eric Martindale via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Mr. Singh,
>
> Proof of Stake is only resilient to ⅓ of the network demonstrating a
Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold.
You can explore prior research here:
https://download.wpsoftware.net/bitcoin/pos.pdf
>
> Independent of the security thresholds, Proof of Stake requires other
trade-offs which are incompatible with Bitcoin's objective (to be a
trustless digital cash) — specifically the famous "security vs. liveness"
guarantee. Digital cash is not useful if it must be globally halted to
ensure its security, and Proof of Work squarely addresses this concern.
>
> Above and beyond any security consideration, Proof of Stake incentivizes
the accumulation of wealth within a small set of actors, which is
undesirable for the long-term health of any such network. If we are to
free humanity from the tyranny of the State, we must do so by protecting
the rights of every individual to hold and preserve their own value,
without trusting any third party. Entrusting the health of the network to
the "economic elite" is the paramount evil with respect to Bitcoin's
objectives, nevermind that Proof of Work relies on energy expenditure to
provide its security.
>
> Sincerely,
>
> Eric Martindale, relentless maker.
> Founder & CEO, Fabric, Inc.
> +1 (919) 374-2020
>
>
> On Fri, May 7, 2021 at 6:50 PM SatoshiSingh via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hello list,
>>
>> I am a lurker here and like many of you I worry about the energy usage
of bitcoin mining. I understand a lot mining happens with renewable
resources but the impact is still high.
>>
>> I want to get your opinion on implementing proof of stake for bitcoin
mining in future. For now, proof of stake is still untested and not battle
tested like proof of work. Though someday it will be.
>>
>> In the following years we'll be seeing proof of stake being implemented.
Smaller networks can test PoS which is a luxury bitcoin can't afford.
Here's how I see this the possibilities:
>>
>> 1 - Proof of stake isn't a good enough security mechanism
>> 2 - Proof of state is a good security mechanism and works as intended
>>
>> IF PoS turns out to be good after battle testing, would you consider
implementing it for Bitcoin? I understand this would invoke a lot of
controversies and a hard fork that no one likes. But its important enough
to consider a hard fork. What are your opinions provided PoS does work?
>>
>> Love from India.
>> _______________________________________________
>> 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/20210509/120dd43f/attachment-0001.html>

2023-06-07 22:52:37

- reply

📅 Original date posted:2021-05-09
📝 Original message:On Sat, 8 May 2021 at 15:36, Karl via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin would get better mainstream public reputation if the block reward were reduced to reduce mining. This would quickly and easily reduce energy expenditure.
You're in luck then, as the block reward is being reduced by 50%, every 4 years.

2023-06-07 18:29:29

- reply

📅 Original date posted:2021-03-12
📝 Original message:Can I just point out (to those addressing James as Lord/Excelency/etc
that he isn't noble nor a Lord, so just wanted to mention this in case
people were giving him more attention than the average person would be
afforded.
My 2p (an equal 2p) on Taproot is ACK, by the way.
On Thu, 11 Mar 2021 at 00:49, Keagan McClelland via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> LORD HIS EXCELLENCY,
>
> This isn't different with Taproot either. When you spend a P2SH output you reveal the script. In Taproot you reveal the portion of the script that is relevant to allowing you to spend it. There is no value to specifying the other possible conditions that could have moved the coins because, after all, you aren't invoking those clauses to move the coins. I am showing you my fingertip, and pointing to my finger tip, the palm is not relevant.
>
> Keagan
>
> On Wed, Mar 10, 2021 at 2:11 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Good Afternoon,
>>
>> You cannot liken the ability to scrutinise the public ledger to be the same as hiding information, it is like showing your palm while you are pointing at the back of your hand. The advice that I have is P2SH is scrutable once the UTXO is spent. Also, there is no public ledger obfuscation in creating new addresses, there is a plausible reduction in transaction linkage.
>>
>> KING JAMES HRMH
>> Great British Empire
>>
>> Regards,
>> The Australian
>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>> of Hougun Manor & Glencoe & British Empire
>> MR. Damian A. James Williamson
>> Wills
>>
>> et al.
>>
>>
>> Willtech
>> www.willtech.com.au
>> www.go-overt.com
>> and other projects
>>
>> earn.com/willtech
>> linkedin.com/in/damianwilliamson
>>
>>
>> m. 0487135719
>> f. +61261470192
>>
>>
>> This email does not constitute a general advice. Please disregard this email if misdelivered.
>> ________________________________
>> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Ryan Grant via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
>> Sent: Saturday, 6 March 2021 1:04 AM
>> To: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] Taproot NACK
>>
>> On Thu, Mar 4, 2021 at 8:48 PM LORD HIS EXCELLENCY JAMES HRMH via
>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > My concern was that the more complex scripts allow obfuscation of the Pay To address
>>
>> This is no different from options available in P2SH, or from the
>> obfuscation achieved by generating a new address for a payment.
>> _______________________________________________
>> 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

2023-06-07 18:02:16

- reply

📅 Original date posted:2017-06-02
📝 Original message:Miner signalling is not enough to avoid two forks - as has been proven in
the past (e.g. when miners signaled they were fully validating blocks when
there we in fact only validating headers). To really protect against two
forks happening, the code needs to detect this happening (i.e. monitor the
other fork) and if it's clear that the signalling was dishonest, then it
needs to abort, IMHO.
On Thu, Apr 6, 2017 at 10:42 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The 95% miner signaling is important to prevent two Bitcoin forks, such as
> what happened with Ethereum HF and Ethereum Classic.
>
> Bitcoin has a very slow difficulty re-targeting algorithm. A fork that has
> just 95% miner support will initially (for 2016 blocks) be 5% slower (an
> average block every 10 minutes and 30 seconds). The transaction capacity of
> the new Bitcoin protocol is reduced only 5%.
> However the chain with 5% if the hashing power not only has a 20x capacity
> reduction, but confirms transactions in 20x more time. So the mempool will
> grow 400 times. It must be noted that fees increased 10x from the moment
> blocks were half full, to the moment blocks became saturated. I'm sure no
> Bitcoin (pre-fork) user will be willing to pay 100x times the transaction
> fees to use such a slow and insecure network.
>
> So a 6-block confirmation will take 20 hours in the original chain and the
> original chain will be in this almost useless slow state for an average of
> 2016 blocks, or 280 days.
> If the original blockchain hard-forks to re-adjust the difficulty, then it
> will just represent an alt-coin having 5% of Bitcoin community, and it
> can't affect Bitcoin (the segwit2mb fork).
>
>
> On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak <btcdrak at gmail.com> wrote:
>
>> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> The hard-fork is conditional to 95% of the hashing power has approved
>>> the segwit2mb soft-fork and the segwit soft-fork has been activated (which
>>> should occur 2016 blocks after its lock-in time)
>>>
>>
>> Miners signalling they have upgraded by flipping a bit in the nVersion
>> field has little relevance in a hard fork. If 100% of the hash power
>> indicates they are running this proposal, but the nodes don't upgrade, what
>> will happen?
>>
>> For the record, I actually talk a lot about hard forks with various
>> developers and am very interested in the research that Johnson in
>> particular is pioneering. However, I have failed to understand your point
>> about 95% miner signalling in relation to a hard fork, so I am eagerly
>> awaiting your explanation.
>>
>
>
> _______________________________________________
> 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/20170602/ee6c0677/attachment.html>