Re: [bitcoin-dev] 32-byte public keys in Schnorr and Taproot

[Christopher Allen via bitcoin-dev]

On Fri, Aug 9, 2019 at 11:17 AM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> if we're going to change things, it's perhaps best to do it as cleanly as
> possible and also drop that byte.
>

I personally lean toward just dropping the byte. I like the simplicity and
I really like 32 bytes. 33 seems so over the edge and so odd ;-)

Yes, there may be some prototype implementations out there that did some
extra work, and will need to be revised, but that is always the risk
developers take when writing code when the spec hasn't fully been
implemented yet.

If you do revise the spec, would you consider proposing a format for
sharing public keys in a non-binary form, maybe using bech32? Given some of
the protocols emerging that may use Schnorr public keys in novel ways,
having a single encoding format for them would be useful.

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

Re: [bitcoin-dev] Taproot proposal

[Pieter Wuille via bitcoin-dev]

On Fri, 9 Aug 2019 at 08:02, Elichai Turkel via bitcoin-dev
 wrote:
>
> Hi,

Since the idea of implicitly even pubkeys has potentially more general
implications, I've started a separate thread [1] about that idea.

> I want to add to John Newbery's suggestion of using implicit even/odd only 
> public keys and tweaked public keys in taproot and suggest the following:
> If everything is implicit then the only reason for the first byte of the 
> control block(`c[0]`) is the tapscript leaf version.

That's unfortunately not correct. If we want to maintain
batch-verifiability of the taproot tweaking (the Q = P + H(P,m)G
relation), we still need a bit in the control block to convey whether
a negation was necessary to make P+H(P,m)G even, even if P and Q both
have implied-even Y coordinates. Not doing that would require
exploring 2^n combinations to batch verify n relations, obviously
destroying any performance savings the batch verification had in the
first place.

> I suggest that this is moved to be the first OP_CODE of the tapscript itself 
> (i.e. OP_0/OP_1 etc.)
> That way having the script *tells* you what does it mean without needing to 
> check the control block.
> That way there's a separation between the tapscript+leaf version and the 
> control block being the merkle path to the script.

If we keep the leaf version idea (it's possible to instead just rely
entirely on OP_SUCCESSx, and drop leaf versions), my preference is to
still keep it separate from script, though just for a fairly banal
reason: that way the script consists entirely of opcodes and can be
treated uniformly by debug tools, rather than needing to treat the
first byte special. I do understand your preference too, but I don't
know how it weighs up.

  [1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017247.html

Cheers,

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

[bitcoin-dev] 32-byte public keys in Schnorr and Taproot

[Pieter Wuille via bitcoin-dev]

Hello all,

It has been suggested [1] to drop the Y oddness bit in the witness
program for Taproot outputs. This seems like a worthwhile change, as:
* The bit doesn't actually contribute to security.
* It avoids Taproot outputs from being more expensive to create than v0 P2WSH.
* It doesn't preclude future changes that would still need the
additional byte anyway.

In exploring that option, Jonas Nick found that it seems cleanest [2]
to actually introduce a type of 32-byte public keys (which implicitly
have an even Y coordinate) in bip-schnorr, with associated signing and
verification logic that are distinct from the 33-byte variant.

This makes me wonder if we need 33-byte public keys at all.

So I'd like to hear opinions about modifying bip-schnorr to only
define 32-byte public keys. The implications of that would be:
* bip-schnorr public keys wouldn't be exactly the same as ECDSA public
keys, however all derivation logic would still apply (BIP32,
mnemonics, xpubs, ... would still exist and be compatible - just the
first pubkey byte would be dropped at the end).
* The Q point in bip-taproot (the one going in the scriptPubKey) would
just follow the 32-byte pubkey encoding, rather than needing a 33rd
byte.
* The P point in bip-taproot (the internal key revealed during script
path) would become just a 32-byte public key (and we can drop the one
bit in the control block to transmit the oddness of the Y coordinate
of P).
* In order to permit batch verification of the P to Q tweaking for
script-path spending, another control block bit is now needed, namely
one that indicates whether a negation was needed to make P+H(P||m)*G's
Y coordinate even.
* All public keys inside bip-tapscript would also become 32-bytes. If
desired, the "upgradable public key" construction in bip-tapscript can
be kept, by triggering based on the length of public keys (rather than
based on their first byte).

One question is whether it's worth such a change to bip-schnorr at
this point. We've purposefully never progressed it past draft since
publishing [3], but it has been a while. If necessary, it's possible
to keep verification compatible by still hashing the implied "even"
byte inside the scheme (which commits to the pubkey), but if we're
going to change things, it's perhaps best to do it as cleanly as
possible and also drop that byte.

Opinions?

  [1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016943.html
  [2] https://github.com/sipa/bips/pull/52
  [3] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html

Cheers,

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

Re: [bitcoin-dev] Taproot proposal

[Elichai Turkel via bitcoin-dev]

Hi,
I want to add to John Newbery's suggestion of using implicit even/odd only
public keys and tweaked public keys in taproot and suggest the following:

If everything is implicit then the only reason for the first byte of the
control block(`c[0]`) is the tapscript leaf version.
I suggest that this is moved to be the first OP_CODE of the tapscript
itself (i.e. OP_0/OP_1 etc.)
That way having the script *tells* you what does it mean without needing to
check the control block.
That way there's a separation between the tapscript+leaf version and the
control block being the merkle path to the script.
-- 
PGP: 5607C93B5F86650C
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[ZmnSCPxj via bitcoin-dev]

Good morning Haoyu LIN et al.,


> We have investigated this problem in very detail. We analysed how profitable 
> the arbitrage can be given the default timelock setting (24/48 hrs). Our 
> result shows that the profit can be approximately 1% ~ 2.3%, which is 
> non-negligible compared with 0.3% for stock market. This can be attractive as 
> it's totally risk-free. Please refer to our paper 
> https://eprint.iacr.org/2019/896, and the related code 
> https://github.com/HAOYUatHZ/fair-atomic-swap if interested.
>
> Several studies have proposed for solving this problem e.g., 
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ and 
> https://coblox.tech/docs/financial_crypto19.pdf. Their basic idea is that, 
> the transaction for the premium needs to be locked with the same secret hash 
> but with a flipped payout, i.e. when redeemed with the secret, the money goes 
> back to Alice and after timelock, the premium goes to Bob as a compensation 
> for Alice not revealing the secret. However, this introduces a new problem: 
> Bob can get the premium without paying anything, by never participating in.
>
> To solve this, the transaction verifier needs to know the status of an 
> dependent transaction. Unfortunately, Bitcoin does not support the stateful 
> transaction functionalities. Therefore, we propose the new opcode: 
> OP_LOOKUP_OUTPUT. It takes the id of an output, and produces the address of 
> the output’s owner. With OP_LOOKUP_OUTPUT, the Bitcoin script can decide 
> whether Alice or Bob should take the premium by ` OP_LOOKUP_OUTPUT 
>  OP_EQUALVERIFY`.

I believe an unsaid principle of SCRIPT opcode design is this:

* No SCRIPT opcode can look at anything that is not in the transaction spending 
from the SCRIPT.

This issue underlies the previous `OP_PUBREF` proposal also.

The reason for this is:

* We support a pruning mode, where in only the UTXO set is retained.
  If `OP_LOOKUP_OUTPUT` exists, we cannot prune, as `OP_LOOKUP_OUTPUT` might 
refer to a TXO that has been spent in very early historical blocks.
* The SCRIPT interpreter is run only once, at the time the transaction enters 
the mempool.
  Thus it cannot get information about the block it is in.
  Instead, the SCRIPT interpreter can have as input only the transaction that 
is attempting to spend the SCRIPT.

In any case:

> However, this introduces a new problem: Bob can get the premium without 
> paying anything, by never participating in.

Premium payment can be made contingent on Bob participating.
Of course, it does mean the premium is paid using the destination coin.
It also requires the destination coin to support SegWit.

Let me explain by this:

1.  Alice and Bob agree on swap parameters:
* Alice will exchange 1 BTC for 1,000,000 WJT from Bob.
* Alice will pay 10,000 WJT as premium to Bob.
* Alice will lock BTC for 48 hours.
* Bob will lock WJT for 24 hours.
* The protocol will start at particular time T.
2.  Alice generates a preimage+hash.
3.  Alice pays 1 BTC to a HTLC with hashlock going to Bob and timelocked at 
T+48 going to Alice.
4.  Alice presents above UTXO to Bob.
5.  Alice reveals the WJT UTXOs to be spent to pay for the 10,000 WJT premium 
to Bob.
6.  Alice and Bob generate, but do not sign, a funding transaction spending 
some of Bob coin as well as the premium coin from Alice.
This pays out to 1,010,000 WJT (the value plus the premium) HTLC.
The hashlock branch requires not just Alice, but also Bob.
The timelock branch at T+24 just requires Bob.
7.  Alice and Bob generate the claim transaction.
This spends the funding transaction HTLC output and pays out 1,000,000 WJT 
to Alice and 10,000 WJT to Bob.
8.  Alice and Bob sign the claim transaction.
This does not allow Bob to make the claim transaction valid by itself as it 
still requires the preimage, and at this point, only Alice knows the preimage.
9.  Alice and Bob sign the funding transaction and broadcast it.
10.  Alice completes the claim transaction by adding the preimage and 
broadcasts it.
11.  Bob sees the preimage on the WJT blockchain and claims the BTC using the 
preimage.

If Bob stalls at step 8, then there is no way to claim the premium, as the 
funding transaction (which is the source of the claim transaction that pays the 
premium) is not valid yet.
After step 9, Bob has been forced to participate and cannot back out and claim 
the premium only.

This is basically this proposal: 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001798.html


In addition, if you really want the premium to be denominated in BTC, I have a 
more complicated ritual: 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001795.html
The described ritual only sets up the American Call Option, but by the time it 
has been set up, the premium has been paid already and the rest of the 
execution is claiming the American Call Option.


Thus, I believe there is no need to add 

[bitcoin-dev] Bitcoin Core 0.18.1 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.18.1 is now available from:

  

Or through BitTorrent:


magnet:?xt=urn:btih:c3ba0cfee3ef8413098ac5e81db08a2670e9da8c=bitcoin-core-0.18.1=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969

This is a new minor version release, including new features, various bug
fixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

How to Upgrade
==

If you are running an older version, shut it down. Wait until it has
completely shut down (which might take a few minutes for older
versions), then run the installer (on Windows) or just copy over
`/Applications/Bitcoin-Qt` (on Mac) or `bitcoind`/`bitcoin-qt` (on
Linux).

The first time you run version 0.15.0 or newer, your chainstate database
will be converted to a new format, which will take anywhere from a few
minutes to half an hour, depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and
there is no automatic upgrade code from before version 0.8 to version
0.15.0 or later. Upgrading directly from 0.7.x and earlier without
redownloading the blockchain is not supported.  However, as usual, old
wallet versions are still supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.10+, and Windows 7 and newer. It is not
recommended to use Bitcoin Core on unsupported systems.

Bitcoin Core should also work on most other Unix-like systems but is not
as frequently tested on them.

- From 0.17.0 onwards, macOS <10.10 is no longer supported. 0.17.0 is
built using Qt 5.9.x, which doesn't support versions of macOS older than
10.10. Additionally, Bitcoin Core does not yet change appearance when
macOS "dark mode" is activated.

Known issues


Wallet GUI
- --

For advanced users who have both (1) enabled coin control features, and
(2) are using multiple wallets loaded at the same time: The coin control
input selection dialog can erroneously retain wrong-wallet state when
switching wallets using the dropdown menu. For now, it is recommended
not to use coin control features with multiple wallets loaded.

0.18.1 change log
=

### P2P protocol and network code
- - #15990 Add tests and documentation for blocksonly (MarcoFalke)
- - #16021 Avoid logging transaction decode errors to stderr (MarcoFalke)
- - #16405 fix: tor: Call `event_base_loopbreak` from the event's callback 
(promag)
- - #16412 Make poll in InterruptibleRecv only filter for POLLIN events 
(tecnovert)

### Wallet
- - #15913 Add -ignorepartialspends to list of ignored wallet options (luke-jr)

### RPC and other APIs
- - #15991 Bugfix: fix pruneblockchain returned prune height (jonasschnelli)
- - #15899 Document iswitness flag and fix bug in converttopsbt (MarcoFalke)
- - #16026 Ensure that uncompressed public keys in a multisig always returns a 
legacy address (achow101)
- - #14039 Disallow extended encoding for non-witness transactions (sipa)
- - #16210 add 2nd arg to signrawtransactionwithkey examples (dooglus)
- - #16250 signrawtransactionwithkey: report error when missing 
redeemScript/witnessScript (ajtowns)

### GUI
- - #16044 fix the bug of OPEN CONFIGURATION FILE on Mac (shannon1916)
- - #15957 Show "No wallets available" in open menu instead of nothing 
(meshcollider)
- - #16118 Enable open wallet menu on setWalletController (promag)
- - #16135 Set progressDialog to nullptr (promag)
- - #16231 Fix open wallet menu initialization order (promag) 
- - #16254 Set `AA_EnableHighDpiScaling` attribute early (hebasto) 
- - #16122 Enable console line edit on setClientModel (promag) 
- - #16348 Assert QMetaObject::invokeMethod result (promag)

### Build system
- - #15985 Add test for GCC bug 90348 (sipa)
- - #15947 Install bitcoin-wallet manpage (domob1812)
- - #15983 build with -fstack-reuse=none (MarcoFalke)

### Tests and QA
- - #15826 Pure python EC (sipa)
- - #15893 Add test for superfluous witness record in deserialization 
(instagibbs)
- - #14818 Bugfix: test/functional/rpc_psbt: Remove check for specific error 
message that depends on uncertain assumptions (luke-jr)
- - #15831 Add test that addmultisigaddress fails for watchonly addresses 
(MarcoFalke)

### Documentation
- - #15890 Remove text about txes always relayed from -whitelist (harding)

### Miscellaneous
- - #16095 Catch by reference not value in wallettool (kristapsk)
- - #16205 Replace fprintf with tfm::format (MarcoFalke)

[bitcoin-core-dev] Bitcoin Core 0.18.1 released

[Wladimir J. van der Laan via bitcoin-core-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.18.1 is now available from:

  

Or through BitTorrent:


magnet:?xt=urn:btih:c3ba0cfee3ef8413098ac5e81db08a2670e9da8c=bitcoin-core-0.18.1=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969

This is a new minor version release, including new features, various bug
fixes and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

How to Upgrade
==

If you are running an older version, shut it down. Wait until it has
completely shut down (which might take a few minutes for older
versions), then run the installer (on Windows) or just copy over
`/Applications/Bitcoin-Qt` (on Mac) or `bitcoind`/`bitcoin-qt` (on
Linux).

The first time you run version 0.15.0 or newer, your chainstate database
will be converted to a new format, which will take anywhere from a few
minutes to half an hour, depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and
there is no automatic upgrade code from before version 0.8 to version
0.15.0 or later. Upgrading directly from 0.7.x and earlier without
redownloading the blockchain is not supported.  However, as usual, old
wallet versions are still supported.

Compatibility
==

Bitcoin Core is supported and extensively tested on operating systems
using the Linux kernel, macOS 10.10+, and Windows 7 and newer. It is not
recommended to use Bitcoin Core on unsupported systems.

Bitcoin Core should also work on most other Unix-like systems but is not
as frequently tested on them.

- From 0.17.0 onwards, macOS <10.10 is no longer supported. 0.17.0 is
built using Qt 5.9.x, which doesn't support versions of macOS older than
10.10. Additionally, Bitcoin Core does not yet change appearance when
macOS "dark mode" is activated.

Known issues


Wallet GUI
- --

For advanced users who have both (1) enabled coin control features, and
(2) are using multiple wallets loaded at the same time: The coin control
input selection dialog can erroneously retain wrong-wallet state when
switching wallets using the dropdown menu. For now, it is recommended
not to use coin control features with multiple wallets loaded.

0.18.1 change log
=

### P2P protocol and network code
- - #15990 Add tests and documentation for blocksonly (MarcoFalke)
- - #16021 Avoid logging transaction decode errors to stderr (MarcoFalke)
- - #16405 fix: tor: Call `event_base_loopbreak` from the event's callback 
(promag)
- - #16412 Make poll in InterruptibleRecv only filter for POLLIN events 
(tecnovert)

### Wallet
- - #15913 Add -ignorepartialspends to list of ignored wallet options (luke-jr)

### RPC and other APIs
- - #15991 Bugfix: fix pruneblockchain returned prune height (jonasschnelli)
- - #15899 Document iswitness flag and fix bug in converttopsbt (MarcoFalke)
- - #16026 Ensure that uncompressed public keys in a multisig always returns a 
legacy address (achow101)
- - #14039 Disallow extended encoding for non-witness transactions (sipa)
- - #16210 add 2nd arg to signrawtransactionwithkey examples (dooglus)
- - #16250 signrawtransactionwithkey: report error when missing 
redeemScript/witnessScript (ajtowns)

### GUI
- - #16044 fix the bug of OPEN CONFIGURATION FILE on Mac (shannon1916)
- - #15957 Show "No wallets available" in open menu instead of nothing 
(meshcollider)
- - #16118 Enable open wallet menu on setWalletController (promag)
- - #16135 Set progressDialog to nullptr (promag)
- - #16231 Fix open wallet menu initialization order (promag) 
- - #16254 Set `AA_EnableHighDpiScaling` attribute early (hebasto) 
- - #16122 Enable console line edit on setClientModel (promag) 
- - #16348 Assert QMetaObject::invokeMethod result (promag)

### Build system
- - #15985 Add test for GCC bug 90348 (sipa)
- - #15947 Install bitcoin-wallet manpage (domob1812)
- - #15983 build with -fstack-reuse=none (MarcoFalke)

### Tests and QA
- - #15826 Pure python EC (sipa)
- - #15893 Add test for superfluous witness record in deserialization 
(instagibbs)
- - #14818 Bugfix: test/functional/rpc_psbt: Remove check for specific error 
message that depends on uncertain assumptions (luke-jr)
- - #15831 Add test that addmultisigaddress fails for watchonly addresses 
(MarcoFalke)

### Documentation
- - #15890 Remove text about txes always relayed from -whitelist (harding)

### Miscellaneous
- - #16095 Catch by reference not value in wallettool (kristapsk)
- - #16205 Replace fprintf with tfm::format (MarcoFalke)