Re: [bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys
On Mon, Aug 28, 2017 at 08:55:47PM +, Alex Nagy via bitcoin-dev wrote:
> Thanks Gregory - to be clear should Native P2WPKH scripts only appear in
> redeem scripts? From reading the various BIPs it had seemed like Native
> P2WPKH and Native P2WSH were also valid and identifiable if they were encoded
> in TxOuts. The theoretical use case for this would be saving bytes in Txes
> with many outputs.
It's not a theoretical use-case: the two OpenTimestamps calendar servers I run
- {alice,bob}.btc.calendar.opentimestamps.org - use native P2WPKH segwit
outputs to keep transaction size to the absolute minimum possible; previously
they used bare CHECKSIG output scripts for the same reason.
I enabled support for it the moment segwit activated, so I'm probably the first
ever production user of P2WPKH on mainnet, and quite possibly, the first person
to create P2WPKH outputs on mainnet for any reason.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] "Compressed" headers stream
On Mon, Aug 28, 2017 at 12:26:48PM -0400, Greg Sanders via bitcoin-dev wrote: > Well, if anything my question may bolster your use-case. If there's a > heavier chain that is invalid, I kind of doubt it matters for timestamping > reasons. Timestamping can easily be *more* vulnerable to malicious miners than financial applications for a number of reasons, including the fact that there's no financial feedback loop of miners destroying the value of the coins they produce - timestamping is a non-financial piggy-back application that doesn't directly interact with the Bitcoin economy, beyond a trival number of timestamp transactions. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Fwd: "Compressed" headers stream
On Mon, Aug 28, 2017 at 05:12:15PM +, Gregory Maxwell via bitcoin-dev wrote: > You are leaving a lot of bytes on the table. > > The bits field can only change every 2016 blocks (4 bytes per header), > the timestamp can not be less than the median of the last 11 and is > usually only a small amount over the last one (saves 2 bytes per > header), the block version is usually one of the last few (save 3 > bytes per header). > > But all these things improvements are just a constant factor. I think > you want the compact SPV proofs described in the appendix of the > sidechains whitepaper which creates log scaling proofs. Note that I'm already planning on OpenTimestamps having infrastructure for trusted validity attestations; log scaling proofs alone only prove total work, not validity. Timestamping has all kinds of very dubious security properties when done via proof-of-work, due to various ways that miners can get away with inaccurate block times. In particular, setting a block time backwards is something that miners can do, particularly with majority hashing power, which is the exact thing we're trying to prevent in a timestamp proof. This all makes me dubious about risking further weakening of this already weak security with compact SPV proofs; we'd need a lot more analysis to understand what we're risking. Also note that we can ship a known-good sum-merkle-tree tip hash with the software, which further reduces initial download bandwidth needed to get the block headers on top of this obviously safe eliding of redundant hashes. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
