Ariel Lorenzo-Luaces [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-09 13:01:45

- reply

📅 Original date posted:2020-12-14
📝 Original message:
I don't think it's so clear that any party refusing to go go first can be assumed to have lost data.
If the rule is that the party receiving the connection is the one that must send the oblivious signatures then a party that has both lost data and is receiving a connection can just ignore the connection request.
There is plausible denyability because knowingly not answering a request can't be distinguished from just having connection issues or distinguished from a machine is just turned off.
This reasoning should work well into the future because as long as machine failures are common, the node with data loss can hide in that anonymity set. And if human kind resolves all machine failures then by definition there shouldn't be lightning channel data loss.
Cheers
Ariel Lorenzo-Luaces
On Dec 13, 2020, 10:12 AM, at 10:12 AM, "David A. Harding" <dave at dtrt.org> wrote:
>On Fri, Dec 11, 2020 at 01:02:04PM +1100, Lloyd Fournier wrote:
>> If c = 1 (i.e. the node is fine and it wants to continue the channel)
>then
>> it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it
>passes
>> it sends the commitment blinding y back to prove that it doesn't have
>the
>> signature (i.e. prove c = 1). If verification fails then the node is
>> malicious and it fails the channel.
>
>This is really cool! However, I don't understand why it's needed.
>Your
>goal seems to be for the sender to provide the commitment transaction
>and signatures before he learns whether the receiver actually needs
>them. That's just as easily accomplished by sending the data upfront
>in
>plain text. For example, it seems to me that both of the following
>protocols provide identical utility:
>
>1. On every reconnection, request the plain text unsigned commitment
> transaction, send a pedersen commitment, and receive the encrypted
> signature(s). If c=1, verify the encrypted signature(s) and (on
> success) send the blinding factor or (on failure) fail the channel
> and ban the peer. If c=0, decrypt the signature(s), apply them to
> the commitment transaction, and broadcast.
>
>2. On every reconnection, request the plain text unsigned commitment
> transaction with all of its signatures, also in plain text. If our
> database is intact, verify the commitment transaction and its
> signatures are valid and (on success) continue or (on failure) fail
> and ban. If we lost data, broadcast the commitment transaction.
>
>Unless I'm forgetting something, there's no reason a node shouldn't
>send
>its latest commitment transaction to its counterparty in plain text
>(over the regular BOLT8 P2P encrypted and authenticated link).
>
>I think the challenge in either protocol above is deciding which peer
>goes first, because whoever sends the commitment transaction reveals
>what they think the current state is. Any node that refuses to go
>first
>can then be suspected of having lost data. BOLT2
>option_static_remotekey has this same problem, which is reasonably
>mitigated IMO by LN's penalty mechanism forcing any would-be thief to
>risk their own funds; this doesn't work for basic eltoo, though.
>
>-Dave
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Lightning-dev mailing list
>Lightning-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201214/eb2a5521/attachment-0001.html>

2023-06-09 12:54:40

- reply

📅 Original date posted:2019-03-30
📝 Original message:
> I am forking this thread as my reply is not at all related to the JIT-Routing.
Sorry I think my last reply was also getting off subject as well.
Thank you for forking the thread
> Nonexistent channels (i.e. channels that do not have some backing UTXO in the Bitcoin blockchain) are not safe to propagate on the network since they are trivially spammable (i.e. can generate a large number of fake channels to waste network bandwidth).
I hadn't considered the effect this gossip would have on the network.
Definitely nodes should not trust one another to tell the truth about
nonexistent channels.
The source node could blindly allow intermediate nodes to create
sub-routes to the next hop.
But I wouldn't favor this blind routing idea because fee calculations
would be a complete guesses.
> A good pruning heuristic is "channel capacity", which can be checked onchain (the value of the UTXO backing the channel is the channel capacity).
> It is good to keep channels with large capacity in the routemap, because such large channels are more likely to successfully route a payment than smaller channels.
> So it is reasonable to delete channels with low capacity when the routemap memory is becoming close to full.
I'm generally concerned about these heuristics because any time nodes
can game a heuristic they will be expected to do so.
Gaming a heuristic can be good or bad depending on the side-effects.
One side effect of the "channel capacity" heuristic is more reliable
payments but another side effect is that low capacity (but possibly
reliable) channels are neglected.
> It seems to me that s/aggregate-channel/high-capacity-channel/g in your idea would still work.
> In effect, the high-capacity channel is very likely to successfully route in either direction.
> But if by chance it falls into a state where it is unable to route in one direction or other, the intermediate node has other, lower-capacity channels that it can use JIT-Routing with to improve the directionality of the high-capacity channel.
> Nothing in the JIT-Routing idea requires that the rebalancing loop is small, only that a loop exists.
>
> Nodes still need to track their direct channels (so they are implicitly always in the routemap).
> But payee nodes making BOLT1 invoices could also provide `r` routes in the invoice, with the given routes being from nodes with high-capacity channels, so that even if the intermediate channels are pruned due to low capacity, it is possible to get paid.
Without low capacity channels spontaneous payments would not work. Or
they would depend on asking for an invoice under the hood.
It feels to me that at some point, someone with complete knowledge of
the network needs to be employed.
Cheers
Ariel Lorenzo-Luaces
On Mar 28, 2019, 9:51 PM, at 9:51 PM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>Good morning Ariel,
>
>I am forking this thread as my reply is not at all related to the
>JIT-Routing.
>
>
>Sent with ProtonMail Secure Email.
>
>> Public nodes could advertise channels which don't actually exist
>directly but are instead hidden paths that the source node doesn't need
>to know or care about. The fees advertised for these aggregate-channels
>would be the aggregate fees expected from the sub-route.
>
>Nonexistent channels (i.e. channels that do not have some backing UTXO
>in the Bitcoin blockchain) are not safe to propagate on the network
>since they are trivially spammable (i.e. can generate a large number of
>fake channels to waste network bandwidth).
>
>> I think the biggest gain from this system is that the network can be
>more abstract. This abstraction allows all possible subsets of public
>nodes to be a clique since all subsets of nodes can be maximally
>connected with aggregate-channels as long as the entire network is well
>connected.
>> This new property of the network could allow a source node to select
>a random privacy-clique and rely on payments to be routed along
>aggregate-channels without the source node needing to compute or even
>know the exact sub-routes. Futhermore, the source node could
>exclusively download and listen to the privacy-clique and ignore the
>rest of the network structure thus reducing the burden of keeping up to
>date network information.
>
>Let me suggest something else.
>
>As the LN grows, the public routemap becomes larger and larger, until
>keeping them in a fast in-memory data structure becomes infeasible on
>cheap hardware.
>In all likelihood, at some point in the future, users will want to be
>able to limit the memory consumed by implementations for routemaps.
>
>So, some pruning heuristic is needed, to reduce the resource usage of
>large routemaps.
>
>A good pruning heuristic is "channel capacity", which can be checked
>onchain (the value of the UTXO backing the channel is the channel
>capacity).
>It is good to keep channels with large capacity in the routemap,
>because such large channels are more likely to successfully route a
>payment than smaller channels.
>So it is reasonable to delete channels with low capacity when the
>routemap memory is becoming close to full.
>
>It seems to me that s/aggregate-channel/high-capacity-channel/g in your
>idea would still work.
>In effect, the high-capacity channel is very likely to successfully
>route in either direction.
>But if by chance it falls into a state where it is unable to route in
>one direction or other, the intermediate node has other, lower-capacity
>channels that it can use JIT-Routing with to improve the directionality
>of the high-capacity channel.
>Nothing in the JIT-Routing idea requires that the rebalancing loop is
>small, only that a loop exists.
>
>Nodes still need to track their direct channels (so they are implicitly
>always in the routemap).
>But payee nodes making BOLT1 invoices could also provide `r` routes in
>the invoice, with the given routes being from nodes with high-capacity
>channels, so that even if the intermediate channels are pruned due to
>low capacity, it is possible to get paid.
>
>Regards,
>ZmnSCPxj

2023-06-09 12:54:25

- reply

📅 Original date posted:2019-03-25
📝 Original message:
Good morning list
I have been thinking about how JIT-Routing can allow the network to be more private and scalable than it currently is today. Rene has mentioned that JIT-Routing allows channel balance information to affect pathing decisions without the source node being aware. I would take this further and suggest that JIT-Routing can allow routing over sub-paths that are only visible to neighbour nodes and are entirely hidden from the source node or plublic view.
An intermediate route node could decide for any reason to re-route a payment through any subset of nodes to arrive at the next hop. This is similar to Rene's local AMP idea where friend-of-a-friend nodes are used. But instead this system could allow arbitraryly long paths to the next hop by finding a new sub-route and re-layering the onion packet with the new sub-route prepended.
The same pre-image would be used and this process would be completely invisible to the next hop (original next hop, not the new next hop in the sub-route, I would instead call those the sub-hops).
It's unfortunate that the intermediate nodes along the sub-route would be aware that a sub-route is being attempted because they could observe extra hop packets prepended to the minimum twenty and I don't see of a way to fix this. But maybe it doesn't need fixing since the original twenty encryption layers are arguably private enough.
The sub-route could also employ base AMP since the same pre-image is used. The next hop node would still never even know that a subroute was attempted if no "wait for more payments" flag is added to the per_hop field and we implement the "wait for timeout if HTLC is less than amt_to_forward" rule.
Public nodes could advertise channels which don't actually exist directly but are instead hidden paths that the source node doesn't need to know or care about. The fees advertised for these aggregate-channels would be the aggregate fees expected from the sub-route.
I think the biggest gain from this system is that the network can be more abstract. This abstraction allows all possible subsets of public nodes to be a clique since all subsets of nodes can be maximally connected with aggregate-channels as long as the entire network is well connected.
This new property of the network could allow a source node to select a random privacy-clique and rely on payments to be routed along aggregate-channels without the source node needing to compute or even know the exact sub-routes. Futhermore, the source node could exclusively download and listen to the privacy-clique and ignore the rest of the network structure thus reducing the burden of keeping up to date network information.
Cheers
Ariel Lorenzo-Luaces
On Mar 22, 2019, 4:44 AM, at 4:44 AM, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>Good morning list,
>
>I have been thinking of JIT-Routing in the context of unidirectional
>channels, as for example in Eclair Mobile.
>Now of course unidirectional-only nodes as in Eclair Mobile cannot
>forward and cannot be intermediate nodes.
>However, as I pointed out in previous email, the same JIT-Routing can
>be used also when the node is the ultimate source of the payment.
>
>The original formulation, which requires a separate, completed
>rebalance, before performing a payment, cannot be used in
>unidirectional mode.
>It requires that the channel to be boosted by the rebalance, must first
>receive the value, which is disallowed in unidirectional mode.
>
>However, the Luaces-Pickhardt JIT-Routing, which has a conditional
>rebalance, does not require that the channel receive.
>So it seems to me, that the Luaces-Pickhardt JIT-Routing can work with
>Eclair.
>
>Let us consider the following history:
>
>1. An Eclair Mobile client creates a 1mBTC channel.
>2. The client successfully pays an unrelated payment of 0.5 mBTC.
>3. The client has to make another payment of 0.6 mBTC, to be passed by
>this channel.
>The client has another channel which can pay out the needed 0.15mBTC
>(additional 0.05mBTC needed for the channel reserve).
>4. The second payment passes.
>
>In the below sequence of states, A is the Eclair Mobile client node,
>while B is the counterparty.
>
>1. A = 1.0, B = 0.0 ; starting state.
>2. A = 0.5, B = 0.0, A->HTLC->B = 0.5 ; client offers payment in #2
>above.
>3. A = 0.5, B = 0.5 ; payee accepts payment.
>4. A = 0.5, B = 0.35, B->HTLC->A = 0.15 ; the rebalance from another
>channel of A, initiated by #3 above.
>5. A = 0.05, B = 0.5, A->HTLC->B = 0.45 ; HTLC polarity reversed by A
>offering an HTLC of 0.6 BTC (the new mechanism proposed by Rene).
>6. A = 0.05, B = 0.95 ; payee accepts payment.
>
>As can be seen from above, A will never have an increase in its money.
>
>Thus, the new Luaces-Pickhardt formulation of JIT-Routing, which
>requires the new "reverse HTLC polarity" mechanism to reuse the same
>hash as the actual payment, should be safe for unidirectional Eclair
>Mobile nodes.
>
>Let us consider the following sequence of events:
>
>1. An Eclair Mobile client creates a 1mBTC channel.
>2. The client successfully pays an unrelated payment of 0.5 mBTC.
>3. The client has to make another payment of 0.6 mBTC, to be passed by
>this channel.
>The client has another channel which can pay out the needed 0.15mBTC
>(additional 0.05mBTC needed for the channel reserve).
>4. The second payment fails.
>
>Then the sequence of states is:
>
>1. A = 1.0, B = 0.0 ; starting state.
>2. A = 0.5, B = 0.0, A->HTLC->B = 0.5 ; client offers payment in #2
>above.
>3. A = 0.5, B = 0.5 ; payee accepts payment.
>4. A = 0.5, B = 0.35, B->HTLC->A = 0.15 ; the rebalance from another
>channel of A, initiated by #3 above.
>5. A = 0.05, B = 0.5, A->HTLC->B = 0.45 ; HTLC polarity reversed by A
>offering an HTLC of 0.6 BTC (the new mechanism proposed by Rene).
>6. A = 0.5, B = 0.5 ; payment fails.
>
>Now in the above, the only state that has A own less money than in a
>later state is state 5.
>However, even if we are at state 6, and B replays state 5, B cannot
>claim the A->HTLC->B (if it had the hash, it would have claimed the
>HTLC instead of failing it), so it will revert back to A when it times
>out.
>This is the same as existing cases of payment failure in Eclair Mobile,
>so presumably if it has a problem here, it would have a problem in
>existing Eclair Mobile unidirectional channels.
>
>Thus, it should be safe to use the Luaces-Pickhardt JIT-Routing in
>unidirectional-only nodes, even if the original Pickhardt JIT-Routing
>is unsafe for unidirectional-only nodes.
>
>Thus this is a plausible replacement for all forms of multipart
>payments.
>In effect, instead of a multipart payment being decided by the source
>to the destination, we have each hop, including the source, deciding to
>split or not split the payment according to how much fee it has to
>devote to rebalance attempts.
>
>Regards,
>ZmnSCPxj
>_______________________________________________
>Lightning-dev mailing list
>Lightning-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190325/51dca3aa/attachment.html>

2023-06-09 12:54:22

- reply

📅 Original date posted:2019-03-14
📝 Original message:
Hello Rene, ZmnSCPxj, and list
I really like the proposal and I'm sure it's the correct way forward for reducing payment failures and increasing privacy (through mitigating probing based network analysis)
However I am concerned that this proposal could introduce a vulnerability to a spoofed-payment attack.
An adversary could create a malicious payment that's guaranteed to fail, for free. Any intermediary nodes on the path of the payment before it fails could lose fees due to rebalancing if the rebalancing path's success is not dependent on the original payment's success.
Could anyone speak to this and confirm whether it would be possible for the rebalancing step to reuse the original payment hash? If this is possible then it should explicitly be included in this proposal.
If reusing the payment hash is not possible on the routing path then JIT routing would need some other mitigation for the spoofed-payment attack.
Cheers
Ariel Lorenzo-Luaces
On Mar 14, 2019, 7:45 AM, at 7:45 AM, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>Good morning Rene and list,
>
>Let us consider then the rule *when* a rebalancing would be beneficial
>to the node.
>
>The node is offered a fee amount (`offered_fee_amount`) for the
>forwarding.
>It knows that, under current channel states, it will definitely have to
>fail and earn 0 fees.
>
>If it engages in JIT-routing, it must pay some fee
>(`rebalancing_fee_amount`) for the rebalancing operation.
>But even if it successfully forwards its hop, it is still possible that
>the route will fail anyway and it will earn 0 fees.
>
>So let us consider the probability of success (`success_rate`), a value
>between 0 to 1.0.
>This is the estimated probability that we will succeed the route after
>we forward it.
>
>We should only engage in JIT-routing if:
>
> offered_fee_amount * success_rate - rebalancing_fee_amount > 0
>
>The LHS of the subtraction is the expected earning, while the RHS of
>the subtraction is the expected cost.
>The above is trivial accounting for determining net earnings.
>
>The fee amounts are trivially computable.
>Presumably the rebalancing code can compute the fee given a particular
>rebalance path, and thus can provide `rebalancing_fee_amount`.
>
>The `success_rate` can be computed statically from some node data.
>Better, is for the node to start with this precomputed static
>information, but augment this over time with its own experienced
>`success_rate` for all forwards.
>
>Regards,
>ZmnSCPxj
>_______________________________________________
>Lightning-dev mailing list
>Lightning-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190314/5243cc1d/attachment.html>

2023-06-09 12:50:05

- reply

📅 Original date posted:2018-04-15
📝 Original message:
Letting the attacker have immediate access to their funds is a null point because the attacker always has the preparation time to unbalance the channel to the honest node's favor. The attacker's 'funds' in this case is trivially reduced to 'reserve balance'. It's hard to argue that forcing the malicious node to wait for the delay before having access to their reserve balance is disincentive enough to not perform the attack.
Cheers
Ariel Lorenzo-Luaces
On Apr 15, 2018, 11:37 AM, at 11:37 AM, Jim Posen <jim.posen at gmail.com> wrote:
>I believe that anyone attempting a DOS by forcing on-chain settlement
>can
>do it just as easily with asymmetric delays than with symmetric delays.
>
>If my goal is to waste the time-value of your money in a channel, in a
>world with symmetric delays, I could just publish the commitment
>transaction and you would have to wait the full delay for access to
>your
>funds. True. But with delays asymmetric as they are now, I can just as
>easily refuse to participate in a mutual close, forcing you to close
>on-chain. This is just as bad. In fact, I'd argue that it is worse,
>because
>I lose less by doing this (in the sense that I as the attacker get
>immediate access to my funds). So in my assessment, it is a very active
>attack and symmetric delays are something of a mitigation. You are
>right
>that the balance of funds in the channel becomes a factor too, but note
>that there is the reserve balance, so I'm always losing access to some
>funds for some time.
>
>-jimpo
>
>On Sun, Apr 15, 2018 at 6:35 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com>
>wrote:
>
>> Good morning Daniel,
>>
>>
>> This makes a lot of sense to me as a way to correct the incentives
>for
>> closing channels. I figure that honest nodes that have truly gone
>offline
>> will not require (or be able to take advantage of) immediate access
>to
>> their balance, such that this change shouldn't cause too much
>inconvenience.
>>
>> I was trying to think if this could open up a DOS vector - dishonest
>nodes
>> performing unilateral closes even when mutual closes are possible
>just to
>> lock up the other side's coins - but it seems like not much of a
>concern. I
>> figure it's hard to pull off on a large scale.
>>
>>
>>
>> Now that you bring this up, I think, it is indeed a concern, and one
>we
>> should not take lightly.
>>
>> As a purely selfish rational being, it matters not to me whether my
>> commitment transaction will delay your output or not; all that
>matters is
>> that it delays mine, and that is enough for me to prefer a bilateral
>close
>> if possible. I think we do not need to change commitment
>transactions to
>> be symmetrical then --- it is enough that the one holding the
>commitment
>> transaction has its own outputs delayed.
>>
>> If I had a goal to disrupt rather than cooperate with the Lightning
>> Network, and commitment transactions would also delay the side not
>holding
>> the commitment transaction (i.e. "symmetrical delay" commitments), I
>would
>> find it easier to disrupt cheaply if I could wait for a channel to be
>> unbalanced in your favor (i.e. you own more money on it than I do),
>then
>> lock up both our funds by doing a unilateral transaction. Since it
>is
>> unbalanced in your favor, you end up losing more utility than I do.
>> Indeed, in the situation where you are funding a new channel to me, I
>have
>> 0 satoshi on the channel and can perform this attack costlessly.
>>
>> Now perhaps one may argue, in the case of asymmetric delays, that if
>I
>> were evil, I could still disrupt the network by misbehaving and
>forcing the
>> other side to push its commitment transaction. Indeed I could even
>just
>> accept a channel and then always fail to forward any payment you try
>to
>> make over it, performing a disruption costlessly too (as I have no
>money in
>> this). But this attack is somewhat more passive than the above
>attack
>> under a symmetrical delay commitment transaction scheme.
>>
>> Regards,
>> ZmnSCPxj
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Lightning-dev mailing list
>Lightning-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180415/2b1c8937/attachment-0001.html>

2023-06-07 18:30:39

- reply

📅 Original date posted:2021-03-07
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210307/f99a9224/attachment.html>

2023-06-07 18:29:47

- reply

📅 Original date posted:2021-03-02
📝 Original message: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 <luke at dashjr.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210302/faf383dd/attachment.html>

2023-06-07 18:29:47

- reply

📅 Original date posted:2021-03-02
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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: michaelfolkson at gmail.com
>Keybase: michaelfolkson
>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210302/1722c7a2/attachment-0001.html>

2023-06-07 18:29:40

- reply

📅 Original date posted:2021-03-02
📝 Original message: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 <erik at q32.com> 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
><bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> 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
><bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210302/711495d9/attachment.html>

2023-06-07 18:29:08

- reply

📅 Original date posted:2021-02-28
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Good Evening,
>
>Thank-you for your advice @JeremyRubin<https://twitter.com/JeremyRubin>
>on the basis you advise, "Taproot does not enable monero-like privacy
>features", I am prepred to withdraw my NACK notably that the existing
>feeatures of Bitcoin MUST be maintained, and whereby the UTXO of a
>transaction is identifiable, the PayTo Address, and the amount all
>without any obfuscation.
>
>Lightning does not really provide obfuscation, it provides a result of
>a subset of transactions although the operation of the channel is
>observable to the parties.
>
>The reports I were reading concerning the supposed operation of Taproot
>published in a public media channel may have been speculation or
>misinformation nonetheless it is prudent to conditionally reply as you
>see that I have. It is important not to allow things to slip through
>the cracks. As you may believe may astute reviewers could make a full
>disclosure to this list it is not to be expected.
>
>KING JAMES HRMH
>Great British Empire
>
>Regards,
>The Australian
>LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>of Hougun Manor & Glencoe & British Empire
>MR. Damian A. James Williamson
>Wills
>
>et al.
>
>
>Willtech
>www.willtech.com.au<mail://local/Sent/www.willtech.com.au>
>www.go-overt.com<mail://local/Sent/www.go-overt.com>
>and other projects
>
>earn.com/willtech
>linkedin.com/in/damianwilliamson
>
>
>m. 0487135719
>f. +61261470192
>
>
>This email does not constitute a general advice. Please disregard this
>email if misdelivered.
>________________________________
>From: Jeremy <jlrubin at mit.edu>
>Sent: Sunday, 28 February 2021 3:14 AM
>To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin
>Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>Subject: Re: [bitcoin-dev] Taproot NACK
>
>I have good news for you: Taproot does not enable monero-like privacy
>features any moreso than already exist in Bitcoin today. At its core,
>taproot is a way to make transactions with embedded smart contracts
>less expensive, done so in a manner that may marginally improve privacy
>dependent on user behavior (but not in the monero-like way you
>mention). For example, it makes it possible for lightning channels to
>look structurally similar to single key wallets, but it does nothing
>inherently to obfuscate the transaction graph as in monero.
>
>Such "monero-like" transaction graph obfuscation may already exist in
>Bitcoin via other techniques (coinjoin, payjoin, coinswap, lightning,
>etc) with or without Taproot, so the point is further moot.
>
>Do you have a source on your reporting?
>
>You may wish to rescind your nack.
>
>
>--
>@JeremyRubin<https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin>
>
>
>On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via
>bitcoin-dev
><bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>>
>wrote:
>Good Afternoon,
>
>It has been reported that Taproot will enable some Monero like features
>including the ability to hide transactions.
>
>If that is the case I offer a full NACK and let me explain.
>
>A part of the benefit of using Bitcoin is its honesty. The full
>transaction is published on the blockchain. If that were to change so
>that transactions may be obfuscated from scrutiny then any government
>would have unlimited impetus to ban Bitcoin, and speculation has that
>is the reason India has been reported to have banned cryptocurrencies
>already.
>
>I am in support of the expanded use case of Bitcoin without harming the
>established robust fairness and equal equity offered. The core
>functionality of Bitcoin, its values, must remain unaltered.
>
>KING JAMES HRMH
>Great British Empire
>
>Regards,
>The Australian
>LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>of Hougun Manor & Glencoe & British Empire
>MR. Damian A. James Williamson
>Wills
>
>et al.
>
>
>Willtech
>www.willtech.com.au<http://www.willtech.com.au>
>www.go-overt.com<http://www.go-overt.com>
>and other projects
>
>earn.com/willtech<http://earn.com/willtech>
>linkedin.com/in/damianwilliamson<http://linkedin.com/in/damianwilliamson>
>
>
>m. 0487135719
>f. +61261470192
>
>
>This email does not constitute a general advice. Please disregard this
>email if misdelivered.
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210228/49cd6deb/attachment.html>

2023-06-07 18:28:56

- reply

📅 Original date posted:2021-02-20
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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 adam at 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 at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210220/05495dc3/attachment.html>

2023-06-07 18:28:44

- reply

📅 Original date posted:2021-02-18
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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: 693504-745920
>
>MASF threshold: 1815/2016 blocks (90%)
>
>Keep in mind only ~100 people showed for the meetings, hardly
>representative of the entire community.
>
>So, these details remain JUST a proposal for now.
>
>It seems inevitable that there won't be consensus on LOT.
>
>Everyone will have to choose for himself. :/
>
>Personally I agree with most of this. I agree that there wasn’t
>overwhelming consensus for either LOT=true or LOT=false. However, from
>my perspective there was clearly more strong opposition (what would
>usually be deemed a NACK in Bitcoin Core review terminology) from
>Bitcoin Core contributors, Lightning developers and other community
>members against LOT=true than there was for LOT=false. Andrew Chow
>tried to summarize views from the meeting in this analysis:
>https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
>
>I am also aware of other current and previous Bitcoin Core
>contributors and Lightning developers who didn’t attend the meeting in
>person who are opposed to LOT=true. I don’t want to put them in the
>spotlight for no reason but if you go through the conversation logs of
>not only the meeting but the weeks of discussion prior to this meeting
>you will see their views evaluated on the ##taproot-activation
>channel. In addition, on taprootactivation.com some mining pools
>expressed a preference for lot=false though I don’t know how strong
>that preference was.
>
>I am only one voice but it is my current assessment that if we are to
>attempt to finalize Taproot activation parameters and propose them to
>the community at this time our only option is to propose LOT=false.
>Any further delay appears to me counterproductive in our collective
>aim to get the Taproot soft fork activated as early as possible.
>
>Obviously others are free to disagree with that assessment and
>continue discussions but personally I will be attempting to avoid
>those discussions unless prominent new information comes to light or
>various specific individuals change their minds.
>
>Next week we are planning a code review of the Bitcoin Core PR #19573
>which was initially delayed because of this LOT discussion. As I’ve
>said previously that will be loosely following the format of the
>Bitcoin Core PR review club and will be lower level and more
>technical. That is planned for Tuesday February 23rd at 19:00 UTC on
>the IRC channel ##taproot-activation.
>
>Thanks to the meeting participants (and those who joined the
>discussion on the channel prior and post the meeting) for engaging
>productively and in good faith.
>
>--
>Michael Folkson
>Email: michaelfolkson at gmail.com
>Keybase: michaelfolkson
>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210217/689747ce/attachment-0001.html>

2023-06-07 18:24:48

- reply

📅 Original date posted:2020-05-24
📝 Original message:On May 24, 2020, 1:26 PM, at 1:26 PM, Karl via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> 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 <ZmnSCPxj at protonmail.com> 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 the difficulty.
>> >
>> > You could develop the frequency of introduction of new hashes such
>that
>> once present-day ASICs are effectively obsolete anyway due to
>competition,
>> new ones do not have time to develop.
>> >
>> > I'm interested in hearing thoughts and concerns.
>> >
>> > Karl Semich
>>
>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200524/eac5b865/attachment-0001.html>

2023-06-07 18:21:09

- reply

📅 Original date posted:2019-10-11
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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
><bitcoin-dev at lists.linuxfoundation.org> 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 standardization is never wrong and
>this
>> would be the first step in the correct direction for better on-chain
>> privacy.
>>
>> However currently we still need a good term for the 'address'
>replacement.
>>
>> The current suggestions are:
>> * Invoice ID
>> * Payment Token
>> * Bitcoin invoice (address)
>> * Bitcoin invoice (path)
>>
>> Because of the LN term invoice I really like the term 'Bitcoin
>Invoice'
>> by Chris Belcher.
>>
>> So how do find a consensus about these terms?
>>
>> Greetings
>> Emil Engler
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191010/25216e06/attachment.html>

2023-06-07 18:17:33

- reply

📅 Original date posted:2019-04-04
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190403/0125e3d2/attachment.html>

2023-06-07 18:07:49

- reply

📅 Original date posted:2017-11-20
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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 <http://about.me/praveen.baratam>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171120/292a25d9/attachment.html>