Re: [bitcoin-dev] Yet another Taproot activation logic

[Ariel Lorenzo-Luaces via bitcoin-dev]

Hi Carlo

This your proposal is similar to the Simple Majority Activation proposal (SMA). 
The difference is that your proposal has the final activation threshold set to 
80% and SMA has it set to 51% 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html

The problem with what you're proposing is what do users do if signaling is 
somewhere between 51% to 79%? Users that want to promote a UASF know that their 
miner majority can activate Taproot and activate without the 21% to 49% of 
miners needing to signal (or purposefully stalling). A UASF knows they have 
majority mining power so there is little risk to them and a big reward 
(activating Taproot) so they are incentivized to do a UASF.

A UASF with a miner majority can scare everyone else about them being at risk 
of big reorgs to gain traction and followers.

With the same proposal but the final threshold set to 51% instead of 80% there 
can't be risk of a UASF because if 51% is not reached they know they don't have 
enough miner support to keep the chain together.

If support is less than 50% a UASF movement needs to hard fork anyway to change 
the PoW (for protection) and change addresses to prevent double spends.

I really like the SMA proposal with 51% because it removes the incentive to do 
a UASF.

Cheers
Ariel Lorenzo-Luaces


On Mar 7, 2021, 6:37 AM, at 6:37 AM, Carlo Spiller via bitcoin-dev 
 wrote:
>Hi everybody
>
>I'm new to this list, but not new to Bitcoin, having skin in the game
>since 2014. I was there for the scaling war and the drama around
>SegWit,
>as a simple user. This time, I run my own full node and follow
>development. I hope to bring something new to the table.
>
>Having witnessed the miner's unwillingness to activate SegWit truly
>makes me concerened for a simple LOT=false. After reading the
>discussion
>now for some time and thinking about it myself, I have come to the
>following proposal.
>
>Initially deploy with LOT=false and an activation threshold of 95% of
>miner signaling.
>
>*IFF* after 6 months Taproot is not activated by MASF, BUT at least 80%
>
>of hashpower signaled for the upgrade, LOT gets a lock-in date another
>6
>months later and the threshold for MASF is lowered to 90%.
>
>If after the initial 6 months of signaling with LOT=false, 80% is not
>reached, the proposal expires.
>
>This way, a small percent of hashpower does not get to stall
>activation,
>rather, 80% of hashpower can activate LOT=true, and later, 90% can
>activate Taproot. If a flaw is found in Taproot in the first six months
>
>(unlikely anyway), miners simply don't signal and the proposal expires.
>
>If miners don't signal at all, only six months are lost, before a new
>activation logic can be deployed.
>
>Don't mind this if something similar was already proposed somewhere
>else.
>
>Best
>
>Carlo
>
>___
>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] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel

[Ariel Lorenzo-Luaces via bitcoin-dev]

You can try to redefine all you want but it doesn't make what you're saying 
true.

A soft fork is a constriction of rules

A 51% attack is a soft fork with majority mining power.

I didn't say that LOT=true does it I said that it must achieve 51% miner 
support to pose reorg risks to force apathetic users into paying attention. 
Please read my message again.

Your definition of invalid has no power here. We are all painfully aware of 
your semantic mental gymnastics.

Cheers
Ariel Lorenzo-Luaces


On Mar 2, 2021, 10:58 AM, at 10:58 AM, Luke Dashjr  wrote:
>On Tuesday 02 March 2021 18:22:35 Ariel Lorenzo-Luaces via bitcoin-dev
>wrote:
>> I'm realizing that a clear advantage of LOT=false is that it can
>happen
>> without the need for a social movement. All that is really needed is
>the
>> convincing of 95% miners. Apathetic users will never notice any kind
>of
>> service disruption no matter the success or failure of the
>activation. This
>> is obviously why it naturally became the default activation method.
>
>No. Miners enforcing rules without the social support is a 51% attack,
>not a
>softfork.
>
>> While LOT=true, on the other hand, must be able to 51% the blockchain
>to
>> win the apathetic users. But then the reorgs will not be pretty. Or
>if it
>> ever clearly gets over the 51% hurdle then all apathetic users now
>need to
>> scramble to use the rogue client to be safe from reorgs. Either way
>it's
>> disruptive.
>
>No, LOT=True doesn't do this. It only happens if miners choose to
>create an
>invalid chain, which they could do at any time with or without a
>softfork
>involved.
>
>Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Ariel Lorenzo-Luaces via bitcoin-dev]

I agree.

Thank you Erik for proposing it. It's a pretty good idea.

P.S. I wouldn't want a chain split of a low percentage of users though. The 
minority will be at the mercy of massive PoW swings and the chain will lose 
friends so it's not good for anyone. I recommend changing the final percentage 
to %50 because that's the hurdle where non-upgraded users *must* activate to 
avoid the risk of being reorged. The number of running users will quickly jump 
to 90%+ if it ever gets near 50%.

Cheers
Ariel Lorenzo-Luaces



On Mar 1, 2021, 5:54 AM, at 5:54 AM, Erik Aronesty  wrote:
>> Today users should start cooperating again to continue using the
>> optimal strategy.
>
>the "gradual" method of reducing the % of miners required for lock-in
>as time goes on seems to encode this optimal strategy.
>
>On Thu, Feb 25, 2021 at 6:43 AM Ariel Luaces via bitcoin-dev
> wrote:
>>
>> On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
>>  wrote:
>> >
>> > If social consensus is what drives technical consensus and not the
>other way around it seems as if there cannot exist a valid (rational?)
>reason to oppose Taproot itself, and then by extension with the
>arguments laid out above, LOT=true seems to be the logical conclusion
>of all of this, even if Core ships LOT=false at the outset.
>> >
>> > Where am I wrong here?
>> >
>> > Keagan
>> >
>> > On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev
> wrote:
>> >>
>> >> Personally, I think with either plan the ultimate risk of forking
>is low given probability to activate before timeout, so we should just
>pick something and move on, accepting that we aren't setting a
>precedent by which all future forks should abide. Given my
>understanding of the tradeoffs, I believe that the safest choice is
>LOT=true, but I wouldn't move to hold back a plan of LOT=false (but
>would probably take mitigative steps on community advocacy if it looks
>like there is non majority but non negligible LOT=true uptake).
>> >>
>> >> Cheers,
>> >>
>> >> Jeremy
>> >>
>> >>
>> >> ___
>> >> 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
>>
>> To favor LOT=true because it seems like the inevitable result is like
>> playing the prisoner's dilemma and never cooperating instead of using
>> the most optimal strategy which is tit-for-tat (cooperating at first
>> and then cheating once for every time your counterparty cheats).
>>
>> During segwit users started by cooperating (BIP9, or "LOT=false"),
>> then a minority of
>> miners didn't cooperate (small veto but remember the majority of
>> miners cooperated), then users stopped cooperating in response
>(UASF),
>> then miners
>> reverted to cooperating (MASF while intolerant miners forked off).
>> Today users should start cooperating again to continue using the
>> optimal strategy.
>>
>> Cheers
>> Ariel Lorenzo-Luaces
>> ___
>> 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] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel

[Ariel Lorenzo-Luaces via bitcoin-dev]

It's becoming increasingly clear that core might not be able to release 
activation code.

Anyone advocating for a UASF must do tremendous amounts of work to convince 
users, miners, and service providers to run a UASF client. Anyone advocating 
against a UASF or indifferent will take the path of least resistance and ignore 
the rogue client. If the movement fails to materialize we will be looking at a 
minor chain split one year later and a year of wasted time. At that moment 
LOT=false can be finally released and calmer heads can activate on the majority 
chain.

The choice has never been LOT=false versus LOT=true. It has always been about 
the order. Some think LOT=true should be attempted first and some think 
LOT=false should be attempted first. And the grand majority are indifferent to 
the choice (won't upgrade until core says it's safe).

I'm realizing that a clear advantage of LOT=false is that it can happen without 
the need for a social movement. All that is really needed is the convincing of 
95% miners. Apathetic users will never notice any kind of service disruption no 
matter the success or failure of the activation. This is obviously why it 
naturally became the default activation method.

While LOT=true, on the other hand, must be able to 51% the blockchain to win 
the apathetic users. But then the reorgs will not be pretty. Or if it ever 
clearly gets over the 51% hurdle then all apathetic users now need to scramble 
to use the rogue client to be safe from reorgs. Either way it's disruptive.

Please, I'm begging you, let's just try LOT=false first. Let's halt the fight 
for this new UASF movement until it's needed. Social movements are hard. 
Especially hard when the people you're trying to convince don't have a material 
threat to their beliefs or freedoms. It would be a shame to meet back here a 
year later after the risk of verbal conflicts, misdirection, lies, 
vilinization, reorgs, double spends, PoW changes, and threats galore.

P.S. I don't think I'm being so apocalyptic this time. I actually see all of 
those things as *necessary* to the UASF movement. Otherwise people won't be 
convinced to take a side.

Cheers
Ariel Lorenzo-Luaces


On Mar 1, 2021, 1:06 PM, at 1:06 PM, Michael Folkson via bitcoin-dev 
 wrote:
>It is approximately 8 months since Steve Lee formally kicked off the
>Taproot activation discussion by setting up the ##taproot-activation
>IRC channel. Obviously there was discussion that considerably predates
>that but that was the first recognition that there needed to be a
>focus towards a solution rather than endless circular debates.
>
>Eight months on it appears there are some who think there is a
>philosopher’s stone still out there that will garner 100 percent
>consensus and contain zero chain split risk in the worst case
>scenario. A philosopher’s stone that us mere mortals have failed to
>find in these 8 months.
>
>While I would be delighted if this philosopher’s stone is found (and
>all are free to continue looking) I think it is prudent at this point
>to step away from the circular arguments and build on the progress we
>have made in these last 8 months. We have effectively achieved
>overwhelming consensus on the activation mechanism (BIP 8) and all of
>the parameters apart from one (lockinontimeout or LOT). Again I’d like
>to thank the people who have put hours of work into getting to this
>point. It is thankless work and it is probably the last thing any of
>us want to be doing.
>
>At this point it is unclear whether Bitcoin Core will be able to
>release any activation code whatsoever due to disagreement logjams.
>Personally I hope they do but again it is prudent to prepare for the
>scenario where Core is unable to. Hence I and others have assessed
>that our energies are better spent working on a community release
>implementing LOT=true in a similar spirit to 2017’s UASF effort. I say
>similar as this time there really is no need for any antagonism.
>Approximately 90 percent of mining pools (taprootactivation.com) have
>declared support and there is overwhelming community consensus to
>activate Taproot. In the absence of a Core release with activation
>code I hope and expect all users (including miners) to consider
>supporting this UASF release and consider running it to activate
>Taproot.
>
>TL;DR Tomorrow (Tuesday) we are holding a kick off meeting for this
>UASF (LOT=true) effort on the ##uasf IRC channel at 19:00 UTC. Please
>consider attending and supporting this effort to get Taproot
>activated. It would be great to get users from the 2017 effort
>involved in addition to recent Taproot proponents from all parts of
>our community. The future of Bitcoin’s scalability and privacy depends
>on, as it always has, on you the user.
>
>--
>Michael Folkson
>Email: michaelfolk...@gmail.com
>Keybase: michaelfolkson
>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>___
>bitcoin-dev mailing list

Re: [bitcoin-dev] Taproot NACK

[Ariel Lorenzo-Luaces via bitcoin-dev]

Hello LORD HIS EXCELLENCY JAMES HRMH

I find a striking dichotomy between your concern of increased privacy in 
bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com

At first your concerns seemed genuine but after seeing your promotion of a 
bitcoin mixer I'm thinking your concerns may be more profit motivated? I can't 
tell since you failed to disclose your relationship with the mixer.

Could you please clarify your association with the bitcoin mixer and moving 
forward could you please always do proper disclosure any time you're publically 
talking about bitcoin transaction privacy. It's only fair to do so as to not 
mislead people in an attempt to manipulate at worst and just a courteous 
practice at best.

Cheers
Ariel Lorenzo-Luaces


On Feb 28, 2021, 4:36 AM, at 4:36 AM, LORD HIS EXCELLENCY JAMES HRMH via 
bitcoin-dev  wrote:
>Good Evening,
>
>Thank-you for your advice @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 
>Sent: Sunday, 28 February 2021 3:14 AM
>To: LORD HIS EXCELLENCY JAMES HRMH ; Bitcoin
>Protocol Discussion 
>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
>
>
>On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via
>bitcoin-dev
>mailto:bitcoin-dev@lists.linuxfoundation.org>>
>wrote:
>Good Afternoon,
>
>It has been reported that Taproot will enable some Monero like features
>including the ability to hide transactions.
>
>If that is the case I offer a full NACK and let me explain.
>
>A part of the benefit of using Bitcoin is its honesty. The full
>transaction is published on the blockchain. If that were to change so
>that transactions may be obfuscated from scrutiny then any government
>would have unlimited impetus to ban Bitcoin, and speculation has that
>is the reason India has been reported to have banned cryptocurrencies
>already.
>
>I am in support of the expanded use case of Bitcoin without harming the
>established robust fairness and equal equity offered. The core
>functionality of Bitcoin, its values, must remain unaltered.
>
>KING JAMES HRMH
>Great British Empire
>
>Regards,
>The Australian
>LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>of Hougun Manor & Glencoe & British Empire
>MR. Damian A. James Williamson
>Wills
>
>et al.
>
>
>Willtech
>www.willtech.com.au
>www.go-overt.com
>and other projects
>
>earn.com/willtech
>linkedin.com/in/damianwilliamson
>
>
>m. 0487135719
>f. +61261470192
>
>
>This email does not constitute a general advice. Please disregard this
>email if misdelivered.
>___
>bitcoin-dev mailing list

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Ariel Lorenzo-Luaces via bitcoin-dev]

What would be the tradeoffs of a BIP8(false, ∞) option? That would remove some 
of the concerns of having to coordinate a UASF with an approaching deadline.

Cheers
Ariel Lorenzo-Luaces
⁣​

On Feb 19, 2021, 6:55 PM, at 6:55 PM, ZmnSCPxj via bitcoin-dev 
 wrote:
>Good morning list,
>
>> It was pointed out to me that this discussion is largely moot as the
>software complexity for Bitcoin Core to ship an
>> option like this is likely not practical/what people would wish to
>see.
>>
>> Bitcoin Core does not have infrastructure to handle switching
>consensus rules with the same datadir - after running with
>> uasf=true for some time, valid blocks will be marked as invalid, and
>additional development would need to occur to
>> enable switching back to uasf=false. This is complex, critical code
>to get right, and the review and testing cycles
>> needed seem to be not worth it.
>
>Without implying anything else, this can be worked around by a user
>maintaining two `datadir`s and running two clients.
>This would have an "external" client running an LOT=X (where X is
>whatever the user prefers) and an "internal" client that is at most
>0.21.0, which will not impose any LOT rules.
>The internal client then uses `connect=` directive to connect locally
>to the external client and connects only to that client, using it as a
>firewall.
>The external client can be run pruned in order to reduce diskspace
>resource usage (the internal client can remain unpruned if that is
>needed by the user, e.g. for LN implementation sthat need to look up
>arbitrary short-channel-ids).
>Bandwidth usage should be same since the internal client only connects
>to the external client and the OS should optimize that case.
>CPU usage is doubled, though.
>
>(the general idea came from gmax, just to be clear, though the below
>use is from me)
>
>Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin
>Core ultimately ships with) on the external client based on the user
>preferences.
>
>If Taproot is not MASF-activated and LOT=!U is what dominates later
>(where U is whatever the user decided on), the user can decide to just
>destroy the external node and connect the internal node directly to the
>network (optionally upgrading the internal node to LOT=!U) as a way to
>"change their mind in view of the economy".
>The internal node will then follow the dominant chain.
>
>
>Regards,
>ZmnSCPxj
>
>>
>> Instead, the only practical way to ship such an option would be to
>treat it as a separate chain (the same way regtest,
>> testnet, and signet are treated), including its own separate datadir
>and the like.
>>
>> Matt
>>
>> On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:
>>
>> > (Also in response to ZMN...)
>> > Bitcoin Core has a long-standing policy of not shipping options
>which shoot yourself in the foot. I’d be very disappointed if that
>changed now. People are of course more than welcome to run such
>software themselves, but I anticipate the loud minority on Twitter and
>here aren’t processing enough transactions or throwing enough financial
>weight behind their decision for them to do anything but just switch
>back if they find themselves on a chain with no blocks.
>> > There’s nothing we can (or should) do to prevent people from
>threatening to (and possibly) forking themselves off of bitcoin, but
>that doesn’t mean we should encourage it either. The work Bitcoin Core
>maintainers and developers do is to recommend courses of action which
>they believe have reasonable levels of consensus and are technically
>sound. Luckily, there’s strong historical precedent for people deciding
>to run other software around forks, so misinterpretation is not very
>common (just like there’s strong historical precedent for miners not
>unilaterally deciding forks in the case of Segwit).
>> > Matt
>> >
>> > > On Feb 19, 2021, at 07:08, Adam Back a...@cypherspace.org wrote:
>> > >
>> > > > would dev consensus around releasing LOT=false be considered as
>"developers forcing their views on users"?
>> > >
>> > > given there are clearly people of both views, or for now don't
>care
>> > > but might later, it would minimally be friendly and useful if
>> > > bitcoin-core has a LOT=true option - and that IMO goes some way
>to
>> > > avoid the assumptive control via defaults.
>> >
>> > > Otherwise it could be read as saying "developers on average
>> > > disapprove, but if you, the market disagree, go figure it out for
>> > > yourself" which is not a good message for being defensive and
>avoiding
>> > > mis-interpretation of code repositories or shipped defaults as
>> > > "control".
>> >
>> > 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] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Ariel Lorenzo-Luaces via bitcoin-dev]

Something what strikes me about the conversation is the emotion surrounding the 
letters UASF.

It appears as if people discuss UASF as if it's a massive tidal wave of support 
that is inevitable, like we saw during segwit activation. But the actual 
definition is "any activation that is not a MASF".

A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, 
all business' nodes, or even all the non mining nodes. On another dimension it 
can have zero mining support, 51% support, 49% support, or any support right up 
against a miner activation threshold.

Hell a UASF doesn't even need code or even a single node running as long as it 
exists as a possibility in people's minds.

The only thing a UASF doesn't have is miner support above an agreed activation 
threshold (some number above %51).

I say this because it strikes me when people say that they are for LOT=true 
with the logic that since a UASF is guaranteed to happen then it's better to 
just make it default from the beginning. Words like coordination and safety are 
sometimes sprinkled into the argument.

The argument comes from a naive assumption that users MUST upgrade to the 
choice that is submitted into code. But in fact this isn't true and some voices 
in this discussion need to be more humble about what users must or must not run.

Does no one realize that it is a very possible outcome that if LOT=true is 
released there may be only a handful of people that begin running it while 
everyone else delays their upgrade (with the very good reason of not getting 
involved in politics) and a year later those handful of people just become 
stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or attracting a 
minority of miners, activating, and forking off into a minority fork. Then a 
lot=false could be started that ends up activating the feature now that the 
stubborn option has ran its course.
The result: a wasted year of waiting and a minority of people who didn't want 
to be lenient with miners by default. The chains could be called BitcoinLenient 
and BitcoinStubborn.
How is that strictly safer or more coordinated?

I may be in the minority, or maybe a silent majority, or maybe a majority that 
just hasn't considered this as a choice but honestly if there is contention 
about whether we're going to be stubborn or lenient with miners for Taproot and 
in the future then I prefer to just not activate anything at all. I'm fine for 
calling bitcoin ossified, accepting that segwit is Bitcoin's last network 
upgrade. Taproot is amazing but no new feature is worth a network split down 
the middle.

Maybe in 10 or 20 years, when other blockchains implement features like Taproot 
and many more, we will become envious enough to put aside our differences on 
how to behave towards miners and finally activate Taproot.

An activation mechanism is a consensus change like any other change, can be 
contentious like any other change, and we must resolve it like any other 
change. Otherwise we risk arriving at the darkest timeline.

Cheers
Ariel Lorenzo-Luaces


On Feb 17, 2021, 7:05 AM, at 7:05 AM, Michael Folkson via bitcoin-dev 
 wrote:
>Yesterday (February 16th) we held a second meeting on Taproot
>activation on IRC which again was open to all. Despite what appeared
>to be majority support for LOT=false over LOT=true in the first
>meeting I (and others) thought the arguments had not been explored in
>depth and that we should have a follow up meeting almost entirely
>focused on whether LOT (lockinontimeout) should be set to true or
>false.
>
>The meeting was announced here:
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
>
>In that mailing list post I outlined the arguments for LOT=true (T1 to
>T6) and arguments for LOT=false (F1 to F6) in their strongest form I
>could. David Harding responded with an additional argument for
>LOT=false (F7) here:
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
>
>These meetings are very challenging given they are open to all, you
>don’t know who will attend and you don’t know most people’s views in
>advance. I tried to give time for both the LOT=true arguments and the
>LOT=false arguments to be discussed as I knew there was support for
>both. We only tried evaluating which had more support and which had
>more strong opposition towards the end of the meeting.
>
>The conversation log is here:
>http://gnusha.org/taproot-activation/2021-02-16.log
>
>(If you are so inclined you can watch a video of the meeting here.
>Thanks to the YouTube account “Bitcoin” for setting up the livestream:
>https://www.youtube.com/watch?v=vpl5q1ovMLM)
>
>A summary of the meeting was provided by Luke Dashjr on Mastodon here:
>https://bitcoinhackers.org/@lukedashjr/105742918779234566
>
>Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
>did manage to come to consensus on everything but LockinOnTimeout.
>
>Activation height range: 

Re: [bitcoin-dev] hashcash-newhash

[Ariel Lorenzo-Luaces via bitcoin-dev]

On May 24, 2020, 1:26 PM, at 1:26 PM, Karl via bitcoin-dev 
 wrote:
>Hi ZmnSCPxj,
>
>Thanks for your reply.  I'm on mobile so please excuse me for
>top-posting.
>
>I'd like to sort these various points out.  Maybe we won't finish the
>whole
>discussion, but maybe at least we can update wiki articles like
>https://en.bitcoin.it/wiki/Hashcash#Cryptanalytic_Risks with more
>points or
>a link to conversations like this.
>
>Everything is possible but some things take a lot of work.
>
>You mention ASICs becoming commoditized.  I'd remind you that
>eventually
>there will be a public mathematical breaking of the algorithm, at which
>point all ASICs will become obsolete regardless.  Would you agree it
>would
>be better to prepare for this by planning algorithm change?
>
>You mention many coordinated hardforks.  Would you agree that if we
>came up
>with a way of programmatically cycling the algorithm, that only one
>hardfork work be needed?  For example one could ask nodes to consent to
>new
>algorithm code written in a simple scripting language, and reject old
>ones
>slowly enough to provide for new research.
>
>You mention the cost of power as the major factor influencing
>decentralized
>mining.  Would you agree that access to hardware that can do the mining
>is
>an equally large factor?  Even without ASICs you would need the
>physical
>cycles.  Including this factor helps us discuss the same set of
>expected
>situations.
>
>You describe improving electricity availability in expensive areas as a
>way
>to improve decentralization.  Honestly this sounds out of place to me
>and
>I'm sorry if I've upset you by rehashing this old topic.  I believe
>this
>list is for discussing the design of software, not international energy
>infrastructure: what is the relation?  There is a lot of power to
>influence
>behavior here but I thought the tools present are software design.
>
>On Sat, May 23, 2020, 9:12 PM ZmnSCPxj  wrote:
>
>> Good morning Karl,
>>
>> > Hi,
>> >
>> > I'd like to revisit the discussion of the digest algorithm used in
>> hashcash.
>> >
>> > I believe migrating to new hashing algorithms as a policy would
>> significantly increase decentralization and hence security.
>>
>> Why do you believe so?
>>
>> My understanding is that there are effectively two strategies for
>ensuring
>> decentralization based on hash algorithm:
>>
>> * Keep changing the hash algorithm to prevent development of ASICs
>and
>> ensure commodity generic computation devices (GPUs) are the only
>practical
>> target.
>> * Do not change the algorithm, to ensure that knowledge of how best
>to
>> implement an ASIC for the algorithm becomes spread out (through
>corporate
>> espionage, ASIC reverse-engineering, patent expiry, and sheer
>engineering
>> effort) and ASICs for the algorithm are as commoditized as GPUs.
>>
>> The former strategy has the following practical disadvantages:
>>
>> * Developing new hash algorithms is not cheap.
>>   The changes to the hashcash algorithm may need to occur faster than
>the
>> speed at which we can practically develop new,
>cryptographically-secure
>> hash algorithms.
>> * It requires coordinated hardforks over the entire network at an
>> alarmingly high rate.
>> * It arguably puts too much power to the developers of the code.
>>
>> On the other hand, the latter strategy requires us only to survive an
>> intermediate period where ASICs are developed, but not yet
>commoditized;
>> and during this intermediate period, the centralization pressure of
>ASICs
>> might not be more powerful than other centralization pressures
>>
>> --
>>
>> Which brings us to another point.
>>
>> Non-ASIC-resistance is, by my understanding, a non-issue.
>>
>> Regardless of whether the most efficient available computing
>substrate for
>> the hashcash algorithm is CPU, GPU, or ASIC, ultimately miner
>earnings are
>> determined by cost of power supply.
>>
>> Even if you imagine that changing the hashcash algorithm would make
>CPUs
>> practical again, you will still not run it on the CPU of a mobile,
>because
>> a mobile runs on battery, and charging a battery takes more power
>than what
>> you can extract from the battery afterwards, because thermodynamics.
>>
>> Similarly, geographic locations with significant costs of electrical
>power
>> will still not be practical places to start a mine, regardless if the
>mine
>> is composed of commodity server racks, commodity video cards, or
>commodity
>> ASICs.
>>
>> If you want to solve the issue of miner centralization, the real
>solution
>> is improving the efficiency of energy transfer to increase the areas
>where
>> cheap energy is available, not stopgap
>change-the-algorithm-every-6-months.
>>
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> >
>> > I believe the impact on existing miners could be made pleasant by
>> gradually moving the block reward from the previous hash to the next
>(such
>> that both are accepted with different rewards).  An appropriate rate
>could
>> possibly be calculated from 

Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'

[Ariel Lorenzo-Luaces via bitcoin-dev]

I would propose a term different than all the others mentioned so far.

I propose Funding Codes.

The word funding can be used as a verb or a noun and this works for the nature 
of Bitcoin transactions. Funding can be seen as what someone needs to do with 
the code as well as referring to it as the code that has funding once bitcoins 
have been transfered to it "give me a funding code".

The word code is fitting since codes are what addresses ultimately describe, 
the signature script, a piece of code. When speaking about the lightning 
transaction graph it's easy to talk about transactions making bitcoins flow 
from code to code, each code different for a different purpose "funding is sent 
from this code to that code" and "funding is kept in this code for 144 blocks".

- Payment tokens feel like they themselves hold the value and can be transfered 
but anyone can generate as many payment tokens as they desire. This name 
conflicts with other cryptocurrencies that focus their blockchain on payments 
and refer to their currency as tokens.

- Invoices are problematic because they imply that they hold bitcoins and they 
specify an amount. However addresses don't specify any amounts while they 
themselves can be included inside a real invoice. I think it is wrong to imply 
that the "thing" we are sending money to is temporary, because it isn't. 
Lightning channels can stay open forever until closed but money doesn't stay in 
an invoice for any amount of time.

- I actually prefer Addresses over both Payment Tokens and Invoices. It's 
actually very natural to send something to an address and an address can hold 
something for a long time. However addresses fall short due to people only 
having one. This makes them think that they have to memorize a bitcoin address. 
There are also all the other reasons people have mentioned.

The word code fits well in the divide between technical and non-technical 
people. To the layman a code is just a string of characters and that is what we 
can visually see and check and compare when one of these funding codes are 
transfered between two parties "does your finding code end with xyz?". To 
programmers code is something that can be executed which is exactly what 
addresses are. Especially ones with complicated logic and lots of conditions 
"this funding code can only be unlocked by Alice or Bob plus Charlie or Dave 
after 1000 blocks".

Funding codes work even better when thinking about self executing smart 
contracts "they are funded and running code with their funds". Contracts don't 
make sense at all when it's an autonomous thing that didn't strike any contract 
with anyone. Contracts should only be referred to the transactions people send 
to funding codes or "smart" codes.

Addresses also fail when transferring between two of your own wallets because 
it doesn't make sense for someone to have so many addresses but it does make 
sense for someone to have many codes.

Lightning already has "funding addresses" and "funding transactions". With 
schnorr and taproot coming it will be possible to create more complex 
situations and they all need funding codes so that funds can be sent to it and 
be locked up in the code (sigscript).

One criticism might be that funding codes sound like they are funding something 
which doesn't appear to be true. But indeed they are! Funding codes fund a 
situation, a setup. The common setup is that you can unlock them at any time. 
Other setups demand multi-party coordination. The funding code is what funds 
all these setups.

Funding codes are also two words and three syllables which is great because 
using only one word is not descriptive enough and using four or more syllables 
is way too long. Having the second word "code" makes for easy abbreviation when 
the conversation is already about Bitcoin "which code did you send them to?"

People will naturally use funding code and bitcoin code interchangeably. This 
is a good thing because bitcoin is a type of fund, so there is no 
contradiction. The more common term should still be funding code because there 
is more than one type of "code" in Bitcoin

Most importantly funding codes sound good when spoken. This goes for both 
singular and plural.

"First a receiver must generate a funding code to have a sender fund it with 
their  from their own funding code which had been previously funded"

Cheers
Ariel Lorenzo-Luaces



On Oct 10, 2019, 7:20 PM, at 7:20 PM, Karl-Johan Alm via bitcoin-dev 
 wrote:
>I've proposed bitcoin invoice for awhile now. See
>https://twitter.com/kallewoof/status/1165841566105079808
>
>I like bitcoin invoice address into bitcoin address as proposed by
>Chris.
>
>
>On Fri, Oct 11, 2019 at 12:45 AM Emil Engler via bitcoin-dev
> wrote:
>>
>> * Sorry if this mail was sent multiple times, my E-Mail client went
>crazy *
>>
>> Thanks for all your feedback.
>> I came to the decision to write a BIP for this, even if it might not
>be
>> implemented by many wallets, a 

Re: [bitcoin-dev] Smart Contracts Unchained

[Ariel Lorenzo-Luaces via bitcoin-dev]

Hello ZmnSCPxj

I like the proposal because it generalizes escrow type mechanisms and I think 
it's a useful train of thought for distributed exchanges.

However, consider the situation where a group of participants are playing 
poker. One participant loses all their funds and decides to present to the 
escrow the contract+an old contract state+a signed message following the 
contract rules (eg. an independently signed cashing out message). How would the 
escrow know that the contract state is old and the operation is disallowed, 
without using a consensus mechanism like a blockchain?

Cheers
Ariel Lorenzo-Luaces

On Apr 3, 2019, 7:14 PM, at 7:14 PM, ZmnSCPxj via bitcoin-dev 
 wrote:
>https://zmnscpxj.github.io/bitcoin/unchained.html
>
>Smart contracts have traditionally been implemented as part of the
>consensus rules of some blokchain.  Often this means creating a new
>blockchain, or at least a sidechain to an existing blockchain.  This
>writeup proposes an alternative method without launching a separate
>blockchain or sidechain, while achieving security similar to federated
>sidechains and additional benefits to privacy and
>smart-contract-patching.
>___
>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] Why SegWit Anyway?

[Ariel Lorenzo-Luaces via bitcoin-dev]

Hello Praveen

You're absolutely right. We could refer to transactions by the hash that gets 
signed.

However the way that bitcoin transactions reference each other has already been 
established to be hash of transaction+signature. Changing this would require a 
hard fork.

Segwit is the realization that this could be done as a soft fork if we simply 
extract the signature outside of what the old client considers a transaction. 
And into a new transaction format where we do exactly what you're describing.

In my opinion the way it originally worked with the sig inside the transaction 
was simply an oversight by satoshi. No different than a bug.

Cheers
Ariel Lorenzo-Luaces


On Nov 20, 2017, 9:29 AM, at 9:29 AM, Praveen Baratam via bitcoin-dev 
 wrote:
>Bitcoin Noob here. Please forgive my ignorance.
>
>From what I understand, in SegWit, the transaction needs to be
>serialized
>into a data structure that is different from the current one where
>signatures are separated from the rest of the transaction data.
>
>Why change the format at all? Why cant we just compute the Transaction
>ID
>the same way the hash for signing the transaction is computed?
>
>--
>Dr. Praveen Baratam
>
>about.me 
>
>
>
>
>___
>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