Daniel Edgecumbe [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-02-22 to 2022-12-11
💬 Posted a total of 5 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 23:17:40

- reply

📅 Original date posted:2022-12-11
📝 Original message:I've been on the sidelines for a while reading these e-mails but it's become rather frustrating to read as of late.
As far as I see it the fundamental principle is that the blockchain, via subsequent confirmations, is the way that security against double spends is provided in Bitcoin.
The application of proof of work to achieve that is the primary innovation of the system that seperates it from simply using digital signatures.
RBF doesn't actually materially affect that at all. Regardless of what happens in the mempool, if you rely on an N-conf transaction being final, and N blocks get reversed, either by an inadvertant chain split or by some sort of short term 51% attack behaviour, you're SOL.
Zeroconf goes even beyond that - if you rely on a transaction in the mempool, a miner can choose to mine a conflicting one regardless of what the relay policy in Core is. The only cost to them is the fee difference between the two transactions, which in the vast majority of cases will be zero or in the favour of the miner.
If we're going to talk about incentive compatibility - in this case the incentive compatible thing, perhaps even a design decision, is that miners just create a backchannel that ignores your censoring of transactions in the mempool.
The debate itself feels like bikeshedding to me for that reason. It doesn't matter what colour we paint the zeroconf shed, it doesn't have a roof and it's made of cardboard.
Daniel Edgecumbe | esotericnonsense
d at esotericnonsense.com | https://esotericnonsense.com
On Sat, Dec 10, 2022, at 12:10, John Carvalho via bitcoin-dev wrote:
> As we debate mempoolfullrbf, and I familiarize myself with related PRs
> from engineers trying to reign in all of the possible behaviors that
> make it inconsistent, I can’t help but think about how I see people
> using the term “incentive-compatible” and how it seems to be awfully
> presumptive.
>
> The idea that a single Bitcoin transaction can be
> “incentive-compatible” by simply restricting it to having a higher fee
> or fee rate is theoretical, likely narrow, and not totally objective.
> RBF is inherently a fee-minimization tool, which as a concept, as I
> understand “incentive-compatibility” to be about miners in this
> context, makes RBF to be anti-incentives; miners are fee maximizers.
>
> Miners want the most fees per block, and per lifetime, do they not? If
> miners, and the mempool, are prioritizing for the smallest txns with
> the highest fees, over the longest acceptable amount of time, this may
> conflict with extra-mempool behaviors that result in more txns per
> block / per lifetime.
>
> If this isn’t making sense yet, let me summarize by how such a problem
> would express: a per-transaction fee-minimized, fully replaceable
> mempool as policy, that appears to always require the highest fee per
> txn, but ultimately includes less txns per block and less fees per
> lifetime. Basically, less use cases, less users, less txns — all to
> enforce a misunderstood theory and predictive speculation of what
> people want out of the system and what miners will do about it.
>
> Simply, we probably want designs that fill blocks, and we don’t need to
> do anything at all to facilitate bidding on a use case like replacement.
>
> Bidding does not require protocol enforcement, it is miner-subjective.
> So why are we pursuing it? Why do we even have RBF? Why are we trying
> to clean up all of the mess RBF creates with more and more code? If
> bidding is already accepted as incentive-compatible, and Bitcoin
> already allows setting a fee, then replacement requires no special code
> at all.
>
> I would think a holistic definition of what is incentive-compatible
> would be something more like what is “market compatible” and enables
> the complementary goals & incentives of every user in the system to
> make it thrive.
>
> It has been shown that users control Bitcoin (UASF) and thus ultimately
> miners would be incentivized to do what users want, up to the point of
> inability or loss. Correct?
>
> So, in contrast, how would the opposite, a user-compatible design,
> express? Well, I think the idea of txns being able to signal intent and
> desired behavior is more interesting (more useful) than a mempool that
> overrides all intent with RBF, and possibly more incentive-compatible
> than mempoolfullrbf as concept.
>
> Since we can’t be sure what the market wants, but we can be sure that
> the more users we have, making the most possible txns, at the highest
> possible prices, will yield the most valuable Bitcoin, and thus the
> most hashpower, we could entertain giving users the most ways to
> express their intent, the most flexibility.
>
> The most basic design would be to simply have no mempool policy at all,
> and let market incentives emerge on their own, but we have a status quo
> to consider, and most users do not have the technical expertise to
> express their own policies with misc patches and hacks of their Bitcoin
> Core software.
>
> I know this is a bit of a high-level abstract perspective, but I think
> it is important to respect such dynamics when making smaller decisions.
> It certainly is not our charge to prioritize what miners want any more
> than any other user type, nor is it within our ability to predict the
> future or fully model incentives of all players across all use cases.
>
> I know some of you may scoff at my bias for use cases like zero-conf,
> but what I am trying to convey is a possible folly in active
> management, speculation, and misapplied game theory that may permeate
> many Bitcoin Core decisions and designs, even beyond the mempoolrbf /
> zero-conf debate.
>
> So, what to do?
>
> —
>
> John Carvalho
> CEO, Synonym.to
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:01:58

- reply

📅 Original date posted:2022-01-01
📝 Original message:I've looked at these PR's and they seem, frankly, bizarre.
You've essentially noticed that if an attacker can run commands on your system, they can run commands on your system.
If you can convince someone to run arbitrary commands, which is what a desktop shortcut or a command argument _is_ at a fundamental level, you own their system. I fail to see how this has anything to do with Core at all.
Daniel Edgecumbe | esotericnonsense
email at esotericnonsense.com | https://esotericnonsense.com
On Sat, Jan 1, 2022, at 21:03, Prayank via bitcoin-dev wrote:
> Hello World,
>
> What?
>
> Remove all *notify options from Bitcoin Core (full node implementation
> used by 99% nodes)
>
> Or one of the below:
>
> notifications.dat
> not use system() in runCommand()
> Use a new setting in settings.json file, notifypolicy which is 0 by
> default (restricted) and can be set to 1 (unrestricted)
>
> Why?
>
> They can help attackers in doing almost anything on machines running
> Bitcoin Core with some social engineering.
>
> How?
>
> Everything is explained several times in different issues, PRs etc. to
> different people including few reviewers who even NACKed a PR that
> would help in adding such options but with some documentation. I won't
> comment much about the reviewers but some of them were clueless about
> issue and how things work.
>
> Example: Calling something misleading and ludicrous when you don't even
> know what works in Windows shortcut and could not share one example of
> financial application
> https://github.com/bitcoin/bitcoin/issues/23412#issuecomment-1003496126
>
> TL;DR
>
> https://github.com/bitcoin/bitcoin/pull/23395#issuecomment-956353035
>
> https://github.com/bitcoin/bitcoin/issues/23412#issuecomment-970480769
>
> To be honest, neither I have energy left to highlight the importance of
> these issues nor most of the people look interested in this space to
> address it. This email is a part of my efforts to share things with
> everyone which I even tried with documentation. There is something
> seriously wrong if few people including maintainers acknowledge the
> issues with *notify options but nobody wants to fix it or document it,
> I will leave it for people to form their own opinions about it.
>
> Last but not least I was even asked to not review and comment in
> https://github.com/bitcoin/bitcoin/pull/23395 when I was just
> responding to others.
>
> This will be helpful in my security project which was already shared in
> mailing list to highlight what users expect from developers and future
> of money, review process etc. and what is the ground reality.
>
> Happy New Year
>
> --
> Prayank
>
> A3B1 E430 2298 178F
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:29:24

- reply

📅 Original date posted:2021-03-01
📝 Original message:Any "transparency" in the blockchain, beyond that required for a participant to determine valid ownership, can only reasonably be thought of as a bug.
Today I spent approximately $5 at a chip shop in North London in cash. Besides the fact that I have voluntarily chosen to share this information, it is absolutely no concern of yourself or any other party that this transaction has occured.
Bitcoin is digital cash.
Daniel Edgecumbe | esotericnonsense
email at esotericnonsense.com | https://esotericnonsense.com
On Mon, Mar 1, 2021, at 22:37, Eric Voskuil via bitcoin-dev wrote:
> To be clear, is this a NACK because Taproot reduces “transparency”
> (increases privacy) on the chain (“maintaining consensus” is obviously
> an argument against any protocol change, so that’s a red herring)?
>
> And is it your theory that only an “honest” (statute abiding) person
> should have privacy, and not against the state, and/or that mixers are
> sufficient privacy?
>
> Personally, I’m not moved by such an argument. What do you think is the
> value proposition of Bitcoin?
>
> e
>
> > On Mar 1, 2021, at 14:21, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >
> > Good Afternoon,
> >
> > I am going to take tough terms with much of your reply and do appreciate a courteous practice. Having previously made public disclosure of my affiliation with Jambler.io it seems sufficient to disclose my affiliation through the link in my email signature block.
> >
> > My concern is not increased privacy it is maintaining consensus values and the transparency of the blockchain wherein all transactions are published in an immutable record and that forbids the redaction of information by any obfuscation. A separate concern is the availability of a privacy suitable for cash should a Bitcoin user desire and especially without disturbing the existing consensus.
> >
> > The use of a Bitcoin Mixer is to enable standard equivalent privacy. As you may experience yourself, you do not allow people to follow you around looking in your purse, suppose you are dealing entirely with cash, and to see where and how much you fill it up, and where you spend. Nonetheless, for an honest person, their wallet is available for government audit as are their financial affairs. This is consistent with the existing operation of consensus.
> >
> > My full email signature block is a disclosure where I have some affiliation with the referenced website being that it carries at least some information that I have provided or that in some way I am associated perhaps only making use of their services. For example, I hardly make a profit from LinkedIn just my information is there. Also, I have made previous public disclosure of the affiliation. Bitcoin Mixer 2.0 is a partner mixer run by Jambler.io wherein I receive a service referral fee and am not in receipt of any part of the process transaction. The operation block diagram provided by Jambler.io is provided here and attached.
> > <ip.bitcointalk.org.png>
> >
> > [ip.bitcointalk.org.png]-Operation of Jambler.io partner mixer
> > https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png&t=622&c=gTi7r1cfh-yynw
> > from this thread https://bitcointalk.org/index.php?topic=5267588
> >
> >
> > The installation script provided by Jambler.io that is the basis of my referral website is also publicly published,
> > https://github.com/jambler-io/bitcoin-mixer
> >
> > The disclosure for the partner program is available from Jambler.io however and is made prominently on my referral website. While it may seem lucrative at first I insist all partner profits are reportable on your personal income.
> > https://jambler.io/become-partner.php
> >
> > I am certainly better than confident that you appreciate the difference between an open and transparent blockchain and the ability of the user to not reveal details of the content of their wallet publicly.
> >
> > If further clarification is required may I suggest you pay a token and mix some Bitcoin wherein our discussion may then have some point of reference.
> >
> > 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:* Ariel Lorenzo-Luaces <arielluaces at gmail.com>
> > *Sent:* Monday, 1 March 2021 12:07 AM
> > *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> > *Subject:* Re: [bitcoin-dev] Taproot NACK
> >
> > Hello LORD HIS EXCELLENCY JAMES HRMH
> >
> > I find a striking dichotomy between your concern of increased privacy in bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com
> >
> > At first your concerns seemed genuine but after seeing your promotion of a bitcoin mixer I'm thinking your concerns may be more profit motivated? I can't tell since you failed to disclose your relationship with the mixer.
> >
> > Could you please clarify your association with the bitcoin mixer and moving forward could you please always do proper disclosure any time you're publically talking about bitcoin transaction privacy. It's only fair to do so as to not mislead people in an attempt to manipulate at worst and just a courteous practice at best.
> >
> > Cheers
> > Ariel Lorenzo-Luaces
> > On Feb 28, 2021, at 4:36 AM, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> Good Evening,
> >>
> >> Thank-you for your advice @JeremyRubin <https://twitter.com/JeremyRubin> on the basis you advise, "Taproot does not enable monero-like privacy features", I am prepred to withdraw my NACK notably that the existing feeatures of Bitcoin MUST be maintained, and whereby the UTXO of a transaction is identifiable, the PayTo Address, and the amount all without any obfuscation.
> >>
> >> Lightning does not really provide obfuscation, it provides a result of a subset of transactions although the operation of the channel is observable to the parties.
> >>
> >> The reports I were reading concerning the supposed operation of Taproot published in a public media channel may have been speculation or misinformation nonetheless it is prudent to conditionally reply as you see that I have. It is important not to allow things to slip through the cracks. As you may believe may astute reviewers could make a full disclosure to this list it is not to be expected.
> >>
> >> 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:* Jeremy <jlrubin at mit.edu>
> >> *Sent:* Sunday, 28 February 2021 3:14 AM
> >> *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> >> *Subject:* Re: [bitcoin-dev] Taproot NACK
> >>
> >> I have good news for you: Taproot does not enable monero-like privacy features any moreso than already exist in Bitcoin today. At its core, taproot is a way to make transactions with embedded smart contracts less expensive, done so in a manner that may marginally improve privacy dependent on user behavior (but not in the monero-like way you mention). For example, it makes it possible for lightning channels to look structurally similar to single key wallets, but it does nothing inherently to obfuscate the transaction graph as in monero.
> >>
> >> Such "monero-like" transaction graph obfuscation may already exist in Bitcoin via other techniques (coinjoin, payjoin, coinswap, lightning, etc) with or without Taproot, so the point is further moot.
> >>
> >> Do you have a source on your reporting?
> >>
> >> You may wish to rescind your nack.
> >>
> >>
> >> --
> >> @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin>
> >>
> >>
> >> On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>> Good Afternoon,
> >>>
> >>> It has been reported that Taproot will enable some Monero like features including the ability to hide transactions.
> >>>
> >>> If that is the case I offer a full NACK and let me explain.
> >>>
> >>> A part of the benefit of using Bitcoin is its honesty. The full transaction is published on the blockchain. If that were to change so that transactions may be obfuscated from scrutiny then any government would have unlimited impetus to ban Bitcoin, and speculation has that is the reason India has been reported to have banned cryptocurrencies already.
> >>>
> >>> I am in support of the expanded use case of Bitcoin without harming the established robust fairness and equal equity offered. The core functionality of Bitcoin, its values, must remain unaltered.
> >>>
> >>> 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.
> >>> _______________________________________________
> >>> 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
> > <ip.bitcointalk.org.png>
> > _______________________________________________
> > 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:21:47

- reply

📅 Original date posted:2019-11-23
📝 Original message:You may find my (incomplete) front-end of interest:
https://bitcoin.electronrelocation.com
The live demo is backed by a -disablewallet node, but it was able to accept payments and send them via QR codes before I stopped development.
The source is available via AGPLv3.
https://git.esotericnonsense.com/pub/bitcoin-top.git
I am unable to continue development due to time constraints.
Daniel Edgecumbe | esotericnonsense
email at esotericnonsense.com | https://esotericnonsense.com
On Sat, Nov 23, 2019, at 17:49, Oscar Lafarga via bitcoin-dev wrote:
> Hi MK,
>
> I very much share your interests and curiosities here and actually
> don't have an answer on whether it's been tried before.
>
> One of the few things I am imagining is that given the security-focused
> nature of the Bitcoin Core software, any vulnerabilities in the way NPM
> handles the dependencies of the Electron app would be a very high
> priority (see
> https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)
>
> In NodeJS-land, my sense is that there is a "move fast and break
> things" mentality that may have seeped into some practices that may be
> considered standard. I have seen some recent developments over the past
> few years to address these kinds of issues such as npm-audit (as of
> Node v6+) but I would recommend doing some thorough research on this
> front to make sure there is a secure dependency management solution in
> place for such a GUI.
>
> Another comment I'd make is that if we consider the GUI as a layer that
> is separate from the protocol layer, this mailing list may not be the
> best place to fully discuss this. However I think if anyone here who
> has been around longer can contribute info on past attempts at this, it
> could be quite productive. This could technically exist as an
> independent client, but I guess there's a conversation on whether this
> new Electron UI would ever replace the Qt UI, but since it doesn't
> exist yet it could be far too early for that.
>
> Thanks,
>
>
>
>
>
>
> On Sat, Nov 23, 2019, 2:17 PM M.K. Safi via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I’d like to try to rebuild Bitcoin Core GUI using the JavaScript Electron framework. My goal is to get a real world understanding of the pros and cons of moving from Qt to Electron.
> >
> > Before I start, I‘d like to know if this has been tried before or if there are ongoing efforts in this direction by anyone?
> >
> > I spent sometime looking into how to implement this. One approach could be for Electron to drive the UI by running bitcoind and communicating with it through RPC. But I don’t know if such implementation can achieve feature-parity with the Qt implementation. Qt has the advantage of direct access to Bitcoin Core code.
> >
> > Anyways, I just wanted to share these ideas before going further with them, so please let me know if you have any information on the above!
> > --
> > Sent from my iPhone
> > _______________________________________________
> > 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:10:30

- reply

📅 Original date posted:2018-02-22
📝 Original message:> However, the non-interactive schnorr aggregation trick[1] can be
applied to merge the S values of all graftroots and signatures in a
transaction into a single aggregate. With this approach only a single
R value for each graftroot need be published, lowering the overhead to
~32 bytes-- the same as taproot. This has a side benefit of binding
the published grafts to a particular transaction, which might help
avoid some screwups.
I don't think that binding grafts to a particular transaction requires this aggregation.
It seems to me that you could just sign H(txid, script) rather than H(script).
I'm not aware of whether this would break aggregation.
---
Daniel Edgecumbe / esotericnonsense
esotericnonsense at esotericnonsense.com
https://esotericnonsense.com
https://danedgecumbe.com