Dan Libby [ARCHIVE]

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

Public Key

npub1hm38d5dwxdq5zxlnv2qdfk3flecptqwl7g7u62ja0tr92d0hmrusejk43d

Profile Code

nprofile1qqstacnk6xhrxs2pr0ek9qx5mg5luuq4s80ly0wd9fwh43j4xhma37gpmm0m0

Author Public Key

npub1hm38d5dwxdq5zxlnv2qdfk3flecptqwl7g7u62ja0tr92d0hmrusejk43d

Show more details

Last Notes

2023-06-07 18:08:55

- reply

📅 Original date posted:2017-12-20
📝 Original message:currencyCode and cryptoCurrencyCode seem to assume that merchants will
always want to sell for fiat. But a merchant might want to sell for
another cryptocurrency instead.
Why not make it more generic, like buySymbol and sellSymbol?
> "currencyCode" : "CAD",
> "cryptoCurrencyCode" : "BTC",

2023-06-07 18:06:44

- reply

📅 Original date posted:2017-09-29
📝 Original message:Anyway, I'll count that as a NAK from Luke. what do others here think?
I wish to guage if I were to submit a functional pull request for one or
both of these RPC calls, if would it be likely to be accepted.
If so I'm happy to contribute my time, otherwise...
On 09/29/2017 03:13 PM, Dan Libby wrote:
> It seems to me that the same statement can be made for *any* key storage
> mechanism depending on one's security/threat model, including
> bitcoin-core's internal wallet storage. There certainly are cases where
> a paper (or metal) offline wallet makes a lot of sense, particularly for
> long-term offline storage... something that electronic media pretty much
> sucks at.
>
> Though if you care to elaborate I'd be interested to learn of your
> specific critiques, if you have any beyond the generic statements here:
> https://en.bitcoin.it/wiki/Paper_wallet
>
> Regardless, the APIs I've proposed have uses beyond paper wallets. It
> can also be used by third party wallets, or any number of reasons that
> individuals or devs might have to generate keys.
>
>
>
> On 09/29/2017 02:03 PM, Luke Dashjr wrote:
>> Paper wallets are a safety hazard, insecure, and generally not advisable.
>>
>>
>> On Friday 29 September 2017 5:29:17 PM Dan Libby via bitcoin-dev wrote:
>>> Hi,
>>>
>>> I'm writing to suggest and discuss the addition of paper wallet
>>> functionality in bitcoin-core software, starting with a single new RPC
>>> call: genExternalAddress [type].
>>>
>>> -- rationale --
>>>
>>> bitcoin-core is the most trusted and most secure bitcoin implementation.
>>>
>>> Yet today (unless I've missed something) paper wallet generation
>>> requires use of third party software, or even a website such as
>>> bitaddress.org. This requires placing trust in an additional body of
>>> code from a less-trusted and less peer-reviewed source. Ideally, one
>>> would personally audit this code for one's self, but in practice that
>>> rarely happens.
>>>
>>> In the case of a website generator, the code must be audited again each
>>> time it is downloaded. I cannot in good faith recommend to anyone to
>>> use such third party tools for wallet generation.
>>>
>>> I *would* recommend for others to trust a paper wallet that uses
>>> address(es) generated by bitcoin-core itself.
>>>
>>> At least for me, this requirement to audit (or implicitly trust) a
>>> secondary body of bitcoin code places an additional hurdle or
>>> disincentive on the use of paper wallets, or indeed private keys
>>> generated outside of bitcoin-core for any purpose.
>>>
>>> Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
>>> or getrawchangeaddress for this purpose, because the associated private
>>> keys are added to the bitcoin-core wallet and cannot be removed... or in
>>> the case of hd-wallets are deterministically derived.
>>>
>>> As such, I'm throwing out the following half-baked proposal as a
>>> starting point for discussion:
>>>
>>>
>>> -----
>>>
>>> genexternaladdress ( "type" )
>>>
>>> Returns a new Bitcoin address and private key for receiving
>>> payments. This key/address is intended for external usage such as
>>> paper wallets and will not be used by internal wallet nor written to
>>> disk.
>>>
>>> Arguments:
>>> 1. "type" (string, optional) one of: p2pkh, p2sh-p2wpkh
>>> default: p2sh-p2wpkh
>>>
>>> Result:
>>> {
>>> "privKey" (string) The private key in wif format.
>>> "address" (string) The address in p2pkh or p2sh-p2wpkh
>>> format.
>>> }
>>>
>>> Examples:
>>> > bitcoin-cli genexternaladdress
>>>
>>> ----
>>>
>>> This API is simple to implement and use. It provides enough
>>> functionality for any moderately skilled developer to create their own
>>> paper wallet creation script using any scripting language, or even for
>>> advanced users to perform using bitcoin-cli or debug console.
>>>
>>> If consensus here is in favor of including such an API, I will be happy
>>> to take a crack at implementing it and submitting a pull request.
>>>
>>> If anyone has reasons why it is a BAD IDEA to include such an RPC call
>>> in bitcoind, I'm curious to hear it.
>>>
>>> Also, I welcome suggestions for a better name, or maybe there could be
>>> some improvements to the param(s), such as calling p2sh-p2wpkh "segwit"
>>> instead.
>>>
>>>
>>> ---- further work ----
>>>
>>>
>>> Further steps could be taken in this direction, but are not necessary
>>> for a useful first-step. In particular:
>>>
>>> 1. an RPC call to generate an external HD wallet seed.
>>> 2. an RPC call to generate N key/address pairs from a given seed.
>>> 3. GUI functionality in bitcoin-qt to facilitate easy paper wallet
>>> generation (and printing?) for end-users, complete with nice graphics,
>>> qr codes, etc.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
Dan Libby
Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359

2023-06-07 18:06:43

- reply

📅 Original date posted:2017-09-29
📝 Original message:It seems to me that the same statement can be made for *any* key storage
mechanism depending on one's security/threat model, including
bitcoin-core's internal wallet storage. There certainly are cases where
a paper (or metal) offline wallet makes a lot of sense, particularly for
long-term offline storage... something that electronic media pretty much
sucks at.
Though if you care to elaborate I'd be interested to learn of your
specific critiques, if you have any beyond the generic statements here:
https://en.bitcoin.it/wiki/Paper_wallet
Regardless, the APIs I've proposed have uses beyond paper wallets. It
can also be used by third party wallets, or any number of reasons that
individuals or devs might have to generate keys.
On 09/29/2017 02:03 PM, Luke Dashjr wrote:
> Paper wallets are a safety hazard, insecure, and generally not advisable.
>
>
> On Friday 29 September 2017 5:29:17 PM Dan Libby via bitcoin-dev wrote:
>> Hi,
>>
>> I'm writing to suggest and discuss the addition of paper wallet
>> functionality in bitcoin-core software, starting with a single new RPC
>> call: genExternalAddress [type].
>>
>> -- rationale --
>>
>> bitcoin-core is the most trusted and most secure bitcoin implementation.
>>
>> Yet today (unless I've missed something) paper wallet generation
>> requires use of third party software, or even a website such as
>> bitaddress.org. This requires placing trust in an additional body of
>> code from a less-trusted and less peer-reviewed source. Ideally, one
>> would personally audit this code for one's self, but in practice that
>> rarely happens.
>>
>> In the case of a website generator, the code must be audited again each
>> time it is downloaded. I cannot in good faith recommend to anyone to
>> use such third party tools for wallet generation.
>>
>> I *would* recommend for others to trust a paper wallet that uses
>> address(es) generated by bitcoin-core itself.
>>
>> At least for me, this requirement to audit (or implicitly trust) a
>> secondary body of bitcoin code places an additional hurdle or
>> disincentive on the use of paper wallets, or indeed private keys
>> generated outside of bitcoin-core for any purpose.
>>
>> Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
>> or getrawchangeaddress for this purpose, because the associated private
>> keys are added to the bitcoin-core wallet and cannot be removed... or in
>> the case of hd-wallets are deterministically derived.
>>
>> As such, I'm throwing out the following half-baked proposal as a
>> starting point for discussion:
>>
>>
>> -----
>>
>> genexternaladdress ( "type" )
>>
>> Returns a new Bitcoin address and private key for receiving
>> payments. This key/address is intended for external usage such as
>> paper wallets and will not be used by internal wallet nor written to
>> disk.
>>
>> Arguments:
>> 1. "type" (string, optional) one of: p2pkh, p2sh-p2wpkh
>> default: p2sh-p2wpkh
>>
>> Result:
>> {
>> "privKey" (string) The private key in wif format.
>> "address" (string) The address in p2pkh or p2sh-p2wpkh
>> format.
>> }
>>
>> Examples:
>> > bitcoin-cli genexternaladdress
>>
>> ----
>>
>> This API is simple to implement and use. It provides enough
>> functionality for any moderately skilled developer to create their own
>> paper wallet creation script using any scripting language, or even for
>> advanced users to perform using bitcoin-cli or debug console.
>>
>> If consensus here is in favor of including such an API, I will be happy
>> to take a crack at implementing it and submitting a pull request.
>>
>> If anyone has reasons why it is a BAD IDEA to include such an RPC call
>> in bitcoind, I'm curious to hear it.
>>
>> Also, I welcome suggestions for a better name, or maybe there could be
>> some improvements to the param(s), such as calling p2sh-p2wpkh "segwit"
>> instead.
>>
>>
>> ---- further work ----
>>
>>
>> Further steps could be taken in this direction, but are not necessary
>> for a useful first-step. In particular:
>>
>> 1. an RPC call to generate an external HD wallet seed.
>> 2. an RPC call to generate N key/address pairs from a given seed.
>> 3. GUI functionality in bitcoin-qt to facilitate easy paper wallet
>> generation (and printing?) for end-users, complete with nice graphics,
>> qr codes, etc.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Dan Libby
Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359

2023-06-07 18:06:41

- reply

📅 Original date posted:2017-09-30
📝 Original message:On 09/29/2017 09:49 PM, Jonas Schnelli wrote:
> AFAIK, client implementations such as your proposal are off-topic for this ML.
> Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for such proposals.
ok, thanks. I will take the proposal there.
> I have to agree with Luke.
thanks for your feedback.
> And I would also extend those concerns to BIP39 plaintext paper backups.
>
> IMO, private keys should be generated and used (signing) on a trusted, minimal and offline hardware/os.
uhh.... do you apply this logic to the bitcoin-core wallet itself?
because clearly it generates keys and is intended to be used for signing
in online environments. Lots of real-world use-cases depend on that today.
So if existing bitcoin-core wallet behavior is "ok" in any context then
how is it any worse for it to generate a key/address that will not be
stored in the internal wallet, and the user may do with it as they wish?
That is all my proposed RPC call does and unlike the existing RPC calls
it never even stores the key or address to disk. It is also useful when
run on an offline hardware device, such as a laptop connected to an
non-networked printer.
Further, you mention the word trust. That's the crux of the matter. As
a full node operator, I've already placed my trust in the bitcoin-core
developers and dev/release practices. Why exactly should I trust the
software in this minimal offline hardware/os you mention if it is NOT
bitcoin core? And even if open source software, does that not at least
double my workload/expense to audit theat software in addition to
bitcoin-core?
> Users should have no way to view or export the private keys (expect for
> the seed backup).
I suppose that in your view then, dumpprivkey and dumpwallet RPCs should
be removed from bitcoin-core to fit this paradigm?
(Personally I actively avoid wallet software that takes this view and
treat users like children, preventing individuals direct access to the
keys for their own funds, which disempowers and sometimes results in a
form of lockin)
> Backups should be encrypted (whoever finds the paper backup should need a second factor to decrypt) and the restore process should be footgun-safe (especially the lost-passphrase deadlock).
This is more relevant to an application layer above the 2 RPC calls I
proposed. Encryption could be implemented (or not) by whichever software
calls the proposed RPC apis. And further the APIs can be called for
use-cases beyond just paper wallets.

2023-06-07 18:06:40

- reply

📅 Original date posted:2017-09-29
📝 Original message:One additional thought:
It should be useful to also define a multi-sig generation RPC.
This would facilitate multi-sig paper wallets stored in different
physical locations, amongst other use-cases.
Something like:
-----
genexternalmultisigaddress ( "m", "n", "type" )
Returns a new Bitcoin address and n number of private key(s).
This address and associated keys is intended for external usage such
as paper wallets and will not be used by internal wallet nor written
to disk.
Arguments:
1. "m" (integer, required) The number of required signers
to send funds.
2. "n" (integer, required) The number of authorized
signers
3. "type" (string, optional) one of: p2sh-p2pkh, p2sh-p2wpkh
default: p2sh-p2wpkh
Result:
{
"address", (string) The address in p2pkh or p2sh-p2wpkh
format.
"privkeys": [
(string) The private key in wif format.
]
}
Examples:
> bitcoin-cli genexternalmultisigaddress 2 3
-----
On 09/29/2017 10:29 AM, Dan Libby via bitcoin-dev wrote:
> Hi,
>
> I'm writing to suggest and discuss the addition of paper wallet
> functionality in bitcoin-core software, starting with a single new RPC
> call: genExternalAddress [type].
>
> -- rationale --
>
> bitcoin-core is the most trusted and most secure bitcoin implementation.
>
> Yet today (unless I've missed something) paper wallet generation
> requires use of third party software, or even a website such as
> bitaddress.org. This requires placing trust in an additional body of
> code from a less-trusted and less peer-reviewed source. Ideally, one
> would personally audit this code for one's self, but in practice that
> rarely happens.
>
> In the case of a website generator, the code must be audited again each
> time it is downloaded. I cannot in good faith recommend to anyone to
> use such third party tools for wallet generation.
>
> I *would* recommend for others to trust a paper wallet that uses
> address(es) generated by bitcoin-core itself.
>
> At least for me, this requirement to audit (or implicitly trust) a
> secondary body of bitcoin code places an additional hurdle or
> disincentive on the use of paper wallets, or indeed private keys
> generated outside of bitcoin-core for any purpose.
>
> Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
> or getrawchangeaddress for this purpose, because the associated private
> keys are added to the bitcoin-core wallet and cannot be removed... or in
> the case of hd-wallets are deterministically derived.

2023-06-07 18:06:40

- reply

📅 Original date posted:2017-09-29
📝 Original message:On 09/29/2017 11:07 AM, Andrew Johnson wrote:
> One consideration of exposing this in QT is that it may encourage users
> to generate paper wallets(which are generally used and recommended for
> cold storage) from online machines, rendering them moreso lukewarm
> rather than cold, since the keys weren't generated in an air-gapped
> environment.
true that. Though there's nothing stopping a diligent person from
installing bitcoin-core on a dedicated offline machine. The blockchain
wouldn't need to be synced at all for key generation purposes.
> When using bitaddress.org <http://bitaddress.org>
> locally(we /are /all only using it locally and not directly from the
> online webpage, right? ;) ) you've at least made the effort to seek out
> the repo, clone it locally, and use it on an offline machine and not
> retain any data from that session.
yeah, so I noticed this issue about Paper Wallet generation not being
possible with bitcoin-core exactly because I was recommending to a
non-technical user to use paper wallets, but then I also had to point
out that really bitaddress code should be downloaded, audited, etc,
before use. Things that are actually impossible for a non-technical user.
So I figured that instead I would make a simple script for them that
would use bitcoin-core to generate the addresses... and that's when it
dawned on me that it won't actually work with present day RPCs that are
all tied to internal wallet.
hence, this proposal.
> I'd suggest that any UI in QT include some sort of a modal dialog that
> informs the user that this is not a secure cold storage address unless
> it was created on an offline machine and printed on a non-networked
> printer, and the prompt must be accepted and dismissed before the wallet
> will provide the requested keys.
yes, agreed.

2023-06-07 18:06:39

- reply

📅 Original date posted:2017-09-29
📝 Original message:Hi,
I'm writing to suggest and discuss the addition of paper wallet
functionality in bitcoin-core software, starting with a single new RPC
call: genExternalAddress [type].
-- rationale --
bitcoin-core is the most trusted and most secure bitcoin implementation.
Yet today (unless I've missed something) paper wallet generation
requires use of third party software, or even a website such as
bitaddress.org. This requires placing trust in an additional body of
code from a less-trusted and less peer-reviewed source. Ideally, one
would personally audit this code for one's self, but in practice that
rarely happens.
In the case of a website generator, the code must be audited again each
time it is downloaded. I cannot in good faith recommend to anyone to
use such third party tools for wallet generation.
I *would* recommend for others to trust a paper wallet that uses
address(es) generated by bitcoin-core itself.
At least for me, this requirement to audit (or implicitly trust) a
secondary body of bitcoin code places an additional hurdle or
disincentive on the use of paper wallets, or indeed private keys
generated outside of bitcoin-core for any purpose.
Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
or getrawchangeaddress for this purpose, because the associated private
keys are added to the bitcoin-core wallet and cannot be removed... or in
the case of hd-wallets are deterministically derived.
As such, I'm throwing out the following half-baked proposal as a
starting point for discussion:
-----
genexternaladdress ( "type" )
Returns a new Bitcoin address and private key for receiving
payments. This key/address is intended for external usage such as
paper wallets and will not be used by internal wallet nor written to
disk.
Arguments:
1. "type" (string, optional) one of: p2pkh, p2sh-p2wpkh
default: p2sh-p2wpkh
Result:
{
"privKey" (string) The private key in wif format.
"address" (string) The address in p2pkh or p2sh-p2wpkh
format.
}
Examples:
> bitcoin-cli genexternaladdress
----
This API is simple to implement and use. It provides enough
functionality for any moderately skilled developer to create their own
paper wallet creation script using any scripting language, or even for
advanced users to perform using bitcoin-cli or debug console.
If consensus here is in favor of including such an API, I will be happy
to take a crack at implementing it and submitting a pull request.
If anyone has reasons why it is a BAD IDEA to include such an RPC call
in bitcoind, I'm curious to hear it.
Also, I welcome suggestions for a better name, or maybe there could be
some improvements to the param(s), such as calling p2sh-p2wpkh "segwit"
instead.
---- further work ----
Further steps could be taken in this direction, but are not necessary
for a useful first-step. In particular:
1. an RPC call to generate an external HD wallet seed.
2. an RPC call to generate N key/address pairs from a given seed.
3. GUI functionality in bitcoin-qt to facilitate easy paper wallet
generation (and printing?) for end-users, complete with nice graphics,
qr codes, etc.

2023-06-07 18:06:03

- reply

📅 Original date posted:2017-09-15
📝 Original message:Thanks for this link. From my reading though, it seems that only
soft-forks that attempt to freeze funds are problematic on ethereum.
>From the article:
> The soft fork creates a new and fundamentally different class of
> transactions in contrast with those that currently exist within the
> protocol. Currently, transactions either complete successfully and
> cause a state transition, or run into an exception, in which case
> state is reverted but the maximum possible gas is still charged. With
> the soft fork, transactions which interact with a DAO will not fit
> within these two classes: they will fail execution but no gas will be
> charged. This must inevitably be the case in any soft fork that aims
> to freeze the stolen funds;
So in the general case ethereum can still soft-fork I think...
On 09/15/2017 04:19 AM, Andrew Quentson wrote:
> From my understanding, the blockchain can be designed in such a way as
> to make soft-forks be impossible or at least impractical due to attack
> vectors.
>
> http://hackingdistributed.com/2016/06/28/ethereum-soft-fork-dos-vector/
>
> Ethereum, for example, can't soft-fork. They have to always hardfork.
>
> On 13 September 2017 at 10:50, Dan Libby via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> 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
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
--
Dan Libby
Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359

2023-06-07 18:06:02

- reply

📅 Original date posted:2017-09-15
📝 Original message:On 09/15/2017 01:40 PM, Simone Bronzini wrote:
> 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.
sure, but in this scenario how would one meaningfully "upgrade" the
functionality, eg add a new opcode? We couldn't, right? so....
success! Preventing new functionality is the primary goal of this
thought experiment. I believe that common sense and market incentives
would prevent arbitrary tightening of the rules for no good reason...

2023-06-07 18:06:01

- reply

📅 Original date posted:2017-09-15
📝 Original message: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

2023-06-07 18:06:00

- reply

📅 Original date posted:2017-09-15
📝 Original message:On 09/15/2017 02:14 AM, Adam Back wrote:
> However most types of soft fork are opt-in...
my concern is that the community can be manipulated via political means.
marketing, social media, payoffs, fud, etc, etc, etc. And essentially
degrades to tyranny of the majority.
So if there is any way to make opt-in forks impractical/infeasible for
purpose of network wide consensus rule change, I'd love to hear it.

2023-06-07 18:05:59

- reply

📅 Original date posted:2017-09-13
📝 Original message: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?

2023-06-07 18:05:17

- reply

📅 Original date posted:2017-09-06
📝 Original message:On 08/30/2017 12:24 AM, shiva sitamraju via bitcoin-dev wrote:
> What would happen if you recover a wallet using seed words ?
> 1. Since there is no difference in seed words between segwit/non
> segwit, the wallet would discover both m/44' and m/49' accounts
> 2. Note that we cannot ask the user to choose an account he wants to
> operate on (Segwit/Non segwit). This is like asking him the HD
> derivation path and a really bad UI
> 3. The wallet now has to constantly monitor both m/44' and m/49'
> accounts for transactions
small nit with 3.
It seems to me that the wallet would perform initial discovery on m/44
and m/49, and then would find transactions at one or the other, so it
can then record the type somewhere and from then on need only monitor
one branch.
Still, I agree it is ugly, makes initial discovery up to 2x slower, etc.
> *- XPUB Derivation*
> This is something not addressed in the BIP yet.
>
> 1. Right now you can get an xpub balance/transaction history. With m/49'
> there is no way to know whether an xpub is from m/44' or m/49'
>
> 2. This breaks lots of things. Wallets like electrum/armory/mycelium
> <https://blog.trezor.io/using-mycelium-to-watch-your-trezor-accounts-a836dce0b954>support
> importing xpub as a watch only wallet. Also services like
> blockonomics/blockchain.info <http://blockchain.info> use xpub for
> displaying balance/generating merchant addresses
>
> Looking forward to hearing your thoughts
speaking as author of tools hd-wallet-addrs and hd-wallet-derive, I
agree this is problematic.
would be great if xpub/xprv could somehow encode their absolute path in
wallet for tools to read. Users cannot be expected to know.

2023-06-07 18:04:29

- reply

📅 Original date posted:2017-07-13
📝 Original message:On 07/12/2017 06:48 PM, Anthony Towns via bitcoin-dev wrote:
> I think that terminology isn't quite precise. I think your options are:
>
> - if you're a miner or run a mining pool, you can *signal* (or not
> signal) support for segwit activation; you do this by controlling
> the block version
I wish to NOT signal for segwit if mining.
> - if you're running a node, you can choose to *enforce* (or not
> enforce) the additional consensus rules associated with segwit
I wish to NOT enforce segwit consensus rules.
>
> I think it's the latter you're talking about. "Activation" is different:
> it's the collective action of the bitcoin ecosystem to start enforcing
> the segwit consensus rules after a sufficient majority of miners are
> signalling support. That's not something you as an individual can control.
good point, thanks for clarifying.
> If you want to disable enforcement of segwit rules, even if a majority of
> mining power signal activation, you can change the code and recompile to
> do so, for example by changing the nTimeout setting for DEPLOYMENT_SEGWIT
> from 1510704000 (Nov 15 2017) to 1493596800 (May 1 2017, already expired).
> This is probably a bad idea, in that it will cause you to risk accepting
> blocks that nobody else in the network will accept, opening you up
> to higher risk of double spends, and may cause you to be unable to
> peer with segwit enabled nodes after segwit is activated if your node
> is rejecting blocks with witness data because you think segwit is not
> enabled while they think it is enabled. To avoid that you would also need
> to stop setting the NODE_WITNESS p2p bit, which you might be able to do
> by setting the nTimeout above to 0 instead of just a date in the past? I
> believe a timeout of 0 gets treated as automatically FAILED. There might
> be other complexities too though.
I've set the nTimeout to 0 already. I will look into the NODE_WITNESS
p2p bit.
I think that logically, if coded correctly, my node would have no more
risks than any other legacy (pre-segwit) node on the network...
>
>> I'm not looking for reasons NOT to do it, only HOW to do it without
>> unwanted side-effects.
>
> The unwanted side-effects are precisely the reasons not to do it. If you
> don't understand what they are, you won't be able to avoid them. :)
fair enough. But these are the same risks as running any pre-segwit
node, correct? For example bitcoin-core 0.13.0, or any version of
btcd to date...
--
Dan Libby
Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359

2023-06-07 18:04:28

- reply

📅 Original date posted:2017-07-13
📝 Original message:On 07/12/2017 06:04 PM, Gregory Maxwell wrote:
> On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev
> It is not simple to do so correctly, I couldn't tell you off the top
> of my head; a number of things must be changed it isn't as simple as
> disabling the activiation because of the segwit P2P changes. Nor is
> it a supported configuration. Even if it were now, it wouldn't be one
> we'd continue to support in the future after segwit is active, as
> we're likely to drop deployment/compat code.
I understand it is not in any way a supported configuration.
> Can you explain why you wish to do this? It should have absolutely no
> adverse impact on you-- if you don't use segwit, you don't use it-- it
> may be the case that there is some confusion about the implications
> that I could clear up for you... or suggest alternatives that might
> achieve your goals.
Please lets not go into the weeds debating about my reasons.
I actually have nothing against segwit per-se, and think it is clever
tech. I wish that it, or another malleability fix, had been baked in
from the start. But it wasn't, and I dislike changing the consensus
rules except if critical flaws are found.
anyway, some of my reasons are:
I am content with status-quo consensus rules.
I see greatest long-term value in a fixed, unchanging set of rules
(though that is outside my control of course).
I have limited bandwidth and resources and prefer 1mb limit for that reason.
Prior to activation, I do not choose to signal for segwit in any way
shape or form.
I realize I could run a pre-segwit node forever, but would like to enjoy
more recent features and otherwise avoid bit-rot.
I am mule-headed and stubborn. If network-wide activation should
happen, I will most likely upgrade to segwit at some point, but I intend
that point to be at my choosing, not because software defaults did it
for me.
I view it as a little bit of a personal challenge and experiment.
> Effectively the only reason I'm aware of to intentionally not run with
> segwit support beyond just not having upgraded yet, is a desire to try
> to temporarily have as your tip block a block that was actively
> stealing the segwit transactions of a third party. Which doesn't seem
> either personally or publicly desirable; but I fully admit I may be
> missing some good reason which I am not aware of.
no that thought did not enter my mind. still not sure I fully grok it
in fact, but no matter.
--
Dan Libby
Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359

2023-06-07 18:04:27

- reply

📅 Original date posted:2017-07-13
📝 Original message:On 07/13/2017 09:35 AM, Jameson Lopp wrote:
>
>
> On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote:
> >> I believe that a good reason not to wish your node to be segwit
> > compliant is to avoid having to deal with the extra bandwidth that
> > segwit could require. Running a 0.14.2 node means being ok with >1MB
> > blocks, in case segwit is activated and widely used. Users not
> > interested in segwit transactions may prefer to keep the cost of their
> > node lower.
> >
> > If the majority of the network decides to deploy SegWit, it would be in
> > your best interest to validate the SegWit transactions, because you
> > might will be downgraded to near-SPV node validation.
> > It would be okay to still run a "non-SegWit" node if there's no SegWit
> > transactions in the chain of transactions for your bitcoins, otherwise
> > you cannot fully verify the the ownership of your bitcoins.
> > I'm not sure the practicality of this in the long run, but it makes a
> > case for having an up-to-date non-SegWit node, although I think it's a
> > bit of a stretch.
>
> Right. Well, if I never upgrade to segwit, then there seems little
> (zero?) risk of having any segwit tx in my tx chain.
>
>
> If you mean you wish to avoid receiving UTXOs that have value that was
> at one point previously encumbered by a SegWit output then no, you can't
> avoid that. No more than you can currently avoid receiving BTC that were
> at one point in time encumbered by a P2SH output.
fair enough. This actually wasn't an area I'd considered much before
Hampus brought it up.
I would like to understand it a bit better, as I think it applies
equally to any pre-segwit node, yes? So let's say I am running 0.13.0
and someone sends me bitcoins to a P2PKH address, but that person
previously received them to a P2WPKH address.
If I understand correctly, my node will accept the incoming tx inputs
but obviously will not perform any segwit related validation, thus those
inputs are not fully validated. I don't yet understand how my node
thinks they are valid at all given that it does not understand P2WPKH
address format, so either it doesn't need to, or P2WPKH is somehow
already valid. I know this has all been discussed in the past, so if
someone can point me towards a document that explains it I'd be happy to
read that.
thanks!

2023-06-07 18:04:27

- reply

📅 Original date posted:2017-07-13
📝 Original message:Hampus, thanks for the explanation!
On 07/13/2017 03:50 PM, Hampus Sjöberg wrote:
> Yes.
> So you have two choices to be fully secure:
> 1. Validate using the new rules of the network (in other words, run a
> SegWit node)
> 2. Avoid any chain of transaction that contains a SegWit transaction
sounds good, though I'm unclear on how exactly to achieve (2) given that
any party I have ever transacted with (or otherwise knows an address of
mine) can send me coins at any time. So it seems the only possible way
to be certain is to run a node that has never published an address to a
3rd party. Is that accurate?
Another thing that could be done is to modify my own node so that it
actually rejects such tx, but then I have modified consensus rules
myself, thus defeating the goal of remaining with status-quo rules, and
anyway the rest of the network would accept the tx. I guess the benefit
is that I could be certain of the remaining funds I have.
I suppose that it would be possible without modifying any rule to
construct a "certain balance" and an "uncertain balance".
I don't intend to do such modifications! just grasping for understanding.
> See
> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_compatibility
> So the witness program is encoded in a new format that old nodes do not
> understand.
> This means that for old nodes, a number >0 will be put on the stack.
> When the script is done, it will be evaluated to true (because of >0)
> and be counted as a valid spend.
>
> https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also
> explains the new witness program more in detail (I left out some details
> in my explanation).
I read the relevant parts, thanks!

2023-06-07 18:04:26

- reply

📅 Original date posted:2017-07-13
📝 Original message:On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote:
>> I believe that a good reason not to wish your node to be segwit
> compliant is to avoid having to deal with the extra bandwidth that
> segwit could require. Running a 0.14.2 node means being ok with >1MB
> blocks, in case segwit is activated and widely used. Users not
> interested in segwit transactions may prefer to keep the cost of their
> node lower.
>
> If the majority of the network decides to deploy SegWit, it would be in
> your best interest to validate the SegWit transactions, because you
> might will be downgraded to near-SPV node validation.
> It would be okay to still run a "non-SegWit" node if there's no SegWit
> transactions in the chain of transactions for your bitcoins, otherwise
> you cannot fully verify the the ownership of your bitcoins.
> I'm not sure the practicality of this in the long run, but it makes a
> case for having an up-to-date non-SegWit node, although I think it's a
> bit of a stretch.
Right. Well, if I never upgrade to segwit, then there seems little
(zero?) risk of having any segwit tx in my tx chain.
Thus this would be a way I could continue with a lower bandwidth cap and
also keep my coins "untainted", so to speak.
I'm not sure about it for the long run either. more just something of
an experiment.

2023-06-07 18:04:25

- reply

📅 Original date posted:2017-07-12
📝 Original message:Hi!
Up to now, I have purposefully been running bitcoin releases prior to
0.13.1 as a way to avoid the (possible) segwit activation, at least
until such time as I personally am comfortable with it.
At this time, I would like to have some of the more recent features, but
without the possibility that my node will activate segwit, until I
choose to.
As I understand it, there is not any user setting that can disable
segwit from activating on my node. If there was, I would use it.
Please correct me if wrong.
I am here to ask what is the simplest code change (fewest LOC changed) I
can make to 0.14.2+ code that would disable segwit from activating and
keep my node acting just like a legacy node with regards to consensus
rules, even if/when the rest of the network activates segwit.
I think, more generally, the same question applies to most any Bip9
versionbits feature.
I'm not looking for reasons NOT to do it, only HOW to do it without
unwanted side-effects. My first untested idea is just to change the
segwit nTimeout in chainparams.cpp to a date in the past. But I figured
I should ask the experts first. :-)
thanks.
ps: full disclosure: I may be the only one who wants this, but if
successful, I do plan to release my changes in case someone else wishes
to run with status-quo consensus rules.