<unnamed>

Public Key

npub1r34khxrz9w39zpzezymqz04dcel95adfxf6qpjul9wdv2qn5vtps06s8vu

Profile Code

nprofile1qqspc6mtnp3zhgj3q3v3zdsp86kuvlj6wk5nyaqqew0jhxk9qf6x9scpzpmhxue69uhkummnw3ezuamfdejs9mvwt7

Publishing to

nostr.wine

Last Notes

2023-06-08 01:08:48 CEST

- reply

📅 Original date posted:2022-05-18
📝 Original message:Good evening ZmnSCPxj,
Sorry for the long delay...
> Good morning e,
>
> > Good evening ZmnSCPxj,
> >
> > For the sake of simplicity, I'll use the terms lender (Landlord), borrower
> > (Lessor), interest (X), principal (Y), period (N) and maturity (height after N).
> >
> > The lender in your scenario "provides use" of the principal, and is paid
> > interest in exchange. This is of course the nature of lending, as a period
> > without one's capital incurs an opportunity cost that must be offset (by
> > interest).
> >
> > The borrower's "use" of the principal is what is being overlooked. To
> > generate income from capital one must produce something and sell it.
> > Production requires both capital and time. Borrowing the principle for the
> > period allows the borrower to produce goods, sell them, and return the
> > "profit" as interest to the lender. Use implies that the borrower is spending
> > the principle - trading it with others. Eventually any number of others end up
> > holding the principle. At maturity, the coin is returned to the lender (by
> > covenant). At that point, all people the borrower traded with are bag holders.
> > Knowledge of this scam results in an imputed net present zero value for the
> > borrowed principal.
>
> But in this scheme, the principal is not being used as money, but as a billboard
> for an advertisement.
>
> Thus, the bitcoins are not being used as money due to the use of the fidelity
> bond to back a "you can totally trust me I am not a bot!!" assertion.
> This is not the same as your scenario --- the funds are never transferred,
> instead, a different use of the locked funds is invented.
>
> As a better analogy: I am borrowing a piece of gold, smelting it down to make
> a nice shiny advertisement "I am totally not a bot!!", then at the end of the
> lease period, re-smelting it back and returning to you the same gold piece
> (with the exact same atoms constituting it), plus an interest from my business,
> which gained customers because of the shiny gold advertisement claiming "I
> am totally not a bot!!".
>
> That you use the same piece of gold for money does not preclude me using
> the gold for something else of economic value, like making a nice shiny
> advertisement, so I think your analysis fails there.
> Otherwise, your analysis is on point, but analyses something else entirely.
Ok, so you are suggesting the renting of someone else's proof of "burn" (opportunity cost) to prove your necessary expense - the financial equivalent of your own burn. Reading through the thread, it looks like you are suggesting this as a way the cost of the burn might be diluted across multiple uses, based on the obscuration of the identity. And therefore identity (or at least global uniqueness) enters the equation. Sounds like a reasonable concern to me.
It appears that the term "fidelity bond" is generally accepted, though I find this an unnecessarily misleading analogy. A bond is a loan (capital at risk), and a fidelity bond is also capital at risk (to provide assurance of some behavior). Proof of burn/work, such as Hash Cash (and Bitcoin), is merely demonstration of a prior expense. But in those cases, the expense is provably associated. As you have pointed out, if the burn is not associated with the specific use, it can be reused, diluting the demonstrated expense to an unprovable degree.
I can see how you come to refer to selling the PoB as "lending" it, because the covenant on the underlying coin is time constrained. But nothing is actually lent here. The "advertisement" created by the covenant (and its presumed exclusivity) is sold. This is also entirely consistent with the idea that a loan implies capital at risk. While this is nothing more than a terminology nit, the use of "fidelity bond" and the subsequent description of "renting" (the fidelity bond) both led me down another path (Tamas' proposal for risk free lending under covenant, which we discussed here years ago).
In any case, I tend to agree with your other posts on the subject. For the burn to be provably non-dilutable it must be a cost provably associated to the scenario which relies upon the cost. This provides the global uniqueness constraint (under cryptographic assumptions of difficulty).
Best,
e
> Regards,
> ZmnSCPxj

2023-06-08 00:56:42 CEST

- reply

📅 Original date posted:2021-07-06
📝 Original message:> you should check out some of the earlier work done here:
>
> https://github.com/olalonde/proof-of-solvency#assets-proofNothing in this
Nothing here refutes what I have said. Furthermore it relies on the
assumption that all assets and liabilities are provable. This is clearly
prohibitive.
> more than enough.
Arbitrary and subjective.
A business raises money (investment) so that it can spend more than it
previously had. This is net "insolvency" until (and assuming) it produces
and earns over time an amount sufficient to cover its capitalization and
time value.
These sort of schemes are relevant only to what Rothbard calls a money
"warehouse" (a literal vault), which is explicitly not a "bank" (banks
lend). Warehousing Bitcoin is a strange idea to start with. And given that
they are so larded with trust and race conditions it's hardly an improvement
over holding your own keys.
e
> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On
> Behalf Of Erik Aronesty via bitcoin-dev
> Sent: Tuesday, July 6, 2021 9:40 AM
> To: Billy Tetrud <billy.tetrud at gmail.com>; Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Proof of reserves - recording
>
> you should check out some of the earlier work done here:
>
> https://github.com/olalonde/proof-of-solvency#assets-proof
>
> to be honest, if any exchange supported that proof, it would be more than
> enough.
>
> there's really no way to prevent a smash-and-grab, but this does prevent a
> slow-leak
>
>
> On Mon, Jul 5, 2021 at 5:10 PM Billy Tetrud via bitcoin-dev <bitcoin-
> dev at lists.linuxfoundation.org> wrote:
> >
> > I had the idea recently for proof of reserves done in a way that can be
used
> to verify reserves are sufficient on an ongoing basis. I'm curious if
there are
> any current approaches out there to proof of reserves that are similar.
> >
> > The idea is to have users create actual private keys using a seed in
pretty
> much the normal way. Users would generate a public key from this seed to
> represent their account, and would give the public key to the custodian to
> represent their account in a public record of account balances.
> >
> > When a user's account is credited, the custodian would update a map of
> addresses (created from the public key of each account) to balances - this
> map could be structured into a merkle tree in the usual "merkle approach".
> The custodian would also store funds on one or more HD wallets (each with
> many addresses) and create a proof that they own each HD wallet. The proof
> could be as simple as a single signature created with the xpub for the
wallet,
> which would be sufficient for proving ownership over the whole list/tree
of
> addresses.
> >
> > These two structures (the map and the HD wallet) would be combined and
> hashed, and the hash published in an on chain transaction (possibly along
> with a URI where the full data can be found), on something like a daily
basis.
> Software for each user could continuously validate that their account has
a
> balance that matches what it's supposed to have, and could also verify
that
> owned addresses have funds that have at least as many coins as promised to
> accounts. If these things aren't verifiable (either because the balances
total
> to more than the HD wallet contains, or because of data unavailability),
> people can raise hell about it.
> >
> > To give user's additional proving ability, a receipt system could be
added.
> Users could request a receipt for any balance update. Eg the user would
> create a message with a timestamp, their custodial "address", and the new
> balance. The user would sign this receipt and send it to the custodian,
who
> would also sign it and send it back. This way, if something goes wrong, a
user
> can use this signed receipt to show that the custodian did in fact promise
a
> new updated balance at a particular time (which would cover the case that
> the custodian records the wrong value in their map). Conversely, the
receipt
> would be useful to honest custodians as well, since they could show the
> user's signed receipt request in the case a user is trying to lie about
what
> balance they should have. There is still the case that the custodian
simply
> refuses to return a signed receipt, in which case the user's only recourse
is to
> yell about it immediately and demand a receipt or a refund.
> >
> > Why record it on chain? Doing that gives a clear record of proof of
reserves
> that can be verified later by anyone in the future. It prevents a
custodian
> from being able to change history when it suits them (by creating a new
> records with false timestamps in the past). Many of these records could be
> aggregated together and recorded in the same transaction (with a single
> hash), so a single transaction per day could record the records of all
> participating custodians. If all custodians are using a standard system,
one can
> cross verify that addresses claimed by one custodian aren't also claimed
by
> another custodian.
> >
> > Even tho the user is responsible for their keys in order to properly
verify,
> losing the keys isn't that big of a deal, since they could simply create a
new
> seed and give a new public key to the custodian - who would have other
> identifying information they could use to validate that they own the
account.
> So it places less responsibility on the user, while still introducing
people, in a
> light-weight way, to self custody of keys.
> >
> > Having a record like this every day would reduce the possibility of
> shenanigans like taking a short term loan of a large amount of
> cryptocurrency. Sure, they could take a 10 minute loan once per day, but
it
> would also be possible to trace on-chain transactions so you could tell if
such
> a thing was going on. I wonder if there would be some way to include the
> ability to prove balances held on the lightning network, but I suspect
that
> isn't generally possible.
> >
> > In any case, I'm curious what people think of this kind of thing, and if
> systems with similar properties are already out there.
> >
> >
> >
> >
> > _______________________________________________
> > 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-08 00:55:36 CEST

- reply

📅 Original date posted:2021-06-30
📝 Original message:All good questions.
> Is the goal here to do what the economic majority wants, or some other group? If so, do you think we have an accurate way of measuring what the economic majority wants?
It’s important that people understand that “economic” does not refer to people interested in, HODLing, coding, or selling Bitcoin. It is only those who are *presently accepting* it. We refer to these as “economic nodes”. Those are the people with the economic power to reject coin that they consider invalid. Only their validation is of any economic consequence in the event of a split. I see no reason to assume that the economy is any less centralized than mining is pooled. Today the support of the economy would be best measured by meeting with exchange operators. If they did not go along, any unenforced soft fork (split) would isolate everyone who thought they could continue to trade their coin on exchanges.
I’d also question the use of the term “majority”. It applies to hash power, by design, but not to the economy. A split of any size is possible, requiring no majority. All it requires is other people to trade with.
Exchanges are highly regulated and compliant institutions. Mining operations are heavily pooled. Neither of these is inherently better than the other. Everyone can have a say by being a miner or being a merchant. Subeconomies can split, majority hash power can censor (which is the exact mechanism of soft fork enforcement). These ideas are straightforward and hardly worthy of debate. The interesting question is how one gets others to go along with his new coin. Make no mistake, any rule change (soft or hard) is a new coin. If hash power doesn’t enforce the new rules of a soft fork, the chain is split just as if it was a hard fork.
I’m sure people will continue to try and devise ways to figure out who wants to come along, to try and convince people (including exchanges and miners) to do so, to reassure them that everyone else will “have to”, and to mislead them about the actual behavior and risks. We’ve seen permanent splits, and we’ve seen hash power enforced soft forks. We’re likely to see more of both. But as core devs we have a responsibility to inform people, honestly, and let them decide. My only beef with this whole process has been that a widespread belief had formed, supported by far too many core devs (and even embedded in the text of deployed BIPs), that soft forks are inherently “backward compatible”. This is unequivocally not true. The only such compatibility is majority hash power enforcement of a soft fork. This is not a matter of opinion, it’s the core innovation of Bitcoin. Proof of Work settles the question of who has authority to order transactions. Majority hash power has that authority. Merchants can split again and again, but their miners will still have that authority. If one wants a say, one can mine.
e
From: Billy Tetrud <billy.tetrud at gmail.com>
Sent: Tuesday, June 29, 2021 7:03 PM
To: Eric Voskuil <eric at voskuil.org>
Cc: Jorge Timón <jtimon at jtimon.cc>; Luke Dashjr <luke at dashjr.org>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
@Jorge
>I don't think we should avoid splits at all costs.
I absolutely agree that we shouldn't avoid splits at all costs. There are some costs too high to pay to avoid a split. If an economic majority started wanting to increase bitcoin's blocksize to 1 GB next year, we should absolutely hard fork away from that mess with a minority chain.
> I don't think we should avoid splits when possible,
I want to see why exactly we disagree about avoiding chain splits "when possible". Are you really saying that we should just hard fork every time instead of soft fork? Should we even bother to get widespread buy in at all, or should we just release the software, hardfork away, and let anyone that wants to follow us follow us later? Are you not at all worried about the costs associated with an increased orphan rate and reorg rate? Are you not worried that an update might happen too fast and that a significant fraction of people that could have come along with us to the new update might be left behind because they didn't have time to evaluate the changed rules?
Do you agree that, in a conversation about rule changes, some people want it their way no matter what and will hardfork to get the rules they want, and some people want it their way, but only if enough other people agree to follow those rules too? Some people might want a rule change, but aren't willing to follow, say, a 20% minority fork. Perhaps their personal cut-off is 40% or 50% or 75% or 90%. Do you agree those people exist?
If you do, then I don't understand why you disagree that we should avoid chain splits even "when possible". Maybe you could elaborate as to what you mean there.
@Luke
Are you in agreement with Jorge here that we should not even attempt to avoid chain splits?
> The only alternative to a split in the problematic scenarios are 1) concede centralised miner control over the network, and 2) have inconsistent enforcement of rules by users who don't agree on what the correct rules are, again leading to centralised miner control over the network.
There is not simply a binary "do or do not". There is also timing. Non-contentious changes can happen fast. Contentious changes need more time for discussion, preparation, or coordination, even if the eventual outcome is the same. Do you disagree that timing issues can be important, that delays can be useful and help to avoid chain splits? Do you agree that miners have a (large) incentive to follow the economic majority? Is the goal here to do what the economic majority wants, or some other group? If so, do you think we have an accurate way of measuring what the economic majority wants? Will that mechanism continue to be accurate into the future?
I'm asking these questions to try and figure out why we disagree here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210630/cdb30f7e/attachment.html>

2023-06-07 20:29:26 CEST

- reply

📅 Original date posted:2021-03-03
📝 Original message:> consensus requires the ledger to be honest does not prove that it is honest.
Actually, that’s exactly what it does. A logical/mathematical requirement (necessity) is also called a proof.
e
From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On Behalf Of LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev
Sent: Tuesday, March 2, 2021 7:06 PM
To: M.K. Safi via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>; Daniel Edgecumbe <email at esotericnonsense.com>
Subject: Re: [bitcoin-dev] Taproot NACK
"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."
Good Afternoon,
Requiring little argument I concur, privacy allows that you do not have snoops and researchers following you around looking in your purse as you transact. For the general public, how much you carry in your purse and where you get it from is none of their business. However, your employer is required to report to the government a record of pay, or at least maintain that record, and the store where you made a purchase similarly to keep records so that taxes can be paid. From their perspective, you do not need to know how much they keep in their drawer. Bitcoin directly allows your purse to be private and for the transaction ledger to take the scrutiny anyone should be able to apply to prove the ledger is honest. Maintaining an argument that consensus requires the ledger to be honest does not prove that it is honest.
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 <http://www.willtech.com.au>
www.go-overt.com <http://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 Daniel Edgecumbe via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
Sent: Tuesday, 2 March 2021 12:16 PM
To: M.K. Safi via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
Subject: Re: [bitcoin-dev] Taproot NACK
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 <mailto: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 <mailto: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 <https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png&t=622&c=gTi7r1cfh-yynw> &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 <http://www.willtech.com.au>
> > www.go-overt.com <http://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 <mailto:arielluaces at gmail.com> >
> > *Sent:* Monday, 1 March 2021 12:07 AM
> > *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au <mailto:willtech at live.com.au> >; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto: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 <http://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 <mailto: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 <http://www.willtech.com.au>
> >> www.go-overt.com <http://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 <mailto:jlrubin at mit.edu> >
> >> *Sent:* Sunday, 28 February 2021 3:14 AM
> >> *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au <mailto:willtech at live.com.au> >; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto: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 <mailto: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 <http://www.willtech.com.au>
> >>> www.go-overt.com <http://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 <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org <mailto: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 <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org <mailto: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/20210303/51f2aabd/attachment-0001.html>