<unnamed>

Public Key

npub183ws43p6p2yhlfv92evu5xg2wuj2g72qvzhqjmep8e37clf6ewnsrl5sgy

Profile Code

nprofile1qqsrchg2csaq4ztl5kz4vkw2ry98wf9y09qxptsfdusnuclv05avhfcpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqdnur3z

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-09 15:03:05 CEST

- reply

📅 Original date posted:2021-07-10
📝 Original message:
Hi,
I propose a new LN invoice pattern that contains a Bitcoin address for
onchain transfer as backup.
Motivation: My dream is to have an app wallet that works in a totally
abstract and transparent way onchain and/or LN depending on the situation.
Phoenix wallet almost achieves this, but there is still a certain
LN/onchain distinction that confuses users a bit.
I use Phoenix daily. Today, for some reason, I couldn't pay a friend.
Payment failed in several attempts. It was not clear why. The fact is that
I managed to transfer to Breeze and then from there I was finally able to
transfer to the final destination. For some reason it had no liquidity on
the specific route. These exception cases greatly confuse the most
non-expert users. If, on the invoice my friend sent to me, I had embedded a
Bitcoin address, the wallet could simply ask: "Couldn't send via LN, do you
want to send it on-chain at XPTO fee rate? It can take a while."
That way, in case of payment failure, there is an immediate onchain backup
alternative, useful especially when rates are low, like now.
The format could be something like:
<prefix>:<version>:<bitcoin address>:<invoice>
Example:
ln:v2:Hi,
I propose a new invoice pattern that contains a Bitcoin address for onchain
transfer.
Motivation: My dream is to have a portfolio that works in a totally
abstract and transparent way onchain and/or LN depending on the situation.
Phoenix wallet almost achieves this, but there is still a certain
LN/onchain distinction that confuses users a bit.
I use Phoenix daily. Today, for some reason, I couldn't pay a friend.
Payment failed in several attempts. It was not clear why. The fact is that
I managed to transfer to Breeze and then from there I was finally able to
transfer to the final destination. For some reason it had no liquidity on
the specific route. These exception cases greatly confuse the most
non-expert users. If, on the invoice my friend sent me, I had embedded a
Bitcoin address, the wallet could simply ask: "Couldn't send via LN, do you
want to send onchain at XPTO rate?"
That way, in case of payment failure, there is an immediate onchain backup
alternative, useful especially when rates are low, like now.
The format could be something like:
<prefix>:<version>:<bitcoin address>:<invoice>
Example:
ln:v1:bc1qucfe06nunhrczh9nrfdxyvma84thy3eugs0825:lnbc20m1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqqqqqpqqqqq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqqqqqgqqqqq7qqzqj9n4evl6mr5aj9f58zp6fyjzup6ywn3x6sk8akg5v4tgn2q8g4fhx05wf6juaxu9760yp46454gpg5mtzgerlzezqcqvjnhjh8z3g2qqdhhwkj
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210710/01fd7239/attachment.html>

2023-06-08 01:11:39 CEST

- reply

📅 Original date posted:2022-07-11
📝 Original message:The expectation is that in a few years a space in the block will be very
competitive / expensive and be used only as a bridge for second layers or
big transactions. Who would have thought in 2017 that one day we would be
worried about cheap rates!
Anyway, it seems like a good point and I suggest giving this issue some
name for easy and later reference.
On Mon, Jul 11, 2022 at 3:20 PM Bram Cohen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If transaction fees came in at an even rate over time all at the exact
> same level then they work fine for security, acting similarly to fixed
> block rewards. Unfortunately that isn't how it works in the real world.
> There's a very well established day/night cycle with fees going to zero
> overnight and even longer gaps on weekends and holidays. If in the future
> Bitcoin is entirely dependent on fees for security (scheduled very
> strongly) and this pattern keeps up (overwhelmingly likely) then this is
> going to become a serious problem.
>
> What's likely to happen is that at first there will simply be no or very
> few blocks mined overnight. There are likely to be some, as miners at first
> turn off their mining rigs completely overnight then adopt the more
> sophisticated strategy of waiting until there are enough fees in the
> mempool to warrant attempting to make a block and only then doing it.
> Unfortunately the gaming doesn't end there. Eventually the miners with
> lower costs of operation will figure out that they can collectively reorg
> the last hour (or some time period) of the day overnight and this will be
> profitable. That's likely to cause the miners with more expensive
> operations to stop attempting mining the last hour of the day preemptively.
>
> What happens after that I'm not sure. There are a small enough number of
> miners with a quirky enough distribution of costs of operation and
> profitability that the dynamic is heavily dependent on those specifics, but
> the beginnings of a slippery slope to a mining cabal which reorgs everyone
> else out of existence and eventually 51% attacks the whole thing have
> begun. It even gets worse than that because once there's a cabal
> aggressively reorging anyone else out when they make a block other miners
> will shut down and rapidly lose the ability to quickly spin up again, so
> the threshold needed for that 51% attack will keep going down.
>
> In short, relying completely on transaction fees for security is likely to
> be a disaster. What we can say from existing experience is that having
> transaction fees be about 10% of rewards on average works well. It's enough
> to incentivize collecting fees but not so much that it makes incentives get
> all weird. 90% transaction fees is probably very bad. 50% works but runs
> the risk of spikes getting too high.
>
> There are a few possible approaches to fixes. One would be to drag most of
> east asia eastward to a later time zone thus smoothing out the day/night
> cycle but that's probably unrealistic. Another would be to hard fork in
> fixed rewards in perpetuity, which is slightly less unrealistic but still
> extremely problematic.
>
> Much more actionable are measures which smooth out fees over time. Having
> wallets opportunistically collect their dust during times of low
> transaction fees would help and would save users on fees. Also making UX
> which clarifies when things are likely to take a day or week but that it's
> reliable would be a reasonable thing to do, but users unfortunately are
> very averse to transactions taking a while.
> _______________________________________________
> 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/20220711/9e338c0a/attachment.html>

2023-06-08 01:10:01 CEST

- reply

📅 Original date posted:2022-06-03
📝 Original message:Totally agree.
I couldn't agree more.
On Fri, Jun 3, 2022 at 3:44 PM alicexbt via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Note: This email is an opinion and not an attack on bitcoin
>
> Covenants on bitcoin will eventually be implemented with a soft fork. CTV
> is the easiest and best possible way OP_TX looks good as well. Apart from
> the technical merits, covenants will improve a few other things:
>
> - Developers can build interesting projects with real demand in market.
> - Students learn Sapio and not just solidity.
> - Better tooling could be available for application developers.
> - Maybe we see bitcoin developer hackathons in different countries.
> - Demand for block space might increase, it wont be just exchanges and
> coinjoin.
> - Funding of bitcoin developers and projects might improve. Wont need to
> convince a few people for grants.
>
> **Why covenants are not contentious?**
>
> Some people may write paragraphs about CTV being contentious, spread
> misinformation and do all types of drama, politics etc. on social media but
> there are zero technical NACKs for CTV. We have discussed other covenant
> proposals in detail on mailing list and IRC meetings with an open minded
> approach.
>
> All the developers that participated in the discussion are either okay
> with CTV or OP_TX or covenants in general.
>
> **How and when should covenants be implemented in Bitcoin?**
>
> I don't think we should wait for years anticipating a proposal that
> everyone will agree on or argue for years to pretend changes are hard in
> Bitcoin. We should improve the review process for soft fork BIPs and share
> honest opinions with agreement, disagreement on technical merits.
>
> I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything
> else being used if that improves Bitcoin. Covenants implemented in Bitcoin
> before the next cycle would provide opportunity for developers to build
> interesting things during the bear market. Ossification supporters also
> believe there is some window that will close soon, maybe doing changes
> considering each case individually will be a better approach. CTV is not a
> rushed soft fork, less people followed the research and it was not
> mentioned on social media repeatedly by the respected developers like other
> soft forks.
>
> /dev/fd0
>
>
> Sent with Proton Mail secure email.
> _______________________________________________
> 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/20220603/7ef05782/attachment.html>

2023-06-08 01:08:30 CEST

- reply

📅 Original date posted:2022-04-27
📝 Original message:The idea seems interesting at first glance, but soon we see several
problems. The biggest problem with votes of this type is that they can be
easily manipulated. Imagine a powerful attacker who impersonates someone in
good faith and arrives with a proposal that looks great but has dark ends
behind it (and that no one has simply noticed yet). It would be enough for
this attacker to convince major wallets, major exchanges and even
individuals to believe him. It could be with a good marketing campaign or
even buying these people. This would create a "false consensus", a
misconception of what consensus means.
For me, the consensus should follow the current line: discussions and tests
carried out by experts. We all know that the most important devs have the
most weight in discussions. And that's how it should be, because they
understand far better than any other lowly mortal. Consensus simply means
that there are not at least two or three important people opposing the idea
with solid arguments. Is it very subjective and difficult? Yes. For sure.
We all yearn for objective answers or methods. However, any method would
fail. At the end, after numerous discussions and an apparent consensus, the
objective answer and the real consensus will be obtained in the network, in
the nodes upgrading. If there is a big war, the network will end up
splitting in two, as it has in the past. To avoid any unwanted splits we
discuss for exhaustion here in the list.
I don't think flagging transactions would be a good method to measure this
sort of thing. You are handing important technical discussions into the
hands of those who have no idea about the subject.
Felipe.
On Tue, Apr 26, 2022 at 5:12 PM Keagan McClelland via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> Alongside the debate with CTV right now there's a second debate that was
> not fully hashed out in the activation of Taproot. There is a lot of
> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
> etc. A significant reason for the breakdown in civility around this debate
> is that because we don't have a means of measuring user support for
> proposed sof-fork changes, it invariably devolves into people claiming that
> their circles support/reject a proposal, AND that their circles are more
> broadly representative of the set of Bitcoin users as a whole.
>
> It seems everyone in this forum has at one point or another said "I would
> support activation of ____ if there was consensus on it, but there isn't".
> This statement, in order to be true, requires that there exist a set of
> conditions that would convince you that there is consensus. People have
> tried to dodge this question by saying "it's obvious", but the reality is
> that it fundamentally isn't. My bubble has a different "obvious" answer
> than any of yours.
>
> Secondly, due to the trauma of the block size wars, no one wants to utter
> a statement that could imply that miners have any influence over what
> rulesets get activated or don't. As such "miner signaling" is consistently
> devalued as a signal for market demand. I don't think this is reasonable
> since following the events of '17 miners are aware that they have the
> strong incentive that they understand market demand. Nevertheless, as it
> stands right now the only signal we have to work with is miner signaling,
> which I think is rightly frustrating to a lot of people.
>
> So how can we measure User Support for a proposed rule change?
>
> I've had this idea floating around in the back of my head for a while, and
> I'd like to solicit some feedback here. Currently, all forms of activation
> that are under consideration involve miner signaling in one form or
> another. What if we could make it such that users could more directly
> pressure miners to act on their behalf? After all, if miners are but the
> humble servants of user demands, this should be in alignment with how
> people want Bitcoin to behave.
>
> Currently, the only means users have of influencing miner decisions are A.
> rejection of blocks that don't follow rules and B. paying fees for
> transaction inclusion. I suggest we combine these in such a way that
> transactions themselves can signal for upgrade. I believe (though am not
> certain) that there are "free" bits in the version field of a transaction
> that are presently ignored. If we could devise a mapping between some of
> those free bits, and the signaling bits in the block header, it would be
> possible to have rules as follows:
>
> - A transaction signaling in the affirmative MUST NOT be included in a
> block that does not signal in the affirmative
> - A transaction that is NOT signaling MAY be included in a block
> regardless of that block's signaling vector
> - (Optional) A transaction signaling in the negative MUST NOT be included
> in a block that signals in the affirmative
>
> Under this set of conditions, a user has the means of sybil-resistant
> influence over miner decisions. If a miner cannot collect the fees for a
> transaction without signaling, the user's fee becomes active economic
> pressure for the miner to signal (or not, if we include some variant of the
> negative clause). In this environment, miners could have a better view into
> what users do want, as would the Bitcoin network at large.
>
> Some may take issue with the idea that people can pay for the outcome they
> want and may try to compare a method like this to Proof of Stake, but there
> are only 3 sybil resistant mechanisms I am aware of, and any "real" view
> into what social consensus looks like MUST be sybil resistant:
>
> - Hashpower
> - Proof of personhood (KYC)
> - Capital burn/risk
>
> Letting hashpower decide this is the thing that is currently contentious,
> KYC is dead on arrival both on technical and social grounds, which really
> just leaves some means of getting capital into the process of consensus
> measurement. This mechanism I'm proposing is measurable completely
> en-protocol and doesn't require trust in institutions that fork futures
> would. Additionally it could be an auxiliary feature of the soft fork
> deployment scheme chosen making it something you could neatly package all
> together with the deployment itself.
>
> There are many potential tweaks to the design I propose above:
> 1. Do we include a notion of negative signaling (allowing for the
> possibility of rejection)
> 2. Do we make it such that miner signaling must be congruent with >X% of
> transactions, where congruence is that the signal must match any
> non-neutral signal of transaction.
>
> Some anticipated objections:
>
> 1. signaling isn't voting, no deployment should be made without consensus
> first.
> - yeah well we can't currently measure consensus right now, so that's not
> a super helpful thing to say and is breeding ground for abuse in the form
> of certain people making the unsubstantiated claim that consensus does or
> does not exist for a particular initiative
>
> 2. This is just a proposal for "pay to play", we should not let the
> wealthy make consensus decisions.
> - I agree that wealth should not be able to strong-arm decision making.
> But the status quo seems even worse where we let publicly influential
> people decide consensus in such a way where not only do they not "lose
> ammunition" in the process of campaigning, but actually accrue it, creating
> really bad long-term balances of power.
>
> 3. Enforcing this proposal requires its own soft fork.
> - Yes. It does...and there's a certain cosmic irony to that, but before we
> consider how to make this happen, I'd like to even discuss whether or not
> it's a good idea.
>
> 4. This gives CoinJoin pool operators and L2 protocol implementations
> power over deciding consensus.
> - I see this as an improvement over the status quo
>
> 5. This encourages "spam"
> - If you pay the fees, it's not spam.
>
> The biggest question I'd like to pose to the forum is:
> - Does a scheme like this afford us a better view into consensus than we
> have today?
> - Can it be gamed to give us a *worse* view into consensus? How?
> - Does it measure the right thing? If not, what do you think is the right
> thing to measure? (assuming we could)
> - Should I write a BIP spec'ing this out in detail?
>
> Cheers,
> Keagan
> _______________________________________________
> 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/20220427/9aa1ef81/attachment.html>

2023-06-08 01:00:04 CEST

- reply

📅 Original date posted:2021-10-14
📝 Original message:Interesting discussion. Correct me if I'm wrong: but putting too many
features together in one shot just can't make things harder to debug in
production if something very unexpected happens. It's a basic principle of
software engineering.
Change. Deploy. Nothing bad happened? Change it a little more. Deployment.
Or: Change, change, change. Deploy. Did something bad happen? What change
caused the problem?
On Thu, Oct 14, 2021 at 8:53 PM Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Oct 11, 2021 at 12:12:58PM -0700, Jeremy via bitcoin-dev wrote:
> > > ... in this post I will argue against frequent soft forks with a
> single or
> > minimal
> > > set of features and instead argue for infrequent soft forks with
> batches
> > > of features.
> > I think this type of development has been discussed in the past and has
> been
> > rejected.
>
> > AJ: - improvements: changes might not make everyone better off, but we
> > don't want changes to screw anyone over either -- pareto
> > improvements in economics, "first, do no harm", etc. (if we get this
> > right, there's no need to make compromises and bundle multiple
> > flawed proposals so that everyone's an equal mix of happy and
> > miserable)
>
> I don't think your conclusion above matches my opinion, for what it's
> worth.
>
> If you've got two features, A and B, where the game theory is:
>
> If A happens, I'm +100, You're -50
> If B happens, I'm -50, You're +100
>
> then even though A+B is +50, +50, then I do think the answer should
> generally be "think harder and come up with better proposals" rather than
> "implement A+B as a bundle that makes us both +50".
>
> _But_ if the two features are more like:
>
> If C happens, I'm +100, You're +/- 0
> If D happens, I'm +/- 0, You're +100
>
> then I don't have a problem with bundling them together as a single
> simultaneous activation of both C and D.
>
> Also, you can have situations where things are better together,
> that is:
>
> If E happens, we're both at +100
> If F happens, we're both at +50
> If E+F both happen, we're both at +9000
>
> In general, I think combining proposals when the combination is better
> than the individual proposals were is obviously good; and combining
> related proposals into a single activation can be good if it is easier
> to think about the ideas as a set.
>
> It's only when you'd be rejecting the proposal on its own merits that
> I think combining it with others is a bad idea in principle.
>
> For specific examples, we bundled schnorr, Taproot, MAST, OP_SUCCESSx
> and CHECKSIGADD together because they do have synergies like that; we
> didn't bundle ANYPREVOUT and graftroot despite the potential synergies
> because those features needed substantially more study.
>
> The nulldummy soft-fork (bip 147) was deployed concurrently with
> the segwit soft-fork (bip 141, 143), but I don't think there was any
> particular synergy or need for those things to be combined, it just
> reduced the overhead of two sets of activation signalling to one.
>
> Note that the implementation code for nulldummy had already been merged
> and were applied as relay policy well before activation parameters were
> defined (May 2014 via PR#3843 vs Sep 2016 for PR#8636) let alone becoming
> an active soft fork.
>
> Cheers,
> aj
>
> _______________________________________________
> 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/20211014/5852b42f/attachment-0001.html>

2023-06-07 20:29:26 CEST

- reply

📅 Original date posted:2021-03-03
📝 Original message:Dear LORD HIS EXCELLENCY JAMES HRMH (& HMRH), a.k.a. "The Australian",
This discussion list is serious stuff, please stop making noise.
Fungibility is a desirable property, anyway.
Thank you!
On Wed, Mar 3, 2021 at 12:04 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > 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
>
> 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
> > > www.go-overt.com
> > > and other projects
> > >
> > > earn.com/willtech
> > > linkedin.com/in/damianwilliamson
> > >
> > >
> > > m. 0487135719
> > > f. +61261470192
> > >
> > >
> > > This email does not constitute a general advice. Please disregard this
> email if misdelivered.
> > > *From:* Ariel Lorenzo-Luaces <arielluaces at gmail.com>
> > > *Sent:* Monday, 1 March 2021 12:07 AM
> > > *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin
> Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> > > *Subject:* Re: [bitcoin-dev] Taproot NACK
> > >
> > > Hello LORD HIS EXCELLENCY JAMES HRMH
> > >
> > > I find a striking dichotomy between your concern of increased privacy
> in bitcoin and your link to a bitcoin mixer in your signature
> www.go-overt.com
> > >
> > > At first your concerns seemed genuine but after seeing your promotion
> of a bitcoin mixer I'm thinking your concerns may be more profit motivated?
> I can't tell since you failed to disclose your relationship with the mixer.
> > >
> > > Could you please clarify your association with the bitcoin mixer and
> moving forward could you please always do proper disclosure any time you're
> publically talking about bitcoin transaction privacy. It's only fair to do
> so as to not mislead people in an attempt to manipulate at worst and just a
> courteous practice at best.
> > >
> > > Cheers
> > > Ariel Lorenzo-Luaces
> > > On Feb 28, 2021, at 4:36 AM, LORD HIS EXCELLENCY JAMES HRMH via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >> Good Evening,
> > >>
> > >> Thank-you for your advice @JeremyRubin <
> https://twitter.com/JeremyRubin> on the basis you advise, "Taproot does
> not enable monero-like privacy features", I am prepred to withdraw my NACK
> notably that the existing feeatures of Bitcoin MUST be maintained, and
> whereby the UTXO of a transaction is identifiable, the PayTo Address, and
> the amount all without any obfuscation.
> > >>
> > >> Lightning does not really provide obfuscation, it provides a result
> of a subset of transactions although the operation of the channel is
> observable to the parties.
> > >>
> > >> The reports I were reading concerning the supposed operation of
> Taproot published in a public media channel may have been speculation or
> misinformation nonetheless it is prudent to conditionally reply as you see
> that I have. It is important not to allow things to slip through the
> cracks. As you may believe may astute reviewers could make a full
> disclosure to this list it is not to be expected.
> > >>
> > >> KING JAMES HRMH
> > >> Great British Empire
> > >>
> > >> Regards,
> > >> The Australian
> > >> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> > >> of Hougun Manor & Glencoe & British Empire
> > >> MR. Damian A. James Williamson
> > >> Wills
> > >>
> > >> et al.
> > >>
> > >>
> > >> Willtech
> > >> www.willtech.com.au
> > >> www.go-overt.com
> > >> and other projects
> > >>
> > >> earn.com/willtech
> > >> linkedin.com/in/damianwilliamson
> > >>
> > >>
> > >> m. 0487135719
> > >> f. +61261470192
> > >>
> > >>
> > >> This email does not constitute a general advice. Please disregard
> this email if misdelivered.
> > >> *From:* Jeremy <jlrubin at mit.edu>
> > >> *Sent:* Sunday, 28 February 2021 3:14 AM
> > >> *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin
> Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> > >> *Subject:* Re: [bitcoin-dev] Taproot NACK
> > >>
> > >> I have good news for you: Taproot does not enable monero-like privacy
> features any moreso than already exist in Bitcoin today. At its core,
> taproot is a way to make transactions with embedded smart contracts less
> expensive, done so in a manner that may marginally improve privacy
> dependent on user behavior (but not in the monero-like way you mention).
> For example, it makes it possible for lightning channels to look
> structurally similar to single key wallets, but it does nothing inherently
> to obfuscate the transaction graph as in monero.
> > >>
> > >> Such "monero-like" transaction graph obfuscation may already exist in
> Bitcoin via other techniques (coinjoin, payjoin, coinswap, lightning, etc)
> with or without Taproot, so the point is further moot.
> > >>
> > >> Do you have a source on your reporting?
> > >>
> > >> You may wish to rescind your nack.
> > >>
> > >>
> > >> --
> > >> @JeremyRubin <https://twitter.com/JeremyRubin> <
> https://twitter.com/JeremyRubin>
> > >>
> > >>
> > >> On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via
> bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >>> Good Afternoon,
> > >>>
> > >>> It has been reported that Taproot will enable some Monero like
> features including the ability to hide transactions.
> > >>>
> > >>> If that is the case I offer a full NACK and let me explain.
> > >>>
> > >>> A part of the benefit of using Bitcoin is its honesty. The full
> transaction is published on the blockchain. If that were to change so that
> transactions may be obfuscated from scrutiny then any government would have
> unlimited impetus to ban Bitcoin, and speculation has that is the reason
> India has been reported to have banned cryptocurrencies already.
> > >>>
> > >>> I am in support of the expanded use case of Bitcoin without harming
> the established robust fairness and equal equity offered. The core
> functionality of Bitcoin, its values, must remain unaltered.
> > >>>
> > >>> KING JAMES HRMH
> > >>> Great British Empire
> > >>>
> > >>> Regards,
> > >>> The Australian
> > >>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> > >>> of Hougun Manor & Glencoe & British Empire
> > >>> MR. Damian A. James Williamson
> > >>> Wills
> > >>>
> > >>> et al.
> > >>>
> > >>>
> > >>> Willtech
> > >>> www.willtech.com.au
> > >>> www.go-overt.com
> > >>> and other projects
> > >>>
> > >>> earn.com/willtech
> > >>> linkedin.com/in/damianwilliamson
> > >>>
> > >>>
> > >>> m. 0487135719
> > >>> f. +61261470192
> > >>>
> > >>>
> > >>> This email does not constitute a general advice. Please disregard
> this email if misdelivered.
> > >>> _______________________________________________
> > >>> bitcoin-dev mailing list
> > >>> bitcoin-dev at lists.linuxfoundation.org
> > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >>
> > >> bitcoin-dev mailing list
> > >> bitcoin-dev at lists.linuxfoundation.org
> > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > <ip.bitcointalk.org.png>
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> 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/4f0b78d2/attachment-0001.html>