npub1ej…ehx2v

Last Notes

2023-06-08 01:00:23 CEST

- reply

📅 Original date posted:2021-10-27
📝 Original message:Good Afternoon,
No. This has been discussed previously and eliminated as there is no proof that the transaction can exist without population through the mempool. As a method of payment not hearing about a transaction until it is possibly mined three months later as I have experienced is non-functional, there were discussions in this mailing list. The purpose of the mempool is not gossip it is gossip and any node technically can mine if they do.
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
duigco.org DUIGCO API
and other projects
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 lisa neigut via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Tuesday, 26 October 2021 1:56 PM
To: bitcoin-dev at lists.linuxfoundation.org <bitcoin-dev at lists.linuxfoundation.org>
Subject: [bitcoin-dev] death to the mempool, long live the mempool
Hi all,
In a recent conversation with @glozow, I had the realization that the mempool is obsolete and should be eliminated.
Instead, users should submit their transactions directly to mining pools, preferably over an anonymous communication network such as tor. This can easily be achieved by mining pools running a tor onion node for this express purpose (or via a lightning network extension etc)
Mempools make sense in a world where mining is done by a large number of participating nodes, eg where the block template is constructed by a majority of the participants on the network. In this case, it is necessary to socialize pending transaction data to all participants, as you don’t know which participant will be constructing the winning block template.
In reality however, mempool relay is unnecessary where the majority of hashpower and thus block template creation is concentrated in a semi-restricted set.
Removing the mempool would greatly reduce the bandwidth requirement for running a node, keep intentionality of transactions private until confirmed/irrevocable, and naturally resolve all current issues inherent in package relay and rbf rules. It also resolves the recent minimum relay questions, as relay is no longer a concern for unmined transactions.
Provided the number of block template producing actors remains beneath, say 1000, it’d be quite feasible to publish a list of tor endpoints that nodes can independently + directly submit their transactions to. In fact, merely allowing users to select their own list of endpoints to use alternatively to the mempool would be a low effort starting point for the eventual replacement.
On the other hand, removing the mempool would greatly complicate solo mining and would also make BetterHash proposals, which move the block template construction away from a centralized mining pool back to the individual miner, much more difficult. It also makes explicit the target for DoS attacks.
A direct communication channel between block template construction venues and transaction proposers also provides a venue for direct feedback wrt acceptable feerates at the time, which both makes transaction confirmation timelines less variable as well as provides block producers a mechanism for (independently) enforcing their own minimum security budget. In other words, expressing a minimum acceptable feerate for continued operation.
Initial feerate estimation would need to be based on published blocks, not pending transactions (as this information would no longer be available), or from direct interactions with block producers.
~niftynei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211027/e9782e39/attachment.html>

2023-06-08 00:52:43 CEST

- reply

📅 Original date posted:2021-05-10
📝 Original message:Good Afternoon,
Proof-of-stake sounds like an altcoin fork. There is no consideration that proof-of-work is insufficient or that it can be improved upon, only that it should be regulated. Imagine, you are a gold miner with larger hands so you start a mining race and mine plenty more than everyone. Pretty soon everybody is employing all their available resources just to keep up in the mining race since there are only so many carts instead of just to leisurely utilise surplus resources for an opportune find. Each block is a new gold mine. It is enough for everybody to use leisurely resources.
I have initiated conversation previously regarding a method to regulate mining, and believe whole heartedly it should happen. That is necessary for the future stability of Bitcoin as it is clear the rate of work cannot be allowed to increase at such a rate. If you search the bitcoin-dev archives you will find discussion there under my email as we search for a solution.
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 Keagan McClelland via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Tuesday, 11 May 2021 1:01 AM
To: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>; Erik Aronesty <erik at q32.com>
Cc: SatoshiSingh <SatoshiSingh at protonmail.com>
Subject: Re: [bitcoin-dev] Opinion on proof of stake in future
To reiterate some of the points here. My problem with proof of stake is twofold.
1. It requires permission of coin holders to enter into the system. This is not true of proof of work. You may even attempt (though not successfully) a proof of work with pencil and paper and submit the block from a regular laptop if you so choose. Whether this level of permissionlessness is necessary is up to individual risk tolerance etc. but it is definitely the default preference of Bitcoin.
2. Proof of stake must have a trusted means of timestamping to regulate overproduction of blocks. This introduction of trust is generally considered to be a nonstarter in Bitcoin. Proof of Work regulates this by making blocks fundamentally difficult to produce in the first place.
Like Jeremy, I’m always interested to learn about new attempts in consensus algorithms, but the bar to clear is very high and proof of stake to date has not proposed much less demonstrated a set of properties that is consistent with Bitcoins objectives.
Keagan
On Mon, May 10, 2021 at 8:43 AM Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
personally, not speaking for anyone else, i think that proof-of-burn
has a much higher likelihood of being a) good enough security and b)
solving the nothing-at-stake problem
the only issue i see with a quality PoB implementation is a robust
solution to the block-timing problem.
https://grisha.org/blog/2018/01/23/explaining-proof-of-work/
i do think there *could* be other low-energy solutions to verifiable
timing, just haven't seen one
On Fri, May 7, 2021 at 6:50 PM SatoshiSingh via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org<mailto: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<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/20210510/788958ad/attachment-0001.html>

2023-06-07 20:30:21 CEST

- reply

📅 Original date posted:2021-03-14
📝 Original message: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<mailto: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<mailto: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<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210314/83f7336d/attachment.html>

2023-06-07 20:29:31 CEST

- reply

📅 Original date posted:2021-03-17
📝 Original message:Good Afternoon,
If you actually believe the operation of consensus and the discussion relevant to that is a mundane or philosophical dissection of people's ability to grasp a humorous while on-topic but obligatorily unnecessary conversation you may prefer if you enquire how Bitcoin is censorship-resistant.
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: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Sent: Wednesday, 17 March 2021 3:19 PM
To: Aymeric Vitte <aymeric at peersm.com>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Cc: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; R E Broadley <rebroad+linuxfoundation.org at gmail.com>; Eric Voskuil <eric at voskuil.org>
Subject: Re: [bitcoin-dev] Taproot NACK
> It's incredible how this troll keeps trolling and the list (bitcoin-dev !!) keeping attention
>
> Good troll, really
Depending on topic raised, it may be useful to at least answer the troll naively as if it were an honest question, if only so that third parties reading do not get confused and think the troll is bringing up some objection that is actually relevant.
For this particular topic you replied to, it seems to me obviously inane to discuss the "lordship" and "majesty" of the troll.
Even if the claims to such "lordship" are *true*, for most of the world, the relevance of the previous British empire is little more than a reality TV show about the British royal family (oh, some random thing happened to some random descendant of the royal family, how interesting, say did you see that nice new (actually old) technique Jeremy was talking about on the other thread about delegating control of coins to script, it looks like "graftroot without a softfork"?), and any particular claims to nobility or aristocracy are largely moot, thus not worth answering.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210317/b11b561f/attachment-0001.html>

2023-06-07 20:29:30 CEST

- reply

📅 Original date posted:2021-03-14
📝 Original message:Good Afternoon,
Since this is on the list I will open without my thank-you. You will
kindly be advised that my title are recorded in both Scotland and with
England, also provided by record in Australia's account with names
recorded. If you wonder than am I Wills it is because a long time
before we ever saw Wills in print with an article provided reference to
any Prince in the past thirty-years there I am Wills already. Title The
Australian was prepared a long time to my requiest to wait until it was
better presented, with at least some acquired experience in business to
understand a market like BHP services. Thereby you accept a separate
title Lord being with feudal and Lord being with the appointments
direct to the service of the monarch's house Earl and similar up to
Duke and King and higher being heard usually the monarch's preference
Your Excellency or Your Highness being His service. I have never been
any Prince. If any Prince titles came the instructions were they were
retained to be considered not accepted not refused.
If you had each fools to inquire.
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 Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Saturday, 13 March 2021 9:30 AM
To: R E Broadley <rebroad+linuxfoundation.org at gmail.com>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot NACK
I’m pretty sure it’s subtle mockery. Even a legit title doesn’t warrant additional attention.
e
> On Mar 12, 2021, at 14:02, R E Broadley via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 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.
_______________________________________________
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/e7e8d309/attachment-0001.html>

2023-06-07 20:29:29 CEST

- reply

📅 Original date posted:2021-03-10
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210310/629032b3/attachment-0001.html>

2023-06-07 20:29:28 CEST

- reply

📅 Original date posted:2021-03-04
📝 Original message:Good Afternoon,
So this I have been advised as you say.
My concern was that the more complex scripts allow obfuscation of the Pay To address thereby removing the probity that Bitcoin can only be honest since the public ledger can be subject to limitless scrutiny. I did see another party mention this publicly on a social media channel and the back is supposed to be conditional both in the application and in lifting.
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: Erik Aronesty <erik at q32.com>
Sent: Thursday, 4 March 2021 1:49 AM
To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Cc: Daniel Edgecumbe <email at esotericnonsense.com>
Subject: Re: [bitcoin-dev] Taproot NACK
taproot does not enable anything that cannot already be done today.
it only enables larger and more complex scripts to be done more
efficiently - using less ledger space.
so any objections you can have should be leveled at bitcoin, not at taproot.
On Wed, Mar 3, 2021 at 6:39 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> "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>
> Sent: Tuesday, 2 March 2021 12:16 PM
> To: M.K. Safi via bitcoin-dev <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 | 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<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>
> > > *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<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> 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>
> > >> *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<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
> > >>> 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
> >
> _______________________________________________
> 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/20210304/a92ed715/attachment-0001.html>

2023-06-07 20:29:25 CEST

- reply

📅 Original date posted:2021-03-03
📝 Original message:"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
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>
Sent: Tuesday, 2 March 2021 12:16 PM
To: M.K. Safi via bitcoin-dev <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 | 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<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>
> > *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<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> 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>
> >> *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<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
> >>> 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
>
_______________________________________________
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/20210303/ab749c44/attachment-0001.html>

2023-06-07 20:29:23 CEST

- reply

📅 Original date posted:2021-02-28
📝 Original message: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.
[cid:532a68da-7ec4-45b9-ba93-56f572752081]
[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<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
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<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<http://earn.com/willtech>
linkedin.com/in/damianwilliamson<http://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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210301/5bc45f97/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ip.bitcointalk.org.png
Type: image/png
Size: 81913 bytes
Desc: ip.bitcointalk.org.png
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210301/5bc45f97/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ip.bitcointalk.org.png
Type: image/png
Size: 81913 bytes
Desc: ip.bitcointalk.org.png
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210301/5bc45f97/attachment-0003.png>

2023-06-07 20:21:40 CEST

- reply

📅 Original date posted:2019-11-08
📝 Original message:It goes without saying in that all privately known CVE should be handled so professionally but, that is, well done team.
Regards,
LORD HIS EXCELLENCY JAMES HRMH
________________________________
From: bitcoin-dev-bounces at lists.linuxfoundation.org <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Saturday, 9 November 2019 2:07 AM
To: bitcoin-dev at lists.linuxfoundation.org <bitcoin-dev at lists.linuxfoundation.org>
Cc: security at bitcoincore.org <security at bitcoincore.org>
Subject: [bitcoin-dev] CVE-2017-18350 disclosure
CVE-2017-18350 is a buffer overflow vulnerability which allows a malicious
SOCKS proxy server to overwrite the program stack on systems with a signed
`char` type (including common 32-bit and 64-bit x86 PCs).
The vulnerability was introduced in 60a87bce873ce1f76a80b7b8546e83a0cd4e07a5
(SOCKS5 support) and first released in Bitcoin Core v0.7.0rc1 in 2012 Aug 27.
A fix was hidden in d90a00eabed0f3f1acea4834ad489484d0012372 ("Improve and
document SOCKS code") released in v0.15.1, 2017 Nov 6.
To be vulnerable, the node must be configured to use such a malicious proxy in
the first place. Note that using *any* proxy over an insecure network (such
as the Internet) is potentially a vulnerability since the connection could be
intercepted for such a purpose.
Upon a connection request from the node, the malicious proxy would respond
with an acknowledgement of a different target domain name than the one
requested. Normally this acknowledgement is entirely ignored, but if the
length uses the high bit (ie, a length 128-255 inclusive), it will be
interpreted by vulnerable versions as a negative number instead. When the
negative number is passed to the recv() system call to read the domain name,
it is converted back to an unsigned/positive number, but at a much wider size
(typically 32-bit), resulting in an effectively infinite read into and beyond
the 256-byte dummy stack buffer.
To fix this vulnerability, the dummy buffer was changed to an explicitly
unsigned data type, avoiding the conversion to/from a negative number.
Credit goes to practicalswift (https://twitter.com/practicalswift) for
discovering and providing the initial fix for the vulnerability, and Wladimir
J. van der Laan for a disguised version of the fix as well as general cleanup
to the at-risk code.
Timeline:
- 2012-04-01: Vulnerability introduced in PR #1141.
- 2012-05-08: Vulnerability merged to master git repository.
- 2012-08-27: Vulnerability published in v0.7.0rc1.
- 2012-09-17: Vulnerability released in v0.7.0.
...
- 2017-09-21: practicalswift discloses vulnerability to security team.
- 2017-09-23: Wladimir opens PR #11397 to quietly fix vulernability.
- 2017-09-27: Fix merged to master git repository.
- 2017-10-18: Fix merged to 0.15 git repository.
- 2017-11-04: Fix published in v0.15.1rc1.
- 2017-11-09: Fix released in v0.15.1.
...
- 2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.
- 2019-11-08: Vulnerability details disclosure to bitcoin-dev ML.
_______________________________________________
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/20191108/aace00bf/attachment-0001.html>

2023-06-07 20:19:50 CEST

- reply

📅 Original date posted:2019-08-02
📝 Original message:I have but one point to make in a brief catch-up read over.
With the current protocol the fix to a network split is simple, the longest chain win. But with the moving checkpoint I'm proposing we have a problem if both chains began to differ more than N blocks ago, the forks are permanent. So we need an additional rule to ignore the moving checkpoint, a limit of X blocks:
It is not to be considered the longest chain, it is to be considered the longest chain with the most proof of work.
Regards,
LORD HIS EXCELLENCY JAMES HRMH
<https://earn.com/willtech>
________________________________
From: bitcoin-dev-bounces at lists.linuxfoundation.org <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Kenshiro [] via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Friday, 2 August 2019 11:08 PM
To: Ethan Heilman <eth3rs at gmail.com>; Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
Hi all,
Very good points. I did some clarifications in a private conversation, the new rule is making the moving checkpoint valid only if the difference in blocks between the main chain and the new fork is smaller than X blocks, like for example 3 days of blocks, so after a long network split everyone can finally follow the longest chain:
With the current protocol the fix to a network split is simple, the longest chain win. But with the moving checkpoint I'm proposing we have a problem if both chains began to differ more than N blocks ago, the forks are permanent. So we need an additional rule to ignore the moving checkpoint, a limit of X blocks:
If a node sees a fork longer than his main chain, and the fork has at least X blocks more than the main chain, then the node ignore the moving checkpoint rule, and it follows the fork, the longest chain.
So as an example, the moving checkpoint could be 24 hours of blocks, and the limit of X blocks, the blocks of 3 days.
So we have 2 possible situations to consider:
- 51% attack: the blocks older than 24 hours are protected against a history rewrite during at least 3 days, in that time developers could release an emergency release with another mining algorithm to stop the attack.
- Network split: if the network split is older than N blocks, we have 2 permanent forks (or chains), but in 3 days (or more) the blockchain heights will differ in more than X blocks (the blocks of 3 days) because there will be more miners in one chain than in the other so finally the loser chain will be abandoned and everyone will follow the longest chain.
It could be even more conservative, like 48 hours for the moving checkpoint and a block limit of 7 days of blocks.
Regards,
________________________________
From: Ethan Heilman <eth3rs at gmail.com>
Sent: Friday, August 2, 2019 14:19
To: Kenshiro [] <tensiam at hotmail.com>; Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Cc: Alistair Mann <al at pectw.net>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
Attack 1:
I partition (i.e. eclipse) a bunch of nodes from the network this partition contains no mining power . I then mine 145 blocks for this partition. I don't even need 51% of the mining power because I'm not competing with any other miners. Under this rule this partition will hardfork from the network permanently. Under current rules this partition will be able to rejoin the network as the least weight chain will be orphaned.
Attack 2:
I pre-mine 145 blocks. A node goes offline for 24 hours, when it rejoins I feed it 145 blocks which fork off from the consensus chain. I have 24+24 hours to mine these 145 blocks so I should be able to do this with 25% of the current hash rate at the time the node went offline. Under your rule each of these offline-->online nodes I attack this way will hardfork themselves from the rest of the network.
I believe a moving-checkpoint rule as describe above would make Bitcoin more vulnerable to 51% attacks.
A safer rule would be if a node detects a fork with both sides of the split having length > 144 blocks, it halts and requests user intervention to determine which chain to follow. I don't think 144 blocks is a great number to use here as 24 hours is very short. I suspect you could improve the security of the rule by making the number of blocks a fork most reach to halt the network proportional to the difference in time between the timestamp in the block prior to the fork and the current time. I am **NOT** proposing Bitcoin adopt such a rule.
NXT has a fundamentally different security model as it uses Proof-of-stake rather than Proof-of-Work.
On Wed, Jul 31, 2019 at 2:37 PM Kenshiro [] via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
P.S.: To be clearer, in this example I set an N value of 144 blocks, which is approximately 24 hours.
________________________________
From: Kenshiro [] <tensiam at hotmail.com<mailto:tensiam at hotmail.com>>
Sent: Wednesday, July 31, 2019 16:40
To: Alistair Mann <al at pectw.net<mailto:al at pectw.net>>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
>>> How would a (potentially, state-sponsored) netsplit lasting longer than N be
handled?
It would be detected by the community much before reaching the reorg limit of N blocks (it's 24 hours) so nodes could stop until the netsplit is fixed.
In the extreme case no one notice the network split during more than N blocks (24 hours) and there are 2 permanent forks longer than N, nodes from one branch could delete their local history so they would join the other branch.
Regards,
________________________________
From: Alistair Mann <al at pectw.net<mailto:al at pectw.net>>
Sent: Wednesday, July 31, 2019 15:59
To: Kenshiro [] <tensiam at hotmail.com<mailto:tensiam at hotmail.com>>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
On Wednesday 31 Jul 2019 12:28:58 Kenshiro [] via bitcoin-dev wrote:
> I would like to propose that a "moving checkpoint" is added to the Bitcoin
> protocol. It's a very simple rule already implemented in NXT coin:
>
> - A node will ignore any new block under nodeBlockHeight - N, so the
> blockchain becomes truly immutable after N blocks, even during a 51% attack
> which thanks to the moving checkpoint can't rewrite history older than the
> last N blocks.
How would a (potentially, state-sponsored) netsplit lasting longer than N be
handled?
--
Alistair Mann
_______________________________________________
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/20190803/8720e865/attachment.html>