Re: [bitcoin-dev] proposal: extend WIF format for segwit

[Pieter Wuille via bitcoin-dev]

On Sep 15, 2017 01:56, "Thomas Voegtlin via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

Note 3: we could also use a bech32 format for the private key, if it is
going to be used with a bech32 address. I am not sure if such a format
has been proposed already.


I've been working on an "extended bech32" format with 12 character checksum
rather than 6, for private keys and other things that need stronger
protection. It would guarantee correcting 4 errors, where normal bech32 can
only detect (but not correct) 4.

The rationale is that in the case of an address, if an error is detected,
you can ask the receiver for a corrected version. As that option doesn't
exist for private keys you want something stronger.

This has been a low-priority thing for me, though, and the computation work
to find a good checksum is significant.

Cheers,

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

Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

[ZmnSCPxj via bitcoin-dev]

Good Morning Dan,

No.

Let us suppose that IsStandard is applied to outputs, but we support P2SH. Then 
we could encode those scripts in P2SH. The softfork could require the script 
preimageto be put elsewhere, such as an OP_RETURN in the same tx, to determine 
the script that is anyone can spend.

We could ban P2SH or restrict P2SH to be IsStandard also, but you are now 
unable to support HTLC (no atomic swap) or LN, unless you specifically add 
those scripts to IsStandard. And if a better layer 2 comes along or LN is 
updated to use better scripts, you have to hardfork those in.

Even then, you can still be softforked. Remember that if we pay to a P2PKH, 
then publish the private key, every output paying to that address is now 
practically anyone can spend. Then a softfork can implement desired rules in an 
extensiom block, where money in UTXOs paying to the special publicized 
"private" key are controlled, post softfork, by data in a block that is not 
published to pre softfork nodes, like witness data is treated in SegWit.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

>  Original Message 
> Subject: Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?
> Local Time: September 16, 2017 3:55 AM
> UTC Time: September 15, 2017 7:55 PM
> From: d...@osc.co.cr
> To: ZmnSCPxj 
> Bitcoin Protocol Discussion 
>
> 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
>>
>>  OP_TRUE
>>
>> So is the below:
>>
>> OP_SIZE  OP_EQUAL
>>
>> Or:
>>
>> OP_1ADD  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  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 

Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

[Dan Libby via bitcoin-dev]

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...


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