eric at voskuil.org [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 23:09:51

- reply

📅 Original date posted:2022-05-25
📝 Original message:> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On
Behalf
> Of Anthony Towns via bitcoin-dev
> Sent: Wednesday, May 25, 2022 11:56 AM
> So the other thing is what happens if the peer announcing packages to us
is
> dishonest?
>
> They announce pkg X, say X has parents A B C and the fee rate is garbage.
But
> actually X has parent D and the fee rate is excellent. Do we request the
> package from another peer, or every peer, to double check? Otherwise we're
> allowing the first peer we ask about a package to censor that tx from us?
>
> I think the fix for that is just to provide the fee and weight when
announcing
> the package rather than only being asked for its info? Then if one peer
makes
> it sound like a good deal you ask for the parent txids from them, dedupe,
> request, and verify they were honest about the parents.
Single tx broadcasts do not carry an advertised fee rate, however the'
feefilter' message (BIP133) provides this distinction. This should be
interpreted as applicable to packages. Given this message there is no reason
to send a (potentially bogus) fee rate with every package. It can only be
validated by obtaining the full set of txs, and the only recourse is
dropping (etc.) the peer, as is the case with single txs. Relying on the
existing message is simpler, more consistent, and more efficient.
> >> Is it plausible to add the graph in?
>
> Likewise, I think you'd have to have the graph info from many nodes if
you're
> going to make decisions based on it and don't want hostile peers to be
able to
> trick you into ignoring txs.
>
> Other idea: what if you encode the parent txs as a short hash of the wtxid
> (something like bip152 short ids? perhaps seeded per peer so collisions
will
> be different per peer?) and include that in the inv announcement? Would
> that work to avoid a round trip almost all of the time, while still giving
you
> enough info to save bw by deduping parents?
As I suggested earlier, a package is fundamentally a compact block (or
block) announcement without the header. Compact block (BIP152) announcement
is already well-defined and widely implemented. A node should never be
required to retain an orphan, and BIP152 ensures this is not required.
Once a validated set of txs within the package has been obtained with
sufficient fee, a fee-optimal node would accept the largest subgraph of the
package that conforms to fee constraints and drop any peer that provides a
package for which the full graph does not.
Let us not reinvent the wheel and/or introduce accidental complexity. I see
no reason why packaging is not simply BIP152 without the 'header' field, an
updated protocol version, and the following sort of changes to names:
sendpkg
MSG_CMPCT_PKG
cmpctpkg
getpkgtxn
pkgtxn
> > For a maximum 25 transactions,
> >23*24/2 = 276, seems like 36 bytes for a child-with-parents package.
>
> If you're doing short ids that's maybe 25*4B=100B already, then the above
is
> up to 36% overhead, I guess. Might be worth thinking more about, but maybe
> more interesting with ancestors than just parents.
>
> >Also side note, since there are no size/count params,
Size is restricted in the same manner as block and transaction broadcasts,
by consensus. If the fee rate is sufficient there would be no reason to
preclude any valid size up to what can be mined in one block (packaging
across blocks is not economically rational under the assumption that one
miner cannot expect to mine multiple blocks in a row). Count is incorporated
into BIP152 as 'shortids_length'.
> > wondering if we
> >should just have "version" in "sendpackages" be a bit field instead of
> >sending a message for each version. 32 versions should be enough right?
Adding versioning to individual protocols is just a reflection of the
insufficiency of the initial protocol versioning design, and that of the
various ad-hoc changes to it (including yet another approach in this
proposal) that have been introduced to compensate for it, though I'll
address this in an independent post at some point.
Best,
e
> Maybe but a couple of messages per connection doesn't really seem worth
> arguing about?
>
> Cheers,
> aj
>
>
> --
> Sent from my phone.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:09:51

- reply

📅 Original date posted:2022-05-25
📝 Original message:Given that packages have no header, the package requires identity in a
BIP152 scheme. For example 'header' and 'blockhash' fields can be replaced
with a Merkle root (e.g. "identity" field) for the package, uniquely
identifying the partially-ordered set of txs. And use of 'getdata' (to
obtain a package by hash) can be eliminated (not a use case).
e
> -----Original Message-----
> From: eric at voskuil.org <eric at voskuil.org>
> Sent: Wednesday, May 25, 2022 1:52 PM
> To: 'Anthony Towns' <aj at erisian.com.au>; 'Bitcoin Protocol Discussion'
> <bitcoin-dev at lists.linuxfoundation.org>; 'Gloria Zhao'
> <gloriajzhao at gmail.com>
> Subject: RE: [bitcoin-dev] Package Relay Proposal
>
> > From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On
> Behalf
> > Of Anthony Towns via bitcoin-dev
> > Sent: Wednesday, May 25, 2022 11:56 AM
>
> > So the other thing is what happens if the peer announcing packages to us
> is
> > dishonest?
> >
> > They announce pkg X, say X has parents A B C and the fee rate is
garbage.
> But
> > actually X has parent D and the fee rate is excellent. Do we request the
> > package from another peer, or every peer, to double check? Otherwise
> we're
> > allowing the first peer we ask about a package to censor that tx from
us?
> >
> > I think the fix for that is just to provide the fee and weight when
> announcing
> > the package rather than only being asked for its info? Then if one peer
> makes
> > it sound like a good deal you ask for the parent txids from them,
dedupe,
> > request, and verify they were honest about the parents.
>
> Single tx broadcasts do not carry an advertised fee rate, however the'
> feefilter' message (BIP133) provides this distinction. This should be
> interpreted as applicable to packages. Given this message there is no
reason
> to send a (potentially bogus) fee rate with every package. It can only be
> validated by obtaining the full set of txs, and the only recourse is
> dropping (etc.) the peer, as is the case with single txs. Relying on the
> existing message is simpler, more consistent, and more efficient.
>
> > >> Is it plausible to add the graph in?
> >
> > Likewise, I think you'd have to have the graph info from many nodes if
> you're
> > going to make decisions based on it and don't want hostile peers to be
> able to
> > trick you into ignoring txs.
> >
> > Other idea: what if you encode the parent txs as a short hash of the
wtxid
> > (something like bip152 short ids? perhaps seeded per peer so collisions
> will
> > be different per peer?) and include that in the inv announcement? Would
> > that work to avoid a round trip almost all of the time, while still
giving
> you
> > enough info to save bw by deduping parents?
>
> As I suggested earlier, a package is fundamentally a compact block (or
> block) announcement without the header. Compact block (BIP152)
> announcement
> is already well-defined and widely implemented. A node should never be
> required to retain an orphan, and BIP152 ensures this is not required.
>
> Once a validated set of txs within the package has been obtained with
> sufficient fee, a fee-optimal node would accept the largest subgraph of
the
> package that conforms to fee constraints and drop any peer that provides a
> package for which the full graph does not.
>
> Let us not reinvent the wheel and/or introduce accidental complexity. I
see
> no reason why packaging is not simply BIP152 without the 'header' field,
an
> updated protocol version, and the following sort of changes to names:
>
> sendpkg
> MSG_CMPCT_PKG
> cmpctpkg
> getpkgtxn
> pkgtxn
>
> > > For a maximum 25 transactions,
> > >23*24/2 = 276, seems like 36 bytes for a child-with-parents package.
> >
> > If you're doing short ids that's maybe 25*4B=100B already, then the
above
> is
> > up to 36% overhead, I guess. Might be worth thinking more about, but
> maybe
> > more interesting with ancestors than just parents.
> >
> > >Also side note, since there are no size/count params,
>
> Size is restricted in the same manner as block and transaction broadcasts,
> by consensus. If the fee rate is sufficient there would be no reason to
> preclude any valid size up to what can be mined in one block (packaging
> across blocks is not economically rational under the assumption that one
> miner cannot expect to mine multiple blocks in a row). Count is
incorporated
> into BIP152 as 'shortids_length'.
>
> > > wondering if we
> > >should just have "version" in "sendpackages" be a bit field instead of
> > >sending a message for each version. 32 versions should be enough right?
>
> Adding versioning to individual protocols is just a reflection of the
> insufficiency of the initial protocol versioning design, and that of the
> various ad-hoc changes to it (including yet another approach in this
> proposal) that have been introduced to compensate for it, though I'll
> address this in an independent post at some point.
>
> Best,
> e
>
> > Maybe but a couple of messages per connection doesn't really seem worth
> > arguing about?
> >
> > Cheers,
> > aj
> >
> >
> > --
> > Sent from my phone.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:08:48

- reply

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

2023-06-07 23:08:47

- reply

📅 Original date posted:2022-05-04
📝 Original message:Good evening ZmnSCPxj,
For the sake of simplicity, I'll use the terms lender (Landlord), borrower (Lessor), interest (X), principal (Y), period (N) and maturity (height after N).
The lender in your scenario "provides use" of the principal, and is paid interest in exchange. This is of course the nature of lending, as a period without one's capital incurs an opportunity cost that must be offset (by interest).
The borrower's "use" of the principal is what is being overlooked. To generate income from capital one must produce something and sell it. Production requires both capital and time. Borrowing the principle for the period allows the borrower to produce goods, sell them, and return the "profit" as interest to the lender. Use implies that the borrower is spending the principle - trading it with others. Eventually any number of others end up holding the principle. At maturity, the coin is returned to the lender (by covenant). At that point, all people the borrower traded with are bag holders. Knowledge of this scam results in an imputed net present zero value for the borrowed principal.
While the lack of usability is a cost to the lender, it is not a benefit to the borrower. The lender incurs no risk, and will obtain no reward - as the loan is of no value. Failure to deploy capital is an opportunity cost, and locking it up is not deployment.
Now, even if we accept the generous (economically irrational) assumption that money must increase in price (i.e. trades from more goods) over any given period, we are still left with the observation that the presumed appreciation would accrue to the lender absent lending, making it pointless.
e
> -----Original Message-----
> From: ZmnSCPxj <ZmnSCPxj at protonmail.com>
> Sent: Tuesday, May 3, 2022 7:37 PM
> To: Eric Voskuil <eric at voskuil.org>
> Cc: Chris Belcher <belcher at riseup.net>; Bitcoin Protocol Discussion <bitcoin-
> dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for
> BIP39 seeds
>
> Good morning e,
>
>
> > It looks like you are talking about lending where the principal return is
> guaranteed by covenant at maturity. This make the net present value of the
> loan zero.
>
> I am talking about lending where:
>
> * Lessor pays landlord X satoshis in rent.
> * Landlord provides use of the fidelity bond coin (value Y) for N blocks.
> * Landlord gets the entire fidelity bond amount (Y) back.
>
> Thus, the landlord gets X + Y satoshis, earning X satoshis, at the cost of having Y
> satoshis locked for N blocks.
>
> So I do not understand why the value of this, to the landlord, would be 0.
> Compare to a simple HODL strategy, where I lock Y satoshis for N blocks and
> get Y satoshi back.
> Or are you saying that a simple HODL strategy is of negative value and that
> "zero value" is the point where you actively invest all your savings?
> Or are you saying that HODL strategy is of some value since it still allows you
> to spend funds freely in the N blocks you are HODLing them, and the option to
> spend is of value, while dedfinitely locking the value Y for N blocks is equal to
> the value X of the rent paid (and thus net zero value)?
>
> Regards,
> ZmnSCPxj

2023-06-07 23:02:34

- reply

📅 Original date posted:2022-01-20
📝 Original message:> BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8 nor BIP9, so characterization one way or another is moot IMO.
For a selective definition of “based” you can draw any conclusion you desire. However I was very clear, as was Luke, and the history on this issue is equally clear, that the *only* material distinction (and the one that we are discussing) is activation with or without majority hash power support. BIP9/ST requires this support, BIP8 does not. The characterization is not moot. It is the central issue and always has been. There was no compromise on this question made in Taproot.
e
From: Billy Tetrud <billy.tetrud at gmail.com>
Sent: Thursday, January 20, 2022 7:23 AM
Thank you Eric for pointing out the factual errors in LukeJr's mention and implications around BIP8. The fact is that the ST pull request was described as <https://github.com/bitcoin/bitcoin/pull/21377> "BIP9-based". TBH BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8 nor BIP9, so characterization one way or another is moot IMO. In any case, I also agree with Michael that this isn't the place to have a long discussion about activation method. That discussion should be kept separate. I'd go so far to say that BIPs should not advocate for any particular activation method, but should only go so far as to mention what types of activation methods are possible (if some types aren't possible for some reason). Separation of concerns would be very useful on that front to reduce noise in conversations.
Thanks,
BT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220120/05477ab0/attachment.html>

2023-06-07 22:56:42

- reply

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

2023-06-07 22:55:38

- reply

📅 Original date posted:2021-06-30
📝 Original message:> From: Jorge Timón <jtimon at jtimon.cc>
>> "Soft forks aren’t compatible without miner enforcement"
> Compatible with what?
There is a good summary of what is meant by this term in BIP141:
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
"Backward compatibility
As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases where the witness programs are equal to 0, which the script must fail). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features."
The explanation is however incomplete. If majority hash power does not enforce the new rules, the above is incorrect. Granted the word "operate" is vague, but clearly what is intended is that "non-upgraded" nodes will not be on a different coin. But in fact they would be. The underlying presumption is that BIP141 is not only signaled, but enforced by majority hash power.
>> "Soft forks without miner support cause splits".
> No, what causes splits are 3 things:
>
> 1) bugs
> 2) coordination mistakes
> 3) people wanting different rules.
#3 (and possibly #4) is what we're talking about, so it's not at all clear why you said "no".
People change their rules, because #3. If majority hash power does not enforce this (soft) change, it's a chain split.
> Let me give an example. Let's say all users want change A.
>
> Only 60% miners want it.
> When it activates with LOT=true, will this cause a split?
No, regardless of percentage adoption. You've proposed that it' is majority hash power enforced.
Furthermore, the term compatibility (see above) implies that not everyone (your impossible presumption of 100%) is aligned.
This is not a debatable subject as far as I'm concerned, but it's worth discussion for those who aren't familiar.
e

2023-06-07 22:55:36

- reply

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

2023-06-07 22:51:26

- reply

📅 Original date posted:2021-04-07
📝 Original message:You may activate any time you want.
e
From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On Behalf Of Claus Ehrenberg via bitcoin-dev
Sent: Wednesday, April 7, 2021 6:42 AM
To: Rusty Russell <rusty at rustcorp.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
As a user, I think it's very important for me to know if Taproot is eventually coming or not. So why not make it so that if _either_ miners _or_ users decide for Taproot, it will activate no matter what. Accepting a chain split is imo the fairest way to 'resolve the conflict' (it can't be resolved anyway).
That would probably mean running ST and and UASF concurrently.
The upside would be that we've got a safe date for Taproot, except neither users nor miners want it.
Cheers,
Claus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210407/dafd545f/attachment.html>

2023-06-07 18:29:39

- reply

📅 Original date posted:2021-03-01
📝 Original message:On Sun, Feb 28, 2021 at 10:18 AM Leo Wandersleb via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:
> Only headers need to be downloaded sequentially so downloading relevant blocks from one node is totally possible with gaps in between.
In fact this is exactly how libbitcoin v4 works. We download and store blocks in parallel. In the case of a restart block gaps are repopulated. Given that headers are validated, we go after the most responsive nodes. Based on standard deviation, we drop the slowest peers and rebalance load to new/empty channels. We make ordered but not necessarily sequential requests. There is no distinction between “initial” block download, a restart, or a single or few blocks at the top. So it’s referred to as continuous parallel block download.
But we don’t prune. Personally I consider this counterproductive. Apart from the complexity, it’s not healthy. And the chain grows linearly with storage cost falling exponentially, leading to a straightforward conclusion.
e
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210301/568af3cd/attachment.html>

2023-06-07 18:29:35

- reply

📅 Original date posted:2021-03-03
📝 Original message:> and all transactions should be open to the scrutiny of an honest government.
>From what do you derive the moral judgement “should” in this context?
> The value proposition is … because people will trust the system?
So, it’s valuable because it’s trusted? Trusted to do what exactly? What that government money doesn’t already do, specifically.
> If it is not necessary to maintain consensus then what is consensus?
Nothing is “necessary”. Consensus is an agreement among people. It’s voluntary. Any person can choose to leave, create or join another consensus, or stay where they are.
> BCH exists in addition to BTC Bitcoin.
Exactly, people are free to do what they want. Nobody “should” do anything except that which they want to do. This and this alone is the “highest value” if one accepts the moral principle of non-aggression. You do not appear to, and I’m afraid that may be well outside the consensus view among core bitcoin developers (the people you are talking to).
e
From: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>
Sent: Tuesday, March 2, 2021 6:55 PM
To: Eric Voskuil <eric at voskuil.org>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Cc: Ariel Lorenzo-Luaces <arielluaces at gmail.com>
Subject: Re: [bitcoin-dev] Taproot NACK
Good Afternoon,
All people are entitled to privacy in their purse, and all transactions should be open to the scrutiny of an honest government. You can debate whether any government is honest. Mixing does not remove the record from the public ledger, where it is possible to see that any Bitcoin has transferred from an UTXO to some Pay-To address even with some amount of transaction in between them. The value proposition is the same <https://www.youtube.com/watch?v=l9jOJk30eQs> https://www.youtube.com/watch?v=l9jOJk30eQs - because people will trust the system; people trust the existing consensus.
Let us dispense with the screen and deal with the issue only. If it is not necessary to maintain consensus then what is consensus?
The intrinsic value of Bitcoin is because of the existing consensus. Even if any proposal gains consensus there is no objective way to show it improves the intrinsic value without trialing and the possibility of failure and so protecting the existing consensus should be the highest value. This understanding is the reason BCH exists in addition to BTC Bitcoin.
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: Eric Voskuil <eric at voskuil.org <mailto:eric at voskuil.org> >
Sent: Tuesday, 2 March 2021 9:37 AM
To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au <mailto:willtech at live.com.au> >; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
Cc: Ariel Lorenzo-Luaces <arielluaces at gmail.com <mailto:arielluaces at gmail.com> >
Subject: Re: [bitcoin-dev] Taproot NACK
To be clear, is this a NACK because Taproot reduces “transparency” (increases privacy) on the chain (“maintaining consensus” is obviously an argument against any protocol change, so that’s a red herring)?
And is it your theory that only an “honest” (statute abiding) person should have privacy, and not against the state, and/or that mixers are sufficient privacy?
Personally, I’m not moved by such an argument. What do you think is the value proposition of Bitcoin?
e
On Mar 1, 2021, at 14:21, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:

Good Afternoon,
I am going to take tough terms with much of your reply and do appreciate a courteous practice. Having previously made public disclosure of my affiliation with Jambler.io it seems sufficient to disclose my affiliation through the link in my email signature block.
My concern is not increased privacy it is maintaining consensus values and the transparency of the blockchain wherein all transactions are published in an immutable record and that forbids the redaction of information by any obfuscation. A separate concern is the availability of a privacy suitable for cash should a Bitcoin user desire and especially without disturbing the existing consensus.
The use of a Bitcoin Mixer is to enable standard equivalent privacy. As you may experience yourself, you do not allow people to follow you around looking in your purse, suppose you are dealing entirely with cash, and to see where and how much you fill it up, and where you spend. Nonetheless, for an honest person, their wallet is available for government audit as are their financial affairs. This is consistent with the existing operation of consensus.
My full email signature block is a disclosure where I have some affiliation with the referenced website being that it carries at least some information that I have provided or that in some way I am associated perhaps only making use of their services. For example, I hardly make a profit from LinkedIn just my information is there. Also, I have made previous public disclosure of the affiliation. Bitcoin Mixer 2.0 is a partner mixer run by Jambler.io wherein I receive a service referral fee and am not in receipt of any part of the process transaction. The operation block diagram provided by Jambler.io is provided here and attached.
<ip.bitcointalk.org.png>
[ip.bitcointalk.org.png]-Operation of Jambler.io partner mixer
https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png <https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png&t=622&c=gTi7r1cfh-yynw> &t=622&c=gTi7r1cfh-yynw
from this thread https://bitcointalk.org/index.php?topic=5267588
The installation script provided by Jambler.io that is the basis of my referral website is also publicly published,
https://github.com/jambler-io/bitcoin-mixer
The disclosure for the partner program is available from Jambler.io however and is made prominently on my referral website. While it may seem lucrative at first I insist all partner profits are reportable on your personal income.
https://jambler.io/become-partner.php
I am certainly better than confident that you appreciate the difference between an open and transparent blockchain and the ability of the user to not reveal details of the content of their wallet publicly.
If further clarification is required may I suggest you pay a token and mix some Bitcoin wherein our discussion may then have some point of reference.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au <http://www.willtech.com.au>
www.go-overt.com <http://www.go-overt.com>
and other projects
earn.com/willtech
linkedin.com/in/damianwilliamson
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this email if misdelivered.
_____
From: Ariel Lorenzo-Luaces <arielluaces at gmail.com <mailto:arielluaces at gmail.com> >
Sent: Monday, 1 March 2021 12:07 AM
To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au <mailto:willtech at live.com.au> >; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
Subject: Re: [bitcoin-dev] Taproot NACK
Hello LORD HIS EXCELLENCY JAMES HRMH
I find a striking dichotomy between your concern of increased privacy in bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com <http://www.go-overt.com>
At first your concerns seemed genuine but after seeing your promotion of a bitcoin mixer I'm thinking your concerns may be more profit motivated? I can't tell since you failed to disclose your relationship with the mixer.
Could you please clarify your association with the bitcoin mixer and moving forward could you please always do proper disclosure any time you're publically talking about bitcoin transaction privacy. It's only fair to do so as to not mislead people in an attempt to manipulate at worst and just a courteous practice at best.
Cheers
Ariel Lorenzo-Luaces
On Feb 28, 2021, at 4:36 AM, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:
Good Evening,
Thank-you for your advice @JeremyRubin <https://twitter.com/JeremyRubin> on the basis you advise, "Taproot does not enable monero-like privacy features", I am prepred to withdraw my NACK notably that the existing feeatures of Bitcoin MUST be maintained, and whereby the UTXO of a transaction is identifiable, the PayTo Address, and the amount all without any obfuscation.
Lightning does not really provide obfuscation, it provides a result of a subset of transactions although the operation of the channel is observable to the parties.
The reports I were reading concerning the supposed operation of Taproot published in a public media channel may have been speculation or misinformation nonetheless it is prudent to conditionally reply as you see that I have. It is important not to allow things to slip through the cracks. As you may believe may astute reviewers could make a full disclosure to this list it is not to be expected.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
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 <mailto:willtech at live.com.au> >; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> >
Subject: Re: [bitcoin-dev] Taproot NACK
I have good news for you: Taproot does not enable monero-like privacy features any moreso than already exist in Bitcoin today. At its core, taproot is a way to make transactions with embedded smart contracts less expensive, done so in a manner that may marginally improve privacy dependent on user behavior (but not in the monero-like way you mention). For example, it makes it possible for lightning channels to look structurally similar to single key wallets, but it does nothing inherently to obfuscate the transaction graph as in monero.
Such "monero-like" transaction graph obfuscation may already exist in Bitcoin via other techniques (coinjoin, payjoin, coinswap, lightning, etc) with or without Taproot, so the point is further moot.
Do you have a source on your reporting?
You may wish to rescind your nack.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:
Good Afternoon,
It has been reported that Taproot will enable some Monero like features including the ability to hide transactions.
If that is the case I offer a full NACK and let me explain.
A part of the benefit of using Bitcoin is its honesty. The full transaction is published on the blockchain. If that were to change so that transactions may be obfuscated from scrutiny then any government would have unlimited impetus to ban Bitcoin, and speculation has that is the reason India has been reported to have banned cryptocurrencies already.
I am in support of the expanded use case of Bitcoin without harming the established robust fairness and equal equity offered. The core functionality of Bitcoin, its values, must remain unaltered.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au <http://www.willtech.com.au>
www.go-overt.com <http://www.go-overt.com>
and other projects
earn.com/willtech <http://earn.com/willtech>
linkedin.com/in/damianwilliamson <http://linkedin.com/in/damianwilliamson>
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this email if misdelivered.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_____
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<ip.bitcointalk.org.png>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210303/3091d805/attachment-0001.html>

2023-06-07 18:29:26

- reply

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