micaroni at gmail.com [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-03-03 to 2022-08-20
💬 Posted a total of 7 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 15:03:05

- reply

📅 Original date posted:2021-07-10
📝 Original message:
I'm sorry for the bad copy/paste in the last email. Resending:
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.
On Sat, Jul 10, 2021 at 2:55 AM <micaroni at gmail.com> wrote:
> 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/7c6e9821/attachment-0001.html>

2023-06-09 15:03:05

- 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-09 14:40:37

- reply

2023-06-09 14:40:37

- reply

2023-06-08 01:12:58

- reply

📅 Original date posted:2022-08-20
📝 Original message:Hi dear devs,
1. THE ISSUE - DAEMON+CLI
========================
I had a wallet in a server production since 2017 (5 years old) and when it
reached about 273 MB, 2.079.337 transactions and 446.503 generated
addresses, the performance started to degrade exponentially.
Most of the commands, e.g. "getbalance", "walletpassphrase" and
"getreceivedbyaddress" started to timeout (more than 15 minutes delay -
default timeout). The CPU was 100% used (all 32 cores - with 150 load avg)
and the machine became almost unusable breaking everything else, with the
default config of 16 RPC threads and 15 min timeout and some attempt calls
per mi
Increasing the timeout and/or the RPC threads in the config file turns
things even worse.
Putting the wallet.dat in a very fast SSD disk and increasing the size of
the cache (I tried with 8GB) have improved but I'm not sure if it is enough.
2. TEST ON BITCOIN QT
====================
If you try to load the wallet in the "bitcoin-qt" everything gets stuck,
even the system (OS/UI) doesn't respond anymore. You click on a button and
receive the message "window doesn't respond, wait or terminate?" - if you
wait it releases after a while but it is slow and hard to use the wallet
anyway.
3. WHY IS THIS SO BAD?
=====================
This is bad because the standard client becomes almost useless for the
wallet feature:
3.1) the wallet Qt already is not so popular among end users. It doesn't
look modern, slow to first sync and hard to use. That's why people prefer
to use Electrum or Wasabi - I personally don't care but it's the sad truth;
3.2) it becomes useless now also for servers in production, forcing them to
use third party solutions for huge wallets. Even if you split in 10 wallets
it will just delay 10 times more each to degrade, postponing the problem
but not eliminating it. Not to mention the slow and daily degradation.
4. SHOULD WE GIVE UP THE WALLET FEATURE?
========================================
Then, Bitcoin Core becomes just a reference implementation and blocks
relayers, but as an application wallet itself turns into a really bad
choice. --- It leads me to the following question: if we won't invest time
on improving this, shouldn't we remove the wallet feature at all? Why keep
a wallet feature that is not useful for the end user nor the production
server? Is it useful for what then?
5. THE CURRENT "SOLUTION" IS BAD
===============================
Currently, the only "solution" for huge wallets is shameful: create a new
one and send the funds there from time to time. But when is the right time
exactly? The performance degrades suddenly or gets worse slowly for each
new address and/or tx?. And besides not being an elegant solution and "not
in the handbook", it also can break a lot of things like monitoring old
addresses and also can lead to privacy concerns unifying lots of inputs in
a big and expensive tx.
6. OTHER USER CASES?
====================
I think this could also become an issue if we have LN nodes that use the
Bitcoin Core wallet infrastructure behind to open / close many channels for
a long time.
7. FINAL THOUGHTS
=================
If moving the wallet from a HDD to a SSD improved a lot, maybe just caching
the entire wallet in memory could improve even more, but I'm afraid some
code optimization is also necessary.
8. SOME QUESTIONS
==================
8.1) Can we "optimize" a huge wallet without moving the funds to a new one?
Like a "fsck" or eqv?
8.2) Can we improve the cache usage somehow? Putting the entire wallet in
memory, for example?
8.3) Is it possible to reduce the wallet size (273 MB is too much for a HD
wallet)?
8.4) Can we tell the CLI to ignore old addresses? What if I need to watch
only the last 30 days?
8.5) How to improve the I/O treatment and/or CPU usage in the main thread
on Bitcoin-Qt to avoid window freezing on big and huge wallets?
8.6) In the last case (if it was not possible to optimize the wallet or the
CLI & Qt), can the CLI just warn the user like: "the wallet is becoming too
big and slow, execute the command 'archive'". And then, the command
"archive" could rename the current wallet to something like
"wallet.dat.archive_until_20220818", create a new "wallet.dat" and move the
funds automatically? Also, would it be nice to have an
"autoarchivehugewallets=1" in the file config?
9. POSSIBLE RELATED AND TESTS
=============================
[1] https://github.com/bitcoin/bitcoin/issues/15015
[2] https://github.com/bitcoin/bitcoin/issues/15148
[3] https://github.com/bitcoin/bitcoin/issues/16874
[4] https://github.com/bitcoin/bitcoin/pull/17135
[5] https://github.com/bitcoin/bitcoin/pull/18160
[6] https://github.com/bitpay/bitcore-node/issues/463
[7] https://github.com/RavenProject/Ravencoin/issues/499
[8] https://github.com/sugarchain-project/sugarchain/issues/106
[9]
https://bitcoin.stackexchange.com/questions/111844/loadwallet-takes-too-much-and-times-out
[10] https://bitcoin.stackexchange.com/a/45713/1761
ANOTHER POSSIBLE BUG
======================
Even if my node is 100% sync:
2022-08-20T13:11:43Z UpdateTip: new
best=00000000000000000005bba0593c2be0f1d322223501591d2b31b544e3af3d0b
height=750300 version=0x2fffe000 log2_work=93.687081 tx=758181489
date='2022-08-20T13:11:16Z' progress=1.000000 cache=4.6MiB(34964txo)
After a "loadwallet" command I am getting an old / wrong balance. The
wallet is already empty because I had moved the funds to a new one 3 or 4
days ago but it is still showing the old balance. I didn't receive any
warning message saying the need for a rescan or something like that.
I am trying the "rescanblockchain" command but it is running and it taking
a looooooooooooooong time.
Best regards,
Felipe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220820/07f9887b/attachment.html>

2023-06-08 01:11:39

- 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

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

- reply

📅 Original date posted:2022-04-28
📝 Original message:Hi Keagan,
The worst case scenario is: no new proposals are accepted and the Bitcoin
remains the same. This is not so bad. I think a bad actor will usually want
to *add* (or remove) something that breaks. I don't know if the boycott of
new proposals is as effective in breaking Bitcoin. It means the more
important devs are not in full control, but they have the (kind of) power
of veto if they have really rational arguments. The most harm they can do
is delay things a little.
But remember: after all, everyone is free to fork the code, try to change
something and perhaps create undesirable splits in the network.
Felipe.
On Wed, Apr 27, 2022 at 3:32 PM Keagan McClelland <
keagan.mcclelland at gmail.com> wrote:
> Felipe,
>
> > 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.
>
> This is essentially an admission that devs have control over the protocol.
> Users "having control" but deferring their judgement to devs is not
> meaningfully different than devs "having control". Many people have
> asserted, quite strongly, that this ought not be how Bitcoin governs
> itself. I myself am on the fence about what is practically possible or not.
> However, let's say that your supposition is correct. How would we protect
> against a corollary scenario where a dev has a proposal that looks great
> but has dark ends that no one notices yet, if the process for evaluation
> more or less is to defer to "the most important devs" expertise? Presumably
> we hash this out in forums like this, but in order to "override" the "most
> important devs" we have to have a way (formalized or not) of deciding when
> the "lesser experts" in aggregate have better judgement.
>
> Erik,
>
> > There are many challenges with on-chain voting, here are a few:
>
> This may be hair-splitting but I feel it important to clarify that my
> proposal isn't voting per se. Calling it that doesn't bug me, but the
> mechanics are meaningfully different than a simple tally vote which is the
> intuition that I think that term conveys. As Billy mentions this proposal
> actually requires that miners block signals from inclusion in the block if
> they themselves do not signal. I'm not necessarily claiming this is a
> superior design overall, however the "flaw" you point out is by design in
> this case. My goal in the proposal was really to give users a means of
> applying direct economic pressure to miners, who do inevitably play a role
> in BIP8/BIP9 activation procedure.
>
> Ryan,
>
> > - you're feeding the Chainalysis beasts, when hodlers move their UTXOs;
>
> Definitely a frightening proposition I hadn't considered. It does open up
> the possibility of tracking individual preferences and targeting of
> political opponents.
>
> > - yuk, it's voting.
>
> I don't think the process of collecting information on user preference is
> in and of itself bad. Where I think Bitcoiners really want to avoid voting
> is this notion that 51% of the constituency can bully the other 49% into
> whatever they want. No part of my proposal suggests this, nor is it
> something I would want.
>
> -----
>
> I think there are a few questions surrounding the issue of soft fork
> activation. Perhaps it warrants zooming out beyond even what my proposal
> aims to solve. In my mind the most important questions surrounding this
> process are:
>
> 1. In an ideal world, assuming we could, with perfect certainty, know
> anything we wanted about the preferences of the user base, what would be
> the threshold for saying "this consensus change is ready for activation"?
> 1a. Does that threshold change based on the nature of the consensus
> change (new script type/opcode vs. block size reduction vs. blacklisting
> UTXOs)?
> 1b. Do different constituencies (end users, wallets, exchanges,
> coinjoin coordinators, layer2 protocols, miners) have a desired minimum or
> maximum representation in this "threshold"?
> 2. Given an answer from #1, what tests can we devise to measure those
> levels of support directly? If we can't measure it directly, can we measure
> different indicators that would help us infer or solve for the knowledge we
> want?
> 3. Can any of the answers to #2 be "gamed"? I'm defining "game" here to
> mean that the measurement taken, diverges from the ground truth we are
> trying to get at in such a way that its divergence would be undetectable.
>
> If we do not answer these sorts of questions we can get technical
> consensus through this messy process, but when it comes to assessing user
> consensus, it is just going to devolve into dogma and demagoguery as we
> each have our own perceptions or agendas and there is no rigorous way for
> anyone to refute our claims. This would, again, be an admission that devs
> ultimately do make protocol decisions. Perhaps it's unavoidable and we are
> doomed to this painful process of arguing with one another until
> there's only one opinion left standing (either because of merit or just
> plain old grit). However, if this is the case, I don't think we can
> honestly claim that devs don't control the protocol (as a group).
>
> I don't think we will have broad agreement on #1 as it is ultimately a
> value judgement and even the most intellectually honest people in Bitcoin
> dev are going to have different value sets. I think this is OK, to a
> degree. But where a lot of communication breakdown occurs is when people
> are debating the properties of #2/#3 when they don't even know that there
> is disagreement between them on #1. I think that everyone having an
> individual answer to #1 can make these discussions go a lot more smoothly
> in the technical sphere since I think most people can suspend their own
> values for the sake of analyzing the effectiveness of a particular
> approach. I am concerned, however, that if value differences are allowed to
> be passed off as technical evaluations, the quality of the conversation may
> erode to the point where no meaningful advancement can happen anymore,
> since we will lose our shared framework for understanding. If this occurs
> too soon, I believe quite strongly that Bitcoin will be captured through
> the increasing power of custodial institutions.
>
> Keagan
>
> On Wed, Apr 27, 2022 at 11:22 AM <micaroni at gmail.com> wrote:
>
>> 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/20220428/53b29505/attachment-0001.html>

2023-06-08 01:08:30

- 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

- 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

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