<unnamed>

Public Key

npub1pynqzktaxz4ffsv8w0ju86anmqmfjau252vwd43nmw0qdk3xrmtskld7pp

Profile Code

nprofile1qqsqjfspt97np255cxrh8ewraweasd5ew7929x8x6ceah8sxmgnpa4cpzpmhxue69uhkummnw3ezuamfdejs4j22nl

Publishing to

nostr.wine

Last Notes

2023-06-07 22:52:41 UTC

- reply

📅 Original date posted:2021-05-08
📝 Original message: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. <https://fabric.fm>
+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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210508/28d52c41/attachment-0001.html>

2023-06-07 22:52:04 UTC

- reply

📅 Original date posted:2021-04-23
📝 Original message:ACK. Kalle has been exceptional throughout his contributions — especially
thankful for btcdeb 🙏
On Fri, Apr 23, 2021, 3:51 AM Pindar Wong via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
>>
> _______________________________________________
> 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/40b1cafb/attachment-0001.html>

2023-06-07 18:30:23 UTC

- reply

📅 Original date posted:2021-03-15
📝 Original message:Bitcoin's security is derived from the energy consumption of mining, so
reducing the overall expenditure would be an objective decrease in
resilience. As a miner, your efficiency at converting energy into
hashpower is the driving factor in your profitability, so this and any
other future attempts to decrease the cost of attacking Bitcoin receives a
hard NACK from me.
If you're concerned about missing out on the subsidy or fee revenue, grab
any number of the sub-500mSAT USB miners and get access to cheap power.
Sincerely,
Eric Martindale, relentless maker.
Founder & CEO, Fabric, Inc. <https://fabric.fm>
+1 (919) 374-2020
On Sun, Mar 14, 2021 at 9:41 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good Afternoon,
>
> It is obvious that something needs to be done to curtail the current cost
> of mining in kWh per block. I understand proposals are rejected because it
> is considered censorship and Bitcoin has a consensus to allow anyone to
> mine but, since mining requires specific hardware and energy requirements
> it is already a form of censorship where most on the planet except for the
> top 6% I am guessing here, cannot afford to mine. Without affecting the
> current algorithm, I have previously begun to explore the process by which
> mining can be turned into a lottery with only authorized payto addresses
> able to mine valid blocks, since transaction fees and block rewards exist
> to pay the miner. It would be better even if the algorithms are improved if
> there are some ways that only a subset of miners can produce valid blocks
> for any given period, say for 12 months with four groups starting three
> months apart to transition, and maybe limit mining to 50 people per
> continent to produce valid blocks at any one time. Possibly this requires a
> consortium to oversee the lottery but it is something Bitcoin can handle
> themselves, and would do better to handle than to wait for government
> intervention as we have seen previously in China where power was too cheap
> Bitcoin was banned entirely.
>
> 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 Lonero Foundation via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Saturday, 6 March 2021 3:16 AM
> *To:* Devrandom <c1.devrandom at niftybox.net>
> *Cc:* Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST
> Datastore for Energy Efficient Mining
>
> Also in regards to my other email, I forgot to iterate that my
> cryptography proposal helps behind the efficiency category but also tackles
> problems such as NP-Completeness or Halting which is something the BTC
> network could be vulnerable to in the future. For sake of simplicity, I do
> want to do this BIP because it tackles lots of the issues in regards to
> this manner and can provide useful insight to the community. If things such
> as bigger block height have been proposed as hard forks, I feel at the very
> least an upgrade regarding the hashing algorithm and cryptography does at
> least warrant some discussion. Anyways I hope I can send you my BIP, just
> let me know on the preferred format?
>
> Best regards, Andrew
>
> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <
> loneroassociation at gmail.com> wrote:
>
> Hi, this isn't about the energy efficient argument in regards to
> renewables or mining devices but a better cryptography layer to get the
> most out of your hashing for validation. I do understand the arbitrariness
> of it, but do want to still propose a document. Do I use the Media Wiki
> format on GitHub and just attach it as my proposal?
>
> Best regards, Andrew
>
> On Fri, Mar 5, 2021, 10:07 AM Devrandom <c1.devrandom at niftybox.net> wrote:
>
> Hi Ryan and Andrew,
>
> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> https://www.truthcoin.info/blog/pow-cheapest/
> "Nothing is Cheaper than Proof of Work"
> on | 04 Aug 2015
>
>
> Just to belabor this a bit, the paper demonstrates that the mining market
> will tend to expend resources equivalent to miner reward. It does not
> prove that mining work has to expend *energy* as a primary cost.
>
> Some might argue that energy expenditure has negative externalities and
> that we should move to other resources. I would argue that the negative
> externalities will go away soon because of the move to renewables, so the
> point is likely moot.
>
> _______________________________________________
> 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/20210314/e8b196fe/attachment-0001.html>

2023-06-07 15:17:33 UTC

- reply

📅 Original date posted:2014-04-07
📝 Original message:We need to make it so mind-numbingly simple to "run Bitcoin correctly" that
the average user doesn't find reasons to do so in the course of normal
use. Right now, Coinbase and Bitstamp are winning in the user experience
battle, which technically endanger the user, and by proxy the Bitcoin
network.
Multi-sig as a default is a start. It won't succeed unless the user
experience is simply better than trusted third parties, but we need to
start the education process with the very basic fundamental: trusting a
third-party with full access to your Bitcoin is just replacing one
centralized banking system with another.
Eric Martindale
Developer Evangelist, BitPay
+1 (919) 374-2020
On Apr 7, 2014 7:05 AM, "Mike Hearn" <mike at plan99.net> wrote:
> My guess is that a large number of users have lost interest after they
>> lost their money in MtGox. The 24th of February coincides with the
>> "final" shutdown
>
>
> Sigh. It would not be surprising if MtGox has indeed dealt the community a
> critical blow in this regard. TX traffic is down since then too:
>
>
> https://blockchain.info/charts/n-transactions-excluding-popular?timespan=60days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
>
> Judging from comments and the leaked user db, it seems a lot of well known
> people lost money there (not me fortunately). I wish I could say people
> have learned but from the size of the deposit base at Bitstamp they clearly
> have not. A lot of Bitcoin users don't seem to be ready to be their own
> bank, yet still want to own some on the assumption everyone else either is
> or soon will be. So it's really only a matter of time until something goes
> wrong with some large bitbank again, either Bitstamp or Coinbase.
>
> Some days I wonder if Bitcoin will be killed off by people who just refuse
> to use it properly before it ever gets a chance to shine. The general
> public doesn't distinguish between "Bitcoin users" who deposit with a third
> party and the real Bitcoin users who don't.
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> 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/20140407/ba5bd602/attachment.html>

2023-06-07 15:17:20 UTC

- reply

📅 Original date posted:2014-04-07
📝 Original message:This is toying with the economics of cryptofinance in a way that needs to
be understood before being put under consideration for implementation in
Bitcoin. This is an opportunity for an altcoin to explore the implications
of these proposals prior to changing the properties of an already
precarious system.
Eric Martindale
Developer Evangelist, BitPay
+1 (919) 374-2020
On Apr 7, 2014 2:55 PM, "Ricardo Filipe" <ricardojdfilipe at gmail.com> wrote:
> 2014-04-07 21:08 GMT+01:00 Troy Benjegerdes <hozer at hozed.org>:
> > I have to play dissenter here again..
> >
> > Using a bitcoin address as a persistent identity key is the first
> real-world
> > use of Bitcoin that I can imagine will make it a 'killer app' that
> everyone
> > and their grandma will want to use.
> >
>
> I am of the same opinion, although i understand Gavin's point. Would
> the multisig seed work for this purpose?
> I have been toying with this idea and I think that for this BIP to
> make sense it would require a "root" key as your login. Then if you
> need to make transfers the system would request you to create and
> associate a new key to your account for each purchase (signing the new
> key with the root one for example).
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> 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/20140407/bbd4f161/attachment.html>

2023-06-07 15:11:43 UTC

- reply

📅 Original date posted:2014-01-15
📝 Original message:One variation of this, "recycled address", might avert misconceptions that
the "re-use" is exclusive to one's own identity.
Eric Martindale, relentless maker.
http://www.ericmartindale.com
+1 (919) 374-2020 | *BitMessage: *BM-2cWCmYBpV64FRSJpHHKWi1Cfc9W52jydwe
*Note:* Beginning December 11th, 2013, I will only be intermittently
available via email, SMS, and BitMessage. As a courtesy, please leave a
detailed message so that I can respond in kind. Thanks!
On Wed, Jan 15, 2014 at 7:05 PM, Jeremy Spilman <jeremy at taplink.co> wrote:
> Might I propose "reusable address".
>
> I think that describes it best to any non-programmer, and even more so
> encourages wallets to present options as 'one time use' vs 'reusable'.
>
> It definitely packs a marketing punch which could help drive adoption. The
> feature is only useful if/when broadly adopted.
>
> I think it meets all the criteria required:
>
> - Communication between parties is a single message from the payee,
> which may be public
> - Multiple payments to the same address are not publicly linkable on the
> blockchain
> - The payee has explicitly designated they expect to receive more than
> one payment at that address
> - Payer can publicly prove they made a payment to the reusable address
> by revealing a secret
>
> I have high hopes for this feature. The war *against* address reuse may
> soon be a distant memory.
>
> On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik <jgarzik at bitpay.com>
> wrote:
>
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
>
> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
>
>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport <bendavenport at gmail.com>
>> wrote:
>> > But may I suggest we consider changing the name "stealth address" to
>> > something more neutral?
>>
>> ACK. Regardless of the 'political' overtones, I think stealth is a
>> little cringe-worthy.
>>
>> "Private address" would be fine if not for confusion with private-keys.
>>
>> "Static address" is perhaps the best in my view. (also helps improve
>> awareness that normal addresses are intended to be more one-use-ness)
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20140115/dad871e2/attachment.html>