Re: [bitcoin-dev] Yesterday’s UASF (LOT=true) kick off meeting

[Ariel Luaces via bitcoin-dev]

On Wed, Mar 3, 2021 at 12:25 PM Michael Folkson via bitcoin-dev
 wrote:
>
> At this point in time it also appears the greatest risk to Taproot
> dying a slow death is a small group of developers who think talking in
> conservative tones and talking about endless philosophy makes Bitcoin
> a conservative system. (It doesn’t, it just makes it a dying, decaying
> one).

The current risk to taproot and all future activations is a loud
minority of users who are threatening to co-opt a LOT=false activation
by switching the parameter and organizing a marketing blitz that could
end in a fork if things don't go well.
As long as that threat persists consensus won't be reached. Then an
activation client probably won't be released because I don't expect
many devs will have an appetite for writing code that either doesn't
have consensus or code that will be manipulated into creating
consensus conflicts.
I think Bitcoin is fine staying as is until that minority forks off
with their own alt-node. If the UASF minority is dead set on creating
the alt-node then I only hope it's released quickly so the deadlock
can break. A quick UASF fork allows for an early LOT=false activation.

Cheers
Ariel Lorenzo-Luaces

> --
> Michael Folkson
> Email: michaelfolk...@gmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot NACK

[Eric Voskuil via bitcoin-dev]

Your Excellency,

You don’t seem to understand how Bitcoin currently works. A signature is a 
mathematical /probabilistical proof that the person who signed (the output) is 
the same person who created the script (the input) that was paid to (i.e. not 
fraud). You cannot see that he is that person, you can only do the math - 
giving yourself a reasonable assurance that it is not a fraud.

Taproot is not a proposed change to this design, so I’m not sure to what 
exactly you are objecting. The math continues to be the sole assurance and 
visibility that the money was created and transferred in accordance with the 
agreed rules (consensus). There is no other way for anyone to “look at” 
potential fraud on the chain.

If you are aware of any flaw in the existing or proposed mathematics that would 
enable fraudulent creation or transfer of bitcoin, please spell it out for us.

e

> On Mar 3, 2021, at 21:10, LORD HIS EXCELLENCY JAMES HRMH 
>  wrote:
> 
> Good Afternoon,
> 
> I will reply privately here, what do you say I am not in support of 
> fungibility? This fungibility is because of consensus including transparency. 
> Otherwise, if it is just a fraud no-one can look at it.
> 
> KING JAMES HRMH
> 
> 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  on behalf 
> of Felipe Micaroni Lalli via bitcoin-dev 
> 
> Sent: Thursday, 4 March 2021 3:30 AM
> To: e...@voskuil.org ; Bitcoin Protocol Discussion 
> 
> Subject: Re: [bitcoin-dev] Taproot NACK
>  
> 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 
>>  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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[yanmaani--- via bitcoin-dev]

No, it's not the same. This approach is not guaranteed to activate. On 
flag day, it'd check for (say) 20% miner support, and activate if so. If 
>80% of miners oppose, it'd fail. LOT=true (and declining percentage) will activate unconditionally.


Also, the day before lock-in, this would still have 95% as the limit, 
not a linear interpolation between 95% and the lock-in limit.


This checks: if miner support > 95% support it (ever) or miner support > 
X% (on flag day), activate

DP checks: if miner support > lerp(95%, 0%) (ever), activate
LOT=true checks: on flag day, activate unconditionally

(Erik: I forgot to hit reply all on my last e-mail, that's why you're 
seeing this twice)


On 2021-03-02 06:11, Erik Aronesty wrote:

This is the declining percentage of signaling activation.

It has all the benefits of both.

Eventually it becomes a LOT=true, so any argument for LOT=true holds

And all of the arguments for LOT=false are satisfied by the cool down
period.

On Mon, Mar 1, 2021, 12:05 PM yanmaani--- via bitcoin-dev
 wrote:


How about a compromise?

With LOT=false, taproot will be activated if at least 95% of the
miners
vote yes.
With LOT=true, taproot will be activated if at least 0% of the
miners
vote yes.
...with LOT=maybe, taproot will be activated if at least ~some% of
the
miners vote yes?

If you want the 'emergency cancel' feature without binding yourself
to
it, couldn't you have some middle-of-the-road solution? "Taproot
will be
enabled if miner support ever goes above 95%, or on flag day if
miner
support is >20% then". That would prevent obstreperous miners from
doing
too much damage, while still hopefully making it possible to bail
out of
a disaster.

On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:

On Sun, Feb 28, 2021 at 07:33:30PM +, Luke Dashjr via

bitcoin-dev

wrote:

As we saw in 2017 with BIP 9, coordinating activation by miner

signal

alone,
despite its potential benefits, also leaves open the door to a

miner

veto.


To the contrary, we saw in 2017 that miners could *not*

successfully

veto a BIP 9 activation. It was certainly more effort and risk

than was

desirable to override the attempted veto, but the attempt at

vetoing

nevertheless failed.


It wouldn't be much different than adding back the inflation bug
(CVE-2018-17144) and trusting miners not to exploit it.


That is ridiculous FUD.


With LOT=False in the picture, however, things can get messy:


LOT=false is always in the picture if we are talking about a

soft-fork:

the defining feature of a soft-fork is that old node software

continues

to work, and old node software will be entirely indifferent to

whether

activation is signalled or not.


some users will
enforce Taproot(eg) (those running LOT=True), while others will

not

(those
with LOT=False)


If you are following bip8 with lockinontimeout=false, you will

enforce

taproot rules if activation occurs, you will simply not reject

blocks

if
activation does not occur.


Users with LOT=True will still get all the safety thereof,
but those with LOT=False will (in the event of miners deciding to



produce a
chain split) face an unreliable chain, being replaced by the

LOT=True

chain
every time it overtakes the LOT=False chain in work.


This assumes anyone mining the chain where taproot does not

activate is

not able to avoid a reorg, despite having majority hashpower (as
implied
by the lot=true chain having to overtake them repeatedly). That's
absurd;
avoiding a reorg is trivially achieved via running

"invalidateblock",

or
via pool software examining block headers, or via a patch along

the

lines
of MUST_SIGNAL enforcement, but doing the opposite. For

concreteness,

here's a sketch of such a patch:





https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f



For 2 weeks, users with LOT=False would not have a usable

network.


That's also ridiculous FUD.

If it were true, it would mean the activation mechanism was not
acceptable, as non-upgraded nodes would also not have a usable

network

for the same reason.

Fortunately, it's not true.

More generally, if miners are willing to lose significant amounts

of

money mining orphan blocks, they can do that at any time. If

they're

not inclined to do so, it's incredibly straightforward for them to



avoid
doing so, whatever a minority of other miners might do.


The overall risk is maximally reduced by LOT=True being the only
deployed
parameter, and any introduction of LOT=False only increases risk
probability
and severity.


LOT=false is the default behaviour of everything single piece of

node

software out there. That behaviour doesn't need to be introduced,

it's

already universal.

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Luke Kenneth Casson Leighton via bitcoin-dev]

would it help by first setting a regular period of e.g. 6 months when
only at that time would consensus rules ever be changed?  not, "6
months from now taproot will be introduced', a rule, "*any* consensus
change regardless of what they are (including NO change) will *ONLY*
be made at regular interval period X months".

this stops dead efforts by bots to announce "consensus! rules! are
changing!" because if it's not at the exact time-period it's clearly
bullshit.

l.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Matt Corallo via bitcoin-dev]

On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote:
While I support essentially any proposed taproot activation method, including a flag day activation, I think it is 
premature to call BIP8 dead.


Even today, I still think that starting with BIP8 LOT=false is, generally speaking, considered a reasonably safe 
activation method in the sense that I think it will be widely considered as a "not wholly unacceptable" approach to 
activation.


How do you propose avoiding divergent consensus rules on the network, something which a number of commentors on this 
list have publicly committed to?


After a normal and successful Core update with LOT=false, we will have more data showing broad community support for the 
taproot upgrade in hand.


I think this is one of the strongest arguments against a flag day activation, but, as I described in more detail in the 
thread "Straight Flag Day (Height) Taproot Activation", I'm not sure we aren't there enough already.


In the next release, 6 months later or so, Core could then confidently deploy a BIP8 LOT=true 


Could you clarify what an acceptable timeline is, then? Six months from release of new consensus rules to activation (in 
the case of a one-year original window) seems incredibly agressive for a flag-day activation, let alone one with 
forced-signaling, which would require significantly higher level of adoption to avoid network split risk. In such a 
world, we'd probably get Taproot faster with a flag day from day one.


client, should it prove to be necessary.  A second Core deployment of LOT=true would mitigate some of the concerns with 
LOT=false, but still provide a period beforehand to objective actions taken by the community in support of taproot.  We 
don't even have to have agreement today on a second deployment of LOT=true after 6 months to start the process of a 
LOT=false deployment. The later deployment will almost certainly be moot, and we will have 6 months to spend debating 
the LOT=true deployment versus doing a flag day activation or something else.


That was precisely the original goal with the LOT=false movement - do something easy and avoid having to hash out all 
the technical details of a second deployment. Sadly, that's no longer tennable as a number of people are publicly 
committed to deploying LOT=true software on the network ASAP.


Matt
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[yanmaani--- via bitcoin-dev]

On 2021-03-03 20:48, Chris Belcher wrote:

On 03/03/2021 17:30, yanma...@cock.li wrote:
Is that supposed to be a good thing? "We should do X because it'll 
work"
doesn't prove X is actually good. These things can be evil, but they 
can

also be legitimate opposition to a change. Taking away the power of a
"social media blitz" is not guaranteed to be a good thing!

It is good that social media drama can only make its own followers fork
away. In bitcoin people represent themselves, if they want certain 
rules

enforced they should have to actually tell their software to do that.
The problem with BIP8 is that social media drama has a incentive to
promote brinksmanship.


Tell their software to do it, yes, but fork it? That seems like a big 
"I'm sorry Dave, I'm afraid I can't do that" moment. If I tell Bitcoin 
Core to do something, it seems like a bad thing that it would favor the 
Core devs' wishes ("Get Taproot done") over mine.



That will only work for really egregious changes. In practice, most
people will trust Core on all other (non-egregious) decisions, because
of the inertia inherent in disobeying them.

[...]
You're right in suggesting that it will work, but the reason why it 
will

work is because nobody wants to disobey Core. It seems immoral to
exploit this fact.



It is not correct to say that this will work because "nobody will
disobey Core". In reality it will work because basically everyone 
either

wants taproot or has no opinion about taproot.


Both can be true at the same time. This is going to work because 
basically nobody opposes Taproot. But if you did have some people 
opposing Taproot, it would still work, because nobody would want to 
disobey Core.



Your argument depends heavily on the word "egregious". I've shown that
for harmful changes like censorship can be resisted by the bitcoin
community. Can you come up with an example of a bad change which won't
be resisted?


Example 1: There is currently a specific mining pool planning to 
blacklist addresses on sanctions lists. If they were to 
convince/bribe/threaten Core to soft-fork so as to burn one specific 
UTXO worth $1, the only direct victim of that would be the holder of 
that UTXO, who loses only $1 from it.


Example 2: A soft fork to decrease the block size by 0.1%.

If we assume that the current block size is optimal and censorship is 
bad, it seems simultaneously true that

1) it would be bad to decrease the block size or to burn that UTXO
2) nobody would be wiling to fight a war over a 0.1% decrease or a $1 
loss to one guy


You might say that these are minor changes. Sure. But that's what I'm 
saying: if the change is big ("egregious") enough to seriously 
inconvenience people, they would fight it, but if it's trivial (thought 
still bad), the inertia of Core would force them to accept it.



Here's another example of an easily-resisted change: A Core team that's
been compromised might do a flag-day UASF where transactions are only
confirmed if they pay a minimum of 1000 sat/vbyte in miner fee. The
community could resist this by doing a counter-UASF where a transaction
paying just 1 sat/vbyte is required to be included in the first block
after the flay day.


(Nitpick: Miners would probably not support it, because less people 
would be willing to pay that fee.)


Sure, and this change would be resisted because it seriously 
inconveniences people. But what if it's just 2sat/vbyte?


At least you shouldn't hard-code it and require dissenters to fork 
away.

I exhort you to consider making all this controversial stuff settings
that can be changed by RPC command or command-line flag; set the 
default

value sure, but requiring a fork to change it is, in my opinion,
oppressive.

What alternative do you suggest? If you advocate allowing miners to
activate soft forks then that still won't protect users. Because miners
won't save users in my above example of a 1000 sat/vbyte price floor, 
in

fact miners would see their income greatly increased if the soft fork
was successful. So in fact the ability to do a counter-UASF is always
what actually protected users, miner protection is nothing something to
count on.


I don't disagree. The ability to do a counter-UASF should also be added, 
if it's envisioned somebody might want to do that.


Basically, I think that Core should provide users with the tools to 
express their views and to exercise their economic power, and they could 
give them default values according to what they think best.


However, they shouldn't force people to use a forked client if they want 
to disobey them. That would be to abuse the power vested in the 
development group.



On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:

Enter flag day activation. With a flag day there can be no
brinksmanship. A social media blitz cant do anything except have its 
own
followers fork away. Crucially, miner signalling cant be used to 
change
the activation date for nodes that didn't choose to and just 

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Russell O'Connor via bitcoin-dev]

While I support essentially any proposed taproot activation method,
including a flag day activation, I think it is premature to call BIP8 dead.

Even today, I still think that starting with BIP8 LOT=false is, generally
speaking, considered a reasonably safe activation method in the sense that
I think it will be widely considered as a "not wholly unacceptable"
approach to activation.

After a normal and successful Core update with LOT=false, we will have more
data showing broad community support for the taproot upgrade in hand.  In
the next release, 6 months later or so, Core could then confidently deploy
a BIP8 LOT=true client, should it prove to be necessary.  A second Core
deployment of LOT=true would mitigate some of the concerns with LOT=false,
but still provide a period beforehand to objective actions taken by the
community in support of taproot.  We don't even have to have agreement
today on a second deployment of LOT=true after 6 months to start the
process of a LOT=false deployment. The later deployment will almost
certainly be moot, and we will have 6 months to spend debating the LOT=true
deployment versus doing a flag day activation or something else.

I don't think we need to start self-sabotaging our efforts to get taproot
activated this year just yet.  Let's cherry-pick the commits of PR #19573
to split it up into non-MUST_SIGNAL and MUST_SIGNAL components, and get
some reviews on that first.  Then afterwards we can decide if BIP8 is dead
or not.

On Wed, Mar 3, 2021 at 9:39 AM Chris Belcher via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The bitcoin world is close to total gridlock on the question of how to
> activate taproot. There's no agreement on activation[1][2], and if an
> agreement isn't reached then nothing happens. That would be really
> terrible because we'd miss out on the benefits of taproot and
> potentially other future soft forks.
>
> A major problem with BIP8 is that it would result to a situation where
> different parts of the bitcoin ecosystem run different consensus rules.
> Some people will run LOT=true and others LOT=false. Worst of all, it
> becomes vulnerable to a twitter/reddit/social media blitz which could
> attempt to move the date of miner activation around.
>
> Twitter and reddit drama provide a perfect cover for social attacks on
> bitcoin.
>
> Forced signalling leads to brinksmanship. Where two or more sides
> (backed up by social media drama) enter into a game of chicken with
> deployed nodes. If one of them doesn't concede then we get a damaging
> chain split. And the $1 trillion in value that the bitcoin network
> protects is put at risk. From the point of view of a miner or big
> exchange stuck in the middle, if they look at the ecosystem of twitter
> and reddit (especially if you think about all the problems with bots and
> sockpuppets) they have no idea which consensus rules they should
> actually follow and exactly what date they take effect. Miners,
> exchanges, merchants and the rest of the ecosystem exist to serve their
> customers and users, and trouble happens when they don't know what their
> customers really want. Social media attacks are not just a theoretical
> concern; back during the block size drama, the bitcoin reddits were
> targetted by bots, sockpuppets and brigading[3].
>
> Enter flag day activation. With a flag day there can be no
> brinksmanship. A social media blitz cant do anything except have its own
> followers fork away. Crucially, miner signalling cant be used to change
> the activation date for nodes that didn't choose to and just passively
> follow signalling. Changing the activation date requires all those users
> to actually run different node software.
>
> Flag day activation works simply: we choose a block height and after
> that block height the new taproot rules become enforced.
>
>
> Supporters of the permissionless, "users rule" approach of LOT=true
> should be happy because it completely takes miners out of activation.
>
> Supporters of the safe, conservative approach of LOT=false can be made
> happy with a few ways of derisking:
>
> * Getting mining pools, businesses and users to look at the code and ask
> if they (a) think its either neutral or good for their business or use
> case and (b) they believe others view it similarly and that the
> consensus changes proposed have a good social consensus around them.
>
> * Setting the flag day far in the future (18 months or 2 years in the
> original proposal[3]).
>
>
> == What if flag day activation is used maliciously? ==
>
> What if one day the Core developer team is co-opted and uses the flag
> day method to do something bad? For example, a soft fork where sending
> to certain blacklisted addresses is not allowed. The bitcoin user
> community who wants to resist this can create their own
> counter-soft-fork full node, where the first block after the flag day
> MUST pay to one of those addresses on the blacklist. This forces a chain
> split between the 

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[Chris Belcher via bitcoin-dev]

It is good that social media drama can only make its own followers fork
away. In bitcoin people represent themselves, if they want certain rules
enforced they should have to actually tell their software to do that.
The problem with BIP8 is that social media drama has a incentive to
promote brinksmanship.


It is not correct to say that this will work because "nobody will
disobey Core". In reality it will work because basically everyone either
wants taproot or has no opinion about taproot.

Your argument depends heavily on the word "egregious". I've shown that
for harmful changes like censorship can be resisted by the bitcoin
community. Can you come up with an example of a bad change which won't
be resisted?


Here's another example of an easily-resisted change: A Core team that's
been compromised might do a flag-day UASF where transactions are only
confirmed if they pay a minimum of 1000 sat/vbyte in miner fee. The
community could resist this by doing a counter-UASF where a transaction
paying just 1 sat/vbyte is required to be included in the first block
after the flay day.

What alternative do you suggest? If you advocate allowing miners to
activate soft forks then that still won't protect users. Because miners
won't save users in my above example of a 1000 sat/vbyte price floor, in
fact miners would see their income greatly increased if the soft fork
was successful. So in fact the ability to do a counter-UASF is always
what actually protected users, miner protection is nothing something to
count on.



On 03/03/2021 17:30, yanma...@cock.li wrote:
> On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:
>> Enter flag day activation. With a flag day there can be no
>> brinksmanship. A social media blitz cant do anything except have its own
>> followers fork away. Crucially, miner signalling cant be used to change
>> the activation date for nodes that didn't choose to and just passively
>> follow signalling. Changing the activation date requires all those users
>> to actually run different node software.
> 
> Is that supposed to be a good thing? "We should do X because it'll work"
> doesn't prove X is actually good. These things can be evil, but they can
> also be legitimate opposition to a change. Taking away the power of a
> "social media blitz" is not guaranteed to be a good thing!
> 
>> What if one day the Core developer team uses the flag
>> day method to do something bad? The bitcoin user
>> community who wants to resist this can create their own
>> counter-soft-fork full node. This forces a chain
>> split. The real bitcoin which most people follow will be
>> the chain without censorship.
> 
> [edited for brevity]
> 
> That will only work for really egregious changes. In practice, most
> people will trust Core on all other (non-egregious) decisions, because
> of the inertia inherent in disobeying them.
> 
> What you suggest may be an efficient way to ram taproot through, but is
> it inherently good? Nothing is free. This seems like de-facto forcing
> people to go along with you, because you're convinced you're right. In
> this case, you are, but you'd be convinced you'd be right even if you
> weren't so.
> 
> You're right in suggesting that it will work, but the reason why it will
> work is because nobody wants to disobey Core. It seems immoral to
> exploit this fact.
> 
> At least you shouldn't hard-code it and require dissenters to fork away.
> I exhort you to consider making all this controversial stuff settings
> that can be changed by RPC command or command-line flag; set the default
> value sure, but requiring a fork to change it is, in my opinion,
> oppressive.
> 
> (Also consider some compromise, such as ">95% miner support before flag
> day or >33% on flag day")
> 
> Best wishes
> Yanmaani
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot NACK

[Felipe Micaroni Lalli via bitcoin-dev]

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@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  *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 ;
> Daniel Edgecumbe 
> *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  on
> behalf of Daniel Edgecumbe via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Tuesday, 2 March 2021 12:16 PM
> *To:* M.K. Safi via bitcoin-dev 
> *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
> em...@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  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 

[bitcoin-dev] Yesterday’s UASF (LOT=true) kick off meeting

[Michael Folkson via bitcoin-dev]

Yesterday we held a UASF (LOT=true) kick off meeting on the ##uasf IRC channel.

The conversation log is here: http://gnusha.org/uasf/2021-03-02.log

It was announced (at short notice admittedly) here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018515.html

It is clear frustration is building but it is also clear that this
isn’t a conducive environment for development and review. The high
level activation discussion has been done to death. Barring a miracle
the only thing Core will ship is BIP 8 (1 year, LOT=false). The
alternative appears Core ships nothing.

At this point in time it also appears the greatest risk to Taproot
dying a slow death is a small group of developers who think talking in
conservative tones and talking about endless philosophy makes Bitcoin
a conservative system. (It doesn’t, it just makes it a dying, decaying
one).

We have a trillion dollar industry (all signed up to this upgrade)
wasting time monitoring these arguments rather than preparing for an
upgrade and preparing for the small but manageable risks that any such
upgrade entails later in the year. Development projects on hold
because there is no end in sight for Taproot activation.

We need to give miners and users the ability to activate this year
(2021). If we fail to do that through whatever means (Core, UASF
release) etc I personally will assume Taproot will never activate. I
will also assume Bitcoin is not a project for the incredibly able
people who have designed and shipped a complex upgrade (Taproot) that
miraculously has overwhelming consensus amongst the entire community.
Failing to ship activation code (a very small code change in
comparison) is a joke.

We need to get this done this year. A UASF (LOT=true) project needs to
be ready to assemble just like it was in 2017 to make sure a small
group of individuals don’t block progress. But Core also needs to be
given the opportunity to ship a BIP 8(1 year, LOT=false) activation
that can be used to activate this year that is as well reviewed and
well tested as any other Core consensus code change.

Once things have calmed down I think we should revisit what progress
has been made and take it from there.

-- 
Michael Folkson
Email: michaelfolk...@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making the case for flag day activation of taproot

[yanmaani--- via bitcoin-dev]

On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:

Enter flag day activation. With a flag day there can be no
brinksmanship. A social media blitz cant do anything except have its 
own

followers fork away. Crucially, miner signalling cant be used to change
the activation date for nodes that didn't choose to and just passively
follow signalling. Changing the activation date requires all those 
users

to actually run different node software.


Is that supposed to be a good thing? "We should do X because it'll work" 
doesn't prove X is actually good. These things can be evil, but they can 
also be legitimate opposition to a change. Taking away the power of a 
"social media blitz" is not guaranteed to be a good thing!



What if one day the Core developer team uses the flag
day method to do something bad? The bitcoin user
community who wants to resist this can create their own
counter-soft-fork full node. This forces a chain
split. The real bitcoin which most people follow will be
the chain without censorship.


[edited for brevity]

That will only work for really egregious changes. In practice, most 
people will trust Core on all other (non-egregious) decisions, because 
of the inertia inherent in disobeying them.


What you suggest may be an efficient way to ram taproot through, but is 
it inherently good? Nothing is free. This seems like de-facto forcing 
people to go along with you, because you're convinced you're right. In 
this case, you are, but you'd be convinced you'd be right even if you 
weren't so.


You're right in suggesting that it will work, but the reason why it will 
work is because nobody wants to disobey Core. It seems immoral to 
exploit this fact.


At least you shouldn't hard-code it and require dissenters to fork away. 
I exhort you to consider making all this controversial stuff settings 
that can be changed by RPC command or command-line flag; set the default 
value sure, but requiring a fork to change it is, in my opinion, 
oppressive.


(Also consider some compromise, such as ">95% miner support before flag 
day or >33% on flag day")


Best wishes
Yanmaani
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[Emil Pfeffer via bitcoin-dev]

On Tue, Mar 02, 2021 at 06:21:59PM +, Chris Belcher via bitcoin-dev wrote:
> It is wrong to say that using miner signalling alone for activation
> (LOT=false) is a bug.

That depends on the definition you choose to work with but since the community
had to produce a fix that implies something was broken so we can call it a
bug in a broad sense.

> 
> As we vividly saw in the events of the 2017 UASF, the purpose of miner
> signalling isn't to activate or enforce the new rules but to stop a
> chain split. A majority of miners can stop a chain split by essentially
> doing a 51% attack. Such attacks have been known about since day one,
> and even the whitepaper writes about them.
> 
> So they are not a bug but an inherent part of the way bitcoin works. If
> fixing this issue was a simple as setting a consensus rule parameter
> then bitcoin would have been invented decades earlier than it was.
> 
> And certainly miner signalling cannot be compared to an inflation bug.

Certainly and neither did the OP.

> The inflation rules are enforced by the economy using full nodes, but
> chain splits or lack of them is enforced by miners. They are two
> different parts of the bitcoin system. Back in 2010 there was an
> inflation bug CVE-2010-5139 (the "Value overflow incident") which proves
> my point. Even though miners created a block which printed 184 billion
> bitcoins, the economy quickly adopted a patch which fixed the bug and
> miners switched over to the correct chain which soon overtook the bugged
> chain (there was a reorg of 53 blocks).
> 
> 
> 
> 
> Also another point: in a hypothetical chain split it's true that the
> LOT=false chain would be vulnerable to reorgs, but it's also true that
> the LOT=true would suffer from slow blocks.

That is true but this would happen for both chains and cannot be used
to put either one of them in a better light.

> 
> So for example, imagine trading bitcoin for cash in person, but instead
> of waiting on average 10 minutes for a confirmation you have to wait 2
> hours. Imagine depositing coins to an exchange which requires 3
> confirmation, then instead of waiting ~30 minutes you have to actually
> wait 6 hours. This is a significant degradation in usability. 

> The situation is a mirror image of how the LOT=false chain is vulnerable to
> reorgs.

No, the LOT=false chain is also vulnerable to this and reorgs.

> Both chains suffer if a chain split happens which is why they
> are pretty important to avoid.

That's correct however that is worst case scenario and it can happen regardless
of which lot bitcoin ships with.

> That's why its inaccurate to portray LOT=true chain as safe 
> with no downsides at all.

It was not, it was portrayed as safer which holds true.

> 
> 
> On 28/02/2021 19:33, Luke Dashjr via bitcoin-dev wrote:
> > (Note: I am writing this as a general case against LOT=False, but using 
> > Taproot simply as an example softfork. Note that this is addressing 
> > activation under the assumption that the softfork is ethical and has 
> > sufficient community support. If those criteria have not been met, no 
> > activation should be deployed at all, of any type.)
> > 
> > As we saw in 2017 with BIP 9, coordinating activation by miner signal 
> > alone, 
> > despite its potential benefits, also leaves open the door to a miner veto. 
> > This was never the intended behaviour, and a bug, which took a rushed 
> > deployment of BIP148 to address. LOT=False would reintroduce that same bug.
> > It wouldn't be much different than adding back the inflation bug 
> > (CVE-2018-17144) and trusting miners not to exploit it.
> > 
> > Some have tried to spin LOT=True as some kind of punishment for miners or 
> > reactive "counter-attack". Rather, it is simply a fallback to avoid 
> > regression on this and other bugs. "Flag day" activation is not 
> > fundamentally 
> > flawed or dangerous, just slow since everyone needs time to upgrade.
> > BIP 8(LOT=True) combines the certainty of such a flag day, with the speed 
> > improvement of a MASF, so that softforks can be activated both reasonably 
> > quick and safely.
> > 
> > In the normal path, and that which BIP8(True) best incentivises, miners 
> > will 
> > simply upgrade and signal, and activation can occur as soon as the economic 
> > majority is expected to have had time to upgrade. In the worst-case path, 
> > the 
> > behaviour of LOT=True is the least-harmful result: unambiguous activation 
> > and 
> > enforcement by the economy, with miners either deciding to make an 
> > anti-Taproot(eg) altcoin, or continue mining Bitcoin. Even if ALL the 
> > miners 
> > revolt against the softfork, the LOT=True nodes are simply faced with a 
> > choice to hardfork (replacing the miners with a PoW change) or concede - 
> > they 
> > do not risk vulnerability or loss.
> > 
> > With LOT=False in the picture, however, things can get messy: some users 
> > will 
> > enforce Taproot(eg) (those running LOT=True), while others will not 

Re: [bitcoin-dev] Taproot NACK

[Eric Voskuil via bitcoin-dev]

> 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  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 ; Daniel 
Edgecumbe 
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  on behalf of 
Daniel Edgecumbe via bitcoin-dev mailto:bitcoin-dev@lists.linuxfoundation.org> >
Sent: Tuesday, 2 March 2021 12:16 PM
To: M.K. Safi via bitcoin-dev mailto:bitcoin-dev@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
em...@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 
> >  >  > 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 

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Anthony Towns via bitcoin-dev]

On Sun, Feb 28, 2021 at 11:45:22AM -0500, Matt Corallo via bitcoin-dev wrote:
> Given this, it seems one way to keep the network in consensus would be to
> simply activate taproot through a traditional, no-frills, flag-day (or
> -height) activation with a flag day of roughly August, 2022. Going back to
> my criteria laid out in [1],

The timeout height proposed in:

 https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102

is block 745920, so bip8/lockinontimeout=true with that param would ensure
activation by block 747936. That's 74,940 blocks away at present, which
would be ~6th August 2022 if the block interval averaged at 10 minutes.

So I think I'm going to treat this as reusing the same parameter, just
dropping the consensus-critical signalling and hence the possibilty
of early activation.

I believe this sort of unsignalled flag day could be implemented
fairly easily by merging PR #19438, adding "int TaprootHeight;" to
Conensus::Params, moving "DEPLOYMENT_TAPROOT" from DeploymentPos
to BuriedDeployment, adjusting DeploymentHeight(), and setting
TaprootHeight=747936 for MAINNET. Might need to add a config param like
"-segwitheight" for regtest in order to keep the tests working.

I think it would be worthwhile to also update getblocktemplate so that
miners signal uptake for something like three or four retarget periods
prior to activation, without that signalling having any consensus-level
effect. That should allow miners and businesses to adjust their
expectations for how much hashpower might not be enforcing taproot rules
when generating blocks -- potentially allowing miners to switch pools
to one running an up to date node, pools to reduce the amount of time
they spend mining on top of unvalidated headers, businesses to increase
confirmation requirements or prepare for the possibility of an increase
in invalid-block entries in their logs, etc.

> 2) The high node-level-adoption bar is one of the most critical goals, and
> the one most currently in jeopardy in a BIP 8 approach.

A couple of days ago I would have disagreed with this; but with Luke
now strongly pushing against implementing lot=false, I can at least see
your point...

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Making the case for flag day activation of taproot

[Chris Belcher via bitcoin-dev]

The bitcoin world is close to total gridlock on the question of how to
activate taproot. There's no agreement on activation[1][2], and if an
agreement isn't reached then nothing happens. That would be really
terrible because we'd miss out on the benefits of taproot and
potentially other future soft forks.

A major problem with BIP8 is that it would result to a situation where
different parts of the bitcoin ecosystem run different consensus rules.
Some people will run LOT=true and others LOT=false. Worst of all, it
becomes vulnerable to a twitter/reddit/social media blitz which could
attempt to move the date of miner activation around.

Twitter and reddit drama provide a perfect cover for social attacks on
bitcoin.

Forced signalling leads to brinksmanship. Where two or more sides
(backed up by social media drama) enter into a game of chicken with
deployed nodes. If one of them doesn't concede then we get a damaging
chain split. And the $1 trillion in value that the bitcoin network
protects is put at risk. From the point of view of a miner or big
exchange stuck in the middle, if they look at the ecosystem of twitter
and reddit (especially if you think about all the problems with bots and
sockpuppets) they have no idea which consensus rules they should
actually follow and exactly what date they take effect. Miners,
exchanges, merchants and the rest of the ecosystem exist to serve their
customers and users, and trouble happens when they don't know what their
customers really want. Social media attacks are not just a theoretical
concern; back during the block size drama, the bitcoin reddits were
targetted by bots, sockpuppets and brigading[3].

Enter flag day activation. With a flag day there can be no
brinksmanship. A social media blitz cant do anything except have its own
followers fork away. Crucially, miner signalling cant be used to change
the activation date for nodes that didn't choose to and just passively
follow signalling. Changing the activation date requires all those users
to actually run different node software.

Flag day activation works simply: we choose a block height and after
that block height the new taproot rules become enforced.


Supporters of the permissionless, "users rule" approach of LOT=true
should be happy because it completely takes miners out of activation.

Supporters of the safe, conservative approach of LOT=false can be made
happy with a few ways of derisking:

* Getting mining pools, businesses and users to look at the code and ask
if they (a) think its either neutral or good for their business or use
case and (b) they believe others view it similarly and that the
consensus changes proposed have a good social consensus around them.

* Setting the flag day far in the future (18 months or 2 years in the
original proposal[3]).


== What if flag day activation is used maliciously? ==

What if one day the Core developer team is co-opted and uses the flag
day method to do something bad? For example, a soft fork where sending
to certain blacklisted addresses is not allowed. The bitcoin user
community who wants to resist this can create their own
counter-soft-fork full node, where the first block after the flag day
MUST pay to one of those addresses on the blacklist. This forces a chain
split between the censorship rules and the no-censorship rules, and its
pretty obvious that the real bitcoin which most people follow will be
the chain without censorship.

For example, if a group of users didn't agree with taproot then they
could create their own counter-flag-day-activation which requires that a
transaction is included that does an invalid-spend from a taproot output
in the first block after the flag day height.

This is always possible with any user activated soft fork. In BIP8
LOT=true it could be done by rejecting block headers with certain
version bits signalled.


== But it will take so long! ==

We seem to be at a deadlock now. This will take less time than any other
method, because other methods might never happen. BIP8 is dead and from
what I see there's no other credible plan.

We've already waited years for taproot. I remember listening to talks
about bitcoin from 2015 of people discussing Schnorr signatures. And
given how slow segwit and p2sh adoption were its pretty likely that
we'll waiting a while for taproot to be actually adopted.


== A social media blitz could still try to activate it early ==

The brinksmanship only works because miner signalling can make many
other nodes activate early, even if those other nodes didn't do
anything. There can't be a game of chicken that puts the bitcoin network
at risk.

If a group of people did adopt alternative node software which has a
shorter flag day, they actually have a risk of slow blocks. Because they
cant trick or force any other nodes to come along with them, they are
likely to only have a small economy and therefore would lose a lot of
hashrate. Imagine trading bitcoins for cash in person and instead of
waiting 10 

Re: [bitcoin-dev] Taproot NACK

[LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev]

Good Afternoon,

No-one has yet demonstrated that Conjoin or using Wasabi wallet is secure if it 
relies on third-parties. Are the transaction not forwarded partially signed as 
with an SPV wallet? So it is possible the SPV server cannot redirect funds if 
dishonest? SPV wallets are secure producing fully signed transactions. A 
ConJoin transaction signs for the UTXO and forwards it to be included signed 
for in another larger transaction with many inputs and outputs. Also, none of 
those you mention is inherently a Privacy Technology. Transparency is one of 
the key articles of value in Bitcoin because it prevents fraud.

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  on behalf of 
Chris Belcher via bitcoin-dev 
Sent: Tuesday, 2 March 2021 10:56 PM
To: bitcoin-dev@lists.linuxfoundation.org 

Subject: Re: [bitcoin-dev] Taproot NACK

The idea of a fully-transparent bitcoin is dead and has been for many
years. This is because of various privacy tech such as CoinJoin,
Lightning Network, PayJoin, change avoidance, avoiding address reuse,
etc, along with a few new ones like CoinSwap and WabiSabi hopefully
coming soon.

On 01/03/2021 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 
>>  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]-Operation of Jambler.io partner mixer
>> https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png=622=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 

Re: [bitcoin-dev] Taproot NACK

[LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev]

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 - 
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 
Sent: Tuesday, 2 March 2021 9:37 AM
To: LORD HIS EXCELLENCY JAMES HRMH ; Bitcoin Protocol 
Discussion 
Cc: Ariel Lorenzo-Luaces 
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 
 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]-Operation of Jambler.io partner mixer
https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png=622=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 

Re: [bitcoin-dev] Taproot NACK

[LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev]

"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  on behalf of 
Daniel Edgecumbe via bitcoin-dev 
Sent: Tuesday, 2 March 2021 12:16 PM
To: M.K. Safi via bitcoin-dev 
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
em...@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 
> >  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]-Operation of Jambler.io partner mixer
> > 

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

[Antoine Riard via bitcoin-dev]

> I believe this is what BIP 60 does, or did you have something else in
> mind?

Right, it achieves the first goal of dissociating `fRelay` from BIP37 but
it doesn't document Core specific behavior of disconnecting peers for raw
TX messages reception
from outbound block-relay-only peers, as implemented by PR 15759. I think
BIP 60 is as much unclear as BIP37 "Whether the remote peer should announce
relayed transactions or not, see BIP 0037, since version >= 70001". A first
interpretation could be that all tx-relay messages are disabled. A second
interpretation could be that only _tx-announcement_ messages (e.g INV(TX))
are disabled.

It could be argued that #15759 introduced incompatible changes between a
Bitcon Core 0.19.0 node and a BIP37 compliant peer on the p2p network.
Post-15759, the message space allowed to a BIP37 peer has been
reduced...Note that BIP60 isn't listed as implemented in
bitcoin/doc/bips.md.

I believe that BIP338 has the merit of making those subjects clear and easy
to follow by any Bitcoin software. Instead of spawning discussion around
old, lightclient-related BIPs or Core undocumented disabling transaction
relay mechanism being de facto part of the p2p protocol.

> Sorry - I meant that Bitcoin Core should allow a certain number of
> inbound peers that do not relay txs. This would be in addition to the
> full-relay inbound peers.

Yes, I agree on the purpose. But I don't think we need to "allow" further
disabled-tx peers by our inbound connection selection or eviction logics.
Turning a few bits in a protocol message sounds a too-cheap burden on
potential attackers contrary to most of our current eviction heuristics,
forcing some work ("announce transaction fast, "be located in some subnet",
"announce block fast"). Though better to discuss this later, not the main
point of your proposal.

Antoine

Le mar. 2 mars 2021 à 07:22, John Newbery via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Antoine,
>
> Nothing in my proposal below precludes introducing a more comprehensive
> feature negotiation mechanism at some later date. The only changes I'm
> proposing are to Bitcoin Core's policy for how it treats its peer
> connections.
>
> > If we don't want to introduce a new message and
> > corresponding code changes, it would be wise at least to extract
> VERSION's
> > `fRelay` and how Core handles it in its own BIP.
>
> I believe this is what BIP 60 does, or did you have something else in
> mind?
>
> > Explicit addr-relay negotiation will offer more
> > flexibility
>
> I agree!
>
> > (and more hygienic code paths rather than triggering data
> > structures initialization in few different locations).
>
> Not sure what you mean by hygienic here. This seems like a code style
> preference.
>
> > Given inbound connections might be attacker-controlled and tx-relay
> opt-out
> > signaling is also attacker-controlled, wouldn't this give a bias toward
> an
> > attacker in occupying our inbound slots ? Compared to honest inbound
> peers,
> > which in average are going to be full-relay.
>
> Sorry - I meant that Bitcoin Core should allow a certain number of
> inbound peers that do not relay txs. This would be in addition to the
> full-relay inbound peers.
>
> John
>
> On Mon, Mar 1, 2021 at 11:11 PM Antoine Riard 
> wrote:
>
>> Hi John,
>>
>> > I think a good counter-argument against simply using `fRelay` for this
>> > purpose is that we shouldn't reuse a protocol feature designed for one
>> > function to achieve a totally different aim. However, we know that nodes
>> > on the network have been using `fRelay` to disable transaction relay
>> > since Bitcoin Core version 0.12 (when `-blocksonly` was added), and that
>> > usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
>> > later (when block-relay-only connections were introduced), so using
>> > `fRelay` to disable transaction relay is now de facto part of the p2p
>> > protocol.
>>
>>
>> I don't think this is good practice ecosystem-wise. To understand
>> tx-relay opt-out from peers correctly, a _non_ Bitcoin Core client has to
>> implement the `fRelay` subset of BIP37, but ignore the wider part around
>> FILTER* messages. Or implement those messages, only to disconnect peers
>> sending them, thus following BIP111 requirements.
>>
>> Thus, future developers of bitcoin software have the choice between
>> implementing a standard in a non-compliant way or implementing p2p messages
>> for a light client protocol in a way of deprecation ? Even further, an
>> interpretation of BIP 37 ("Being able to opt-out of _inv_ messages until
>> the filter is set prevents a client being flooded with traffic in the brief
>> window of time") would make it okay to send TX messages to your inbound
>> block-relay-only peers. And that your client shouldn't be disconnected for
>> such behavior.
>>
>> On the long-term, IMHO, better to have a well-defined standard with a
>> clean negotiation mechanism rather than relying on code specifics