<unnamed>

Public Key

npub1pynqzktaxz4ffsv8w0ju86anmqmfjau252vwd43nmw0qdk3xrmtskld7pp

Profile Code

nprofile1qqsqjfspt97np255cxrh8ewraweasd5ew7929x8x6ceah8sxmgnpa4cprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvdwh0yr

Publishing to

relay.snort.social

Last Notes

2023-06-08 00:52:41 CEST

- 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-08 00:52:04 CEST

- 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 17:17:33 CEST

- 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 17:17:20 CEST

- 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 17:11:43 CEST

- 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>