Re: [bitcoin-dev] Low-bandwidth transaction relay

2018-04-04 Thread Gleb Naumenko via bitcoin-dev
Thanks for the links!

Blocksonly is definitely a relevant piece. However, I’m wondering what are the 
implications, especially at larger scale. For example, transactions processing 
will be not smooth anymore and will happen every 10 minutes at once. Another 
question is transaction propagation.

I think what I’ve proposed does not have those implications. Well, propagation 
is still a concern, but it’s not that extreme. One weakness of my idea is 
relative complexity comparing to blocksonly.

Another variation of the idea I described might work without INVs at all  (then 
N=1 and transactions are relayed through 1 link only, during the time between 
blocks) and it would have the same security assumptions as blocksonly.

Your IBLT and BCH-sets proposals sound very promising. I had something like 
that on mind, but I decided to start with a more conservative protocol.
It looks like sync-relay idea has a lot of interesting questions, I’m excited 
to follow that research.

On Apr 3, 2018, 12:04 PM -0700, Gregory Maxwell , wrote:
> On Mon, Apr 2, 2018 at 10:18 PM, Gleb Naumenko via bitcoin-dev
>  wrote:
> > Hi all,
> > I have a couple of ideas regarding transaction relay protocol and wanted to
> > share it with and probably get some feedback.
>
>
>
> https://bitcointalk.org/index.php?topic=1377345.0
>
> https://people.xiph.org/~greg/mempool_sync_relay.txt
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2018-04-04 Thread Karl Johan Alm via bitcoin-dev
I took the liberty of turning this into a BIP proposal -- the
formatted version can be seen here:
https://github.com/kallewoof/bips/blob/bip-typed-wif/bip-extended-privkey.mediawiki


  BIP: XXX
  Layer: Applications
  Title: Typed Private Keys
  Author: Karl-Johan Alm 
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX
  Status: Draft
  Type: Standards Track
  Created: 2018-04-04
  License: CC0-1.0


== Abstract ==

An extension to the private key (WIF) format to specify what kind of
public key the private key corresponds to.

== Motivation ==

There are several types of public keys which can all be associated
with a given private key: P2PKH (legacy 1... format),
P2SH-P2WPKH (SegWit public key inside P2SH), P2WPKH (bech32), etc.

While private keys have a 1-byte suffix indicating whether the
corresponding public key is compressed (0x01) or not
(0x00), there is no way of knowing what kind of public
keys were associated with the private key. As a result, when importing
a private key, the wallet has to assume all kinds, and keep track of
each possible alternative.

By extending the suffix, we can specify what kind of public key was
associated with the given private key.

== Specification ==

Currently, private keys are stored as a uint256 (private key data)
followed by a uint8 (compressed flag). The latter is extended to
specify the public key types:

{|class="wikitable" style="text-align: center;"
|-
!Value
!Type
!Compr
!Clarification
|-
|0x00||P2PKH_UNCOMPRESSED||No||Uncompressed legacy public
key. Unknown public key format
|-
|0x01||P2PKH_COMPRESSED||Yes||Compressed legacy public
key. Unknown public key format
|-
|0x80||P2PKH||Yes||Compressed legacy public key. Legacy
public key format (1...)
|-
|0x81||P2WPKH||Yes||Bech32 format (native Segwit)
|-
|0x82||P2WPKH_P2SH||Yes||Segwit nested in BIP16 P2SH
(3...)
|-
|0x85||P2SH||  ||Non-Segwit BIP16 P2SH (3...)
|-
|0x86||P2WSH||  ||Native Segwit P2SH
|-
|0x87||P2WSH_P2SH||  ||Native Segwit P2SH nested
in BIP16 P2SH
|}

When a wallet imports a private key, it will have two outcomes:

* the key is using one of the legacy types, in which case all types
must be accounted for
* the key is using one of the extended types, in which case the wallet
need only track the specific corresponding public key

== Rationale ==

TODO

== Compatibility ==

This proposal is not backwards compatible, in that software that does
not recognize the new types will not understand the compressed flag.
It would be trivial to change this, by keeping the 'uncompressed'
state as it is (0) and changing 'compressed' to be 'anything not 0',
as opposed to 'the value 1'.

The proposal *is* backwards compatible in that new wallet software
will always understand the old WIF format, however. It will, as it
does today, assume that any kind of public key is possible, and will
have to track all of them, as it has to today.

== Acknowledgements ==

This BIP is based on the initial proposal by Thomas Voegtlin
 on the Bitcoin Dev mailing
listhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015007.html
and the Electrum 3.0
implementationhttps://github.com/spesmilo/electrum/blob/82e88cb89df35288b80dfdbe071da74247351251/RELEASE-NOTES#L95-L108

== Reference implementation ==

There is a partial implementation which adds, but does not use, the
types described in this BIP here:
https://github.com/bitcoin/bitcoin/pull/12869

== References ==



== Copyright ==

This document is licensed under the Creative Commons CC0 1.0 Universal license.

On Mon, Sep 18, 2017 at 12:36 AM, Mark Friedenbach via bitcoin-dev
 wrote:
> Bech32 and WIF payload format are mostly orthogonal issues. You can design a
> new wallet import format now and later switch it to Bech32.
>
> On Sep 17, 2017, at 7:42 AM, AJ West via bitcoin-dev
>  wrote:
>
> Hi I have a small interjection about the point on error correction (excuse
> me if it seems elementary). Isn't there an argument to be made where a
> wallet software should never attempt to figure out the 'correct' address, or
> in this case private key? I don't think it's crazy to suggest somebody could
> import a slightly erroneous WIF, the software gracefully error-corrects any
> problem, but then the user copies that error onward such as in their backup
> processes like a paper wallet. I always hate to advocate against a feature,
> I'm just worried too much error correcting removes the burden of exactitude
> and attention of the user (eg. "I know I can have up to 4 errors").
>
> I'm pretty sure I read those arguments somewhere in a documentation or issue
> tracker/forum post. Maybe I'm misunderstanding the bigger picture in this
> particular case, but I was just reminded of that concept (even if it only
> applies generally).
>
> Thanks,
> AJ West
>
> On Sun, Sep 17, 2017 at 4:10 AM, Thomas