Simone Bronzini [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-07-21 to 2017-09-15
💬 Posted a total of 5 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:06:01

- reply

📅 Original date posted:2017-09-15
📝 Original message:Since a soft-fork is a restriction of the consensus rules, I think the
only way to have an un-soft-forkable cryptocurrency is creating a
cryptocurrency where no transaction is valid.
Imagine I build a very minimal cryptocurrency where in the transaction
output you only indicate the public key to send your coins to and the
amount. One can still soft-fork it by deciding that, from now on, only
even amounts are valid or only public keys that are a multiple of 10 are
valid.
On 15/09/17 21:55, Dan Libby via bitcoin-dev wrote:
> Ok, this is good stuff. thanks for the thoughtful reply.
>
> Regarding anyone-can-spend:
>
> all of the examples you gave do not satisfy isStandard. So if our
> hypothetical cryptocurrency were to restrict all transactions to
> isStandard at the consensus layer, would that not effectively prevent
> anyone-can-spend?
>
> Or more generally and with our thinking caps on, what would be the best
> way to prevent anyone-can-spend, if that is our goal?
>
>
> Regarding soft-fork = restrict:
>
> Your example of miners running secret soft-fork code that blacklists
> satoshi's utxo's is intriguing and somewhat troubling.
>
> I think the main takeaways are that:
> 1) there are other ways to soft-fork besides anyone-can-spend.
> 2) it is impossible to prevent hidden soft-forks.
>
> Is that accurate?
>
> Still, I would put forth the following question: If anyone-can-spend tx
> were no longer allowed according to consensus rules (assuming that is
> possible/practical), then could the network still be practically
> "upgraded" with new features (eg opcodes) via soft-fork, and if so, what
> would be the mechanism for backwards compatibility in this scenario?
>
>
> or from another angle: even if it is impossible to prevent all
> soft-forks, can you see any way at all to make it logistically
> infeasible to use soft-forks as a network-wide consensus change mechanism?
>
> and another thought: as I understand it, bitcoin is presently able to
> add new opcodes via soft-fork because Satoshi added 10 unused opcodes
> via hardfork. What will happen when these run out? Can new opcodes
> still be added without a hard-fork?
>
>
> note: I ask these questions with the goal/vision of creating an
> immutable altcoin or sidechain, not necessarily restricting bitcoin's path.
>
>
>
>
>
> On 09/14/2017 09:01 PM, ZmnSCPxj wrote:
>> Good morning Dan,
>>
>> My understanding is that it is impossible for soft forks to be prevented.
>>
>> 1. Anyone-can-spend
>>
>> There are a very large number of anyone-can-spend scripts, and it would
>> be very impractical to ban them all.
>>
>> For example, the below output script is anyone-can-spend
>>
>> <random number> OP_TRUE
>>
>> So is the below:
>>
>> OP_SIZE <random small number> OP_EQUAL
>>
>> Or:
>>
>> OP_1ADD <random number> OP_EQUAL
>>
>> Or:
>>
>> OP_BOOLAND
>>
>> Or:
>>
>> OP_BOOLOR
>>
>> And so on.
>>
>> So no, it is not practically possible to ban anyone-can-spend outputs,
>> as there are too many potential scriptPubKey that anyone can spend.
>>
>> It is even possible to have an output that requires a proof-of-work,
>> like so:
>>
>> OP_HASH256 <difficulty target> OP_LESSTHAN
>>
>> All the above outputs are disallowed from propagation by IsStandard, but
>> a miner can put them validly in a block, and IsStandard is not consensus
>> code and can be modified.
>>
>> 2. Soft fork = restrict
>>
>> It is possible (although unlikely) for a majority of miners to run soft
>> forking code which the rest of us are not privy to.
>>
>> For example, for all we know, miners are already blacklisting spends on
>> Satoshi's coins. We would not be able to detect this at all, since no
>> transaction that spends Satoshi's coins have been broadcast, ever. It
>> is thus indistinguishable from a world where Satoshi lost his private
>> keys. Of course, the world where Satoshi never spent his coins and
>> miners are blacklisting Satoshi's coins, is more complex than the world
>> where Satoshi never spent his coins, so it is more likely that miners
>> are not blacklisting.
>>
>> But the principle is there. We may already be in a softfork whose rules
>> we do not know, and it just so happens that all our transactions today
>> do not violate those rules. It is impossible for us to know this, but
>> it is very unlikely.
>>
>> Soft forks apply further restrictions on Bitcoin. Hard forks do not.
>> Thus, if everyone else is entering a soft fork and we are oblivious, we
>> do not even know about it. Whereas, if everyone else is entering a hard
>> fork, we will immediately see (and reject) invalid transactions and blocks.
>>
>> Thus the only way to prevent soft fork is to hard fork against the new
>> soft fork, like Bcash did.
>>
>> Regards,
>> ZmnSCPxj
>>
>> -------- Original Message --------
>> Subject: [bitcoin-dev] hypothetical: Could soft-forks be prevented?
>> Local Time: September 13, 2017 5:50 PM
>> UTC Time: September 13, 2017 9:50 AM
>> From: bitcoin-dev at lists.linuxfoundation.org
>> To: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>>
>> Hi, I am interested in the possibility of a cryptocurrency software
>> (future bitcoin or a future altcoin) that strives to have immutable
>> consensus rules.
>>
>> The goal of such a cryptocurrency would not be to have the latest and
>> greatest tech, but rather to be a long-term store of value and to offer
>> investors great certainty and predictability... something that markets
>> tend to like. And of course, zero consensus rule changes also means
>> less chance of new bugs and attack surface remains the same, which is
>> good for security.
>>
>> Of course, hard-forks are always possible. But that is a clear split
>> and something that people must opt into. Each party has to make a
>> choice, and inertia is on the side of the status quo. Whereas
>> soft-forks sort of drag people along with them, even those who oppose
>> the changes and never upgrade. In my view, that is problematic,
>> especially for a coin with permanent consensus rule immutability as a
>> goal/ethic.
>>
>> As I understand it, bitcoin soft-forks always rely on anyone-can-spend
>> transactions. If those were removed, would it effectively prevent
>> soft-forks, or are there other possible mechanisms? How important are
>> any-one-can spend tx for other uses?
>>
>> More generally, do you think it is possible to programmatically
>> avoid/ban soft-forks, and if so, how would you go about it?
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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 --------------
A non-text attachment was scrubbed...
Name: 0xB2E60C73.asc
Type: application/pgp-keys
Size: 15541 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170915/56ee44a1/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170915/56ee44a1/attachment-0001.sig>

2023-06-07 18:05:09

- reply

📅 Original date posted:2017-08-29
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi all,
last month we started looking for feedback (here and on other channels)
about a proposal for a new structure to facilitate the management of
different multisig accounts under the same master key, avoiding key
reuse but still allowing cosigners to independently generate new
addresses. While previously multiaccount multisig wallets were little
used, now that LN is becoming a reality it is extremely important to
have a better multiaccount management method to handle multiple payment
channels.
Please have a look at the draft of the BIP at the link below:
https://github.com/chainside/BIP-proposal/blob/master/BIP.mediawiki
Any feedback is highly appreciated, but in particular we would like to
collect opinions about the following issues:
1. coin_type level:
this level is intended to allow users to manage multiple
cryptocurrencies or forks of Bitcoin using the same masterkey (similarly
to BIP44). We have already received some legit objections that, since we
are talking about a Bitcoin Improvement Proposal, it shouldn't care
about alt-coins. While we can agree with such objections, we also
believe that having a coin_type level improves interoperability with
muti-currency wallets (which is good), without any major drawback.
Moreover, even a Bitcoin maximalist may hold multiple coins for whatever
reason (short term speculation, testing, etc).
2. SegWit addresses:
since mixing SegWit and non-SegWit addresses on the same BIP44 structure
could lead to UTXOs not being completely recognised by old wallets,
BIP49 was proposed to separate the key space. Since this is a new
proposal, we can assume that wallets implementing it would be
SegWit-compatible and so there should be no need to differetiate between
SegWit and non-SegWit pubkeys. Anyway, if someone believes this problem
still holds, we thought about two possible solutions:
a. Create separate purposes for SegWit and non SegWit addresses
(this would keep the same standard as BIP44 and BIP49)
b. Create a new level on this proposed structure to divide SegWit
and non SegWit addresses: we would suggest to add this new level between
cosigner_index and change
We believe solution b. would be better as it would give the option of
having a multisig wallet with non SegWit-aware cosigners without having
to use two different subtrees.
This proposal is a work in progess so we would like to receive some
feedback before moving on with proposing it as a BIP draft.
Simone Bronzini
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEErS/wgXh5+C1vqPN/TXSJoN+7oQoFAlmlP2QACgkQTXSJoN+7
oQptgA/7B46/Why5h5/cxWyvgjmuUJ12Rkvh+EtfOUhMX+a8i4PJkLHGB2RibRfR
/Li1F+QWd2yeqdNO97er8HDGSlouxB7twB0ZMnS/LRPsHTA3Zf4OoD7H/yjj3lcD
GiJGy4MiHEOfjqaIwd0onUPX9ch5+Mm7aL34vBDdK0/8gm2v+HGO+GAefaUnZTQh
/CIaM0Th9dDS0xs5wcP3ncNqs1e59MHXOWlh7+zAxfvFio+HHnCbULIe4uct6stC
QxTNh8naQD4cB7tV9wsEeyuuJQ1gG8/pgN3WgRu5gW9CGpmpsySJgCCftkTZZHeL
eoqGJy5XFbI4CN2wEC2pbWW0xtDNyFq71wUPYNXINn8/7rnSjSl06OKISEk0u1yL
vhFuR9RSxEge2cS1pDwIwHVNR6pCeZMRwo0tp1OEXnt5VGGpmKengtpcFkFlOVdd
avUueIe8OoFGODco4+f25foB/z/rzyg3REXYX36bZiS6UkUOx4TCGpAzY86i4fDJ
STeDy5KMLk1S9rvTNrygxR74DkFMiNkalF3g4VauUlCFmh8iOzEDdtOQ3mLu/pgq
MXxfxq6ABxeCmQ7LsuBcFc+wN6AVLhrOhIPGyI8EAyaZNIGByqdgZGubvOl0J/gt
Yr4z5fViI7hjJijvooKzFtX0MNnaLBCOlggLpQO58t8En+BiNDE=
=XgcB
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xB2E60C73.asc
Type: application/pgp-keys
Size: 15541 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170829/3be6b307/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xB2E60C73.asc.sig
Type: application/pgp-signature
Size: 566 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170829/3be6b307/attachment-0001.sig>

2023-06-07 18:05:09

- reply

📅 Original date posted:2017-08-30
📝 Original message:Thanks for your feedback, I fixed what you suggested. As for the purpose
how should we move on? We would be inclined to use 46, but of course we
are open to any other number.
On 29/08/17 22:07, Luke Dashjr via bitcoin-dev wrote:
>> Status: Proposed
> This should only be set after peer review and implementations are complete,
> and you intend that there will be no further changes.
>
>> As registered coin types we propose the ones already used for BIP44, which
> can be found at the following page.
>
> I suggest just referring to SLIP 44 directly.
>
> You're missing the Backward Compatibility and Copyright sections.
>
>
>
> On Tuesday 29 August 2017 10:19:10 AM Simone Bronzini via bitcoin-dev wrote:
>> Hi all,
>> last month we started looking for feedback (here and on other channels)
>> about a proposal for a new structure to facilitate the management of
>> different multisig accounts under the same master key, avoiding key
>> reuse but still allowing cosigners to independently generate new
>> addresses. While previously multiaccount multisig wallets were little
>> used, now that LN is becoming a reality it is extremely important to
>> have a better multiaccount management method to handle multiple payment
>> channels.
>> Please have a look at the draft of the BIP at the link below:
>>
>> https://github.com/chainside/BIP-proposal/blob/master/BIP.mediawiki
>>
>> Any feedback is highly appreciated, but in particular we would like to
>> collect opinions about the following issues:
>>
>> 1. coin_type level:
>> this level is intended to allow users to manage multiple
>> cryptocurrencies or forks of Bitcoin using the same masterkey (similarly
>> to BIP44). We have already received some legit objections that, since we
>> are talking about a Bitcoin Improvement Proposal, it shouldn't care
>> about alt-coins. While we can agree with such objections, we also
>> believe that having a coin_type level improves interoperability with
>> muti-currency wallets (which is good), without any major drawback.
>> Moreover, even a Bitcoin maximalist may hold multiple coins for whatever
>> reason (short term speculation, testing, etc).
>>
>> 2. SegWit addresses:
>> since mixing SegWit and non-SegWit addresses on the same BIP44 structure
>> could lead to UTXOs not being completely recognised by old wallets,
>> BIP49 was proposed to separate the key space. Since this is a new
>> proposal, we can assume that wallets implementing it would be
>> SegWit-compatible and so there should be no need to differetiate between
>> SegWit and non-SegWit pubkeys. Anyway, if someone believes this problem
>> still holds, we thought about two possible solutions:
>> a. Create separate purposes for SegWit and non SegWit addresses
>> (this would keep the same standard as BIP44 and BIP49)
>> b. Create a new level on this proposed structure to divide SegWit
>> and non SegWit addresses: we would suggest to add this new level between
>> cosigner_index and change
>>
>> We believe solution b. would be better as it would give the option of
>> having a multisig wallet with non SegWit-aware cosigners without having
>> to use two different subtrees.
>>
>> This proposal is a work in progess so we would like to receive some
>> feedback before moving on with proposing it as a BIP draft.
>>
>> Simone Bronzini
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xB2E60C73.asc
Type: application/pgp-keys
Size: 15541 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170830/8b886086/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170830/8b886086/attachment-0001.sig>