[bitcoin-dev] Note on Sequence Lock Upgrades Defect

[Jeremy via bitcoin-dev]

Hi Bitcoin Devs,

I recently noticed a flaw in the Sequence lock implementation with respect
to upgradability. It might be the case that this is protected against by
some transaction level policy (didn't see any in policy.cpp, but if not,
I've put up a blogpost explaining the defect and patching it
https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/

I've proposed patching it here https://github.com/bitcoin/bitcoin/pull/22871,
it is proper to widely survey the community before patching to ensure no
one is depending on the current semantics in any live application lest this
tightening of standardness rules engender a confiscatory effect.

Best,

Jeremy

--
@JeremyRubin 

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

Re: [bitcoin-dev] Drivechain: BIP 300 and 301

[Prayank via bitcoin-dev]

> of course stacks can do this even without drivechain, so not sure whatwe're 
> hiding from there

Stacks is not a Bitcoin sidechain IMO. It has its own native token which isn't 
pegged to BTC. Premined.  It uses Bitcoin as a storage and broadcast medium for 
recording all blocks. Marketing with lot of misinformation. None of these 
things really help Bitcoin.

-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Drivechain: BIP 300 and 301

[Prayank via bitcoin-dev]

Good morning ZmnSCPxj,

Thanks for sharing all the details. One thing that I am not sure about:

> * We already ***know*** that blockchains cannot scale
> * Your plan for scaling is to make ***more*** blockchains?

Scaling Bitcoin can be different from scaling Bitcoin sidechains. You can 
experiment with lot of things on sidechains to scale which isn't true for 
Bitcoin. Most important thing is requirements for running a node differ. Its 
easy to run a node for LN, Liquid and Rootstock right now. Will it remain the 
same? I am not sure.

LND: https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md

Liquid: 
https://help.blockstream.com/hc/en-us/articles/92026026-How-do-I-set-up-a-Liquid-node-

Rootstock: https://developers.rsk.co/rsk/node/install/

> More to the point: what are sidechains **for**?

Smart contracts are possible on Bitcoin but with limited functionality so lot 
of applications are not possible using Bitcoin (Layer1). Some of these don't 
even make sense on Layer 1 and create other issues like MEV however deploying 
them on sidechains should not affect base layer.

> Increasing the Drivechain security parameter leads to slower 
>sidechain->mainchin withdrawals, effectively a bottleneck on how much can be 
>transferred sidechain->mainchain.

I think 'withdrawals' is the part which can be improved in Drivechain. Not sure 
about any solution at this point or trade-offs involved but making few changes 
can help Drivechain and Bitcoin.
I agree with everything else you explained and emails like these will be 
helpful for everyone trying to understand what's going on with Layer 2 on 
Bitcoin.

-- 
Prayank

A3B1 E430 2298 178F



Sep 3, 2021, 02:32 by zmnsc...@protonmail.com:

> Good morning Prayank,
>
> Just to be clear, neither Liquid nor RSK, as of my current knowledge, are 
> Drivechain systems.
>
> Instead, they are both federated sidechains.
> The money owned by a federated sidechain is, as far s the Bitcoin blockchain 
> is concerned, really owned by the federation that.runs the sidechain.
>
> Basically, a mainchain->sidechain transfer is done by paying to a federation 
> k-of-n address and a coordination signal of some kind (details depending on 
> federated sidechain) to create the equivalent coins on the sidechain.
> A sidechain->mainchain transfer is done by requesting some coins on the 
> sidechain to be destroyed, and then the federation will send some of its 
> mainchain k-of-n coins into whatever address you indicate you want to use on 
> the mainchain.
>
> In theory, a sufficient quorum of the federation can decide to ignore the 
> sidechain data entirely and spend the mainchain money arbitrarily, and the 
> mainchain layer will allow this (being completely ignorant of he sidechain).
>
> In such federated sidechains, the federation is often a fixed predetermined 
> signing set, and changes to that federation are expected to be rare.
>
> Federated sidechains are ultimately custodial; as noted above, the federation 
> could in theory abscond with the funds completely, and the mainchain would 
> not care if the sidechain federation executes its final exit strategy and you 
> lose your funds.
> One can consider federated sidechains to be a custodian with multiple 
> personality disorder, that happens to use a blockchain to keep its individual 
> sub-personalities coordinated with each other, but ultimately control of the 
> money is contingent on the custodian following the dictates of the supposed 
> owners of the coin.
> From a certain point of view, it is actually immaterial that there is a 
> separate blockchain called the "sidechain" --- it is simply that a blockchain 
> is used to coordinate the custodians of the coin, but in principle any other 
> coordination mechanism can be used between them, including a plain database.
>
>
> With Drivechains, custody of the sidechain funds is held by mainchain miners.
> Again, this is still a custodial setup.
> A potential issue here is that the mainchain miners cannot be identified (the 
> entire point is anonymity of miners is possible), which may be of concern.
>
> In particular, note that solely on mainchain, all that miners determine is 
> the *ordering* and *timing* of transactions.
> Let us suppose that there is a major 51% attack attempt on the Bitcoin 
> blockchain.
> We expect that such an attack will be temporary --- individuals currently not 
> mining may find that their HODLings are under threat of the 51% attack, and 
> may find it more economic to run miners at a loss, in order to protect their 
> stacks rather than lose it.
> Thus, we expect that a 51% attack will be temporary, as other miners will 
> arise inevitably to take back control of transaction processing.
> https://github.com/libbitcoin/libbitcoin-system/wiki/Threat-Level-Paradox
>
> In particular, on the mainchain, 51% miners cannot reverse deep history.
> If you have coins you have not moved since 2017, for example, the 51% attack 
> is expected to 

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[ts via bitcoin-dev]

Hi Marek,

Marek Palatinus wrote on 8/31/21 3:47 AM:
I fully agree with sipa and his reasoning that this proposal is not solving any particular 
problem, but making it actually a bit worse.
Ok, I understand. I'm just trying to find ways to reduce the risk of sending to the wrong 
address and to make the transaction process a bit more user friendly, specially for 
inexperienced users. I am sure that it can be implemented in a way without making it "worse". 
For example, if there is the risk that the user looks ONLY at the code and not at the address, 
then the code should have enough entropy to account for it. If looking at 6 characters is 
considered to be enough, then the code should also be 6 characters long. As I mentioned in my 
following message, the code could be made from specific characters of the address instead of a 
checksum (e.g. first 4 and last 2 characters). By showing these characters to the user 
separately and in a bigger font, he will be encouraged to verify all of these characters.


Also, do you know what I hate more than copy bitcoin addresses? Copy pasting zillion 
random fields for SEPA/wire transfers. And I believe that a single copy pasta of a bitcoin 
address is a much better user experience after all.


I totally agree with this :)

Cheers,
TS



Best,
slush

On Tue, Aug 31, 2021 at 9:08 AM ts via bitcoin-dev > wrote:


Pieter, thanks for your comments. Here my thoughts:

Pieter Wuille wrote on 8/29/21 9:24 AM:
> On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev
mailto:bitcoin-dev@lists.linuxfoundation.org>>
wrote:
>
>> Following up on my original proposal, I would like to get some more 
feedback of the
community
>>
>> to see if this could be realized at some point. Also, any 
recommendations as to who
to contact
>>
>> to get things rolling?
>
> I honestly don't understand the point of what you're suggesting.

It is about creating a simple technical assistance that makes it more user 
friendly and
less
error prone to verify the entered address. For all types of users, 
including those who are
less tech savvy.


> * If you're concerned about random typos, this is something already 
automatically
protected against through the checksum (both base58check or bech32/bech32m).

I agree, but as mentioned in the original proposal, it is not about random 
typos (although
this would help for other coins without integrated checksum of course), but 
rather about
copy errors (both technical or user caused).


> * If you're concerned about accidentally entering the wrong - but 
honestly created -
address, comparing any few characters of the address is just as good as any 
other. It
doesn't even require the presence of a checksum. Looking at the last N 
characters, or
the middle N, or anything except the first few, will do, and is just as 
good as an
"external" checksum added at the end. For randomly-generated addresses (as 
honest ones
are), each of those has exactly as much entropy.

Correct. However, I believe that ADDITIONALLY to looking at N characters, a 
quick check
of a 3
or 4 digit code in bigger font next to the address would make for a better 
user experience.
This gives the user the reassurance that there is definitely no error. I 
agree that most
users
with technical background including most of us here will routinely check 
the first/last N
characters. I usually check the first 3 + last 3 characters. But I don't 
think this is very
user friendly. More importantly, I once had the case that two addresses 
were very
similar at
precisely those 6 characters, and only a more close and concentrated look 
made me see the
difference. Moreover, some inexperienced users that are not aware of the 
consequences of
entering a wrong address (much worse than entering the wrong bank account 
in an online bank
transfer) might forget to look at the characters altogether.


> * If you're concerned about maliciously constructed addresses, which are 
designed to
look similar in specific places, an attacker can just as easily make the 
external
checksum collide (and having one might even worsen this, as now the 
attacker can focus
on exactly that, rather than needing to focus on every other character).

Not so concerned about this case, since this is a very special case that 
can only occur
under
certain circumstances. But taking this case also into consideration, this 
is why the user
should use the verification code ADDITIONALLY to the normal way of 
verifying, not
instead. If
the attacker only focuses on the verification code, he will only be 
successful with
users that
ONLY look at this code. But if the attacker intends to be more successful, 
he now needs to
create a valid address that is both similar in specific places