public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tomas Susanka <tomas.susanka@satoshilabs•com>
To: Achow101 via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 174 thoughts
Date: Mon, 25 Jun 2018 21:47:59 +0200	[thread overview]
Message-ID: <f8f5b1e3-692a-fc1e-2ad3-c4ad4464957f@satoshilabs.com> (raw)
In-Reply-To: <ljk5Z_a3KK6DHfmPJxI8o9W2CkwszkUG34h0i1MTGU4ss8r3BTQ3GnTtDTfWF6J7ZqcSAmejzrr11muWqYN-_wnWw_0NFn5_lggNnjI0_Rc=@achow101.com>

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

Hi,

this is great.

On 23.6.2018 00:28, Achow101 via bitcoin-dev wrote:

> Hi all,
>
> After reading the comments here about BIP 174, I would like to propose the following changes:

From my perspective those are exactly the points I have felt strongly
about. I still think "typed records" would be a better choice, but it's
something I'm willing to compromise on. As I'm looking at the draft, we
currently have 13 records and only 3 of them have keys... Matejcik was a
bit keener on this, so we'll try to discuss this more during the week
and we also look at the draft more carefully to see if we can come up
with some nit-picks.

> - Encoding
>
> I have decided that PSBTs should either be in binary or encoded as a Base64 string. For the latter, several
> Bitcoin clients already support Base64 encoding of data (for signed messages) so this will not add any extra
> dependencies like Z85 would.

I agree. If we're arguing for not using protobuf, because it is a
dependency, we shouldn't add dependency for some lesser-known encoding
format.

As was partially brought up by William, shouldn't we consider using
bech32? It doesn't break on double-click and it is a dependency for
native Segwit addresses anyway, so wallets might already support it or
they will at some point. But we should probably run some numbers on this
first, since bech32 will obviously be larger than base64.


On 24.6.2018 10:28, Andrew Chow via bitcoin-dev wrote:

> I disagree with the idea that global types can be removed. Firstly, it
> is less of a breaking change to leave it there than to remove it
> entirely. Secondly, there may be a point in the future where global
> types would be useful/necessary. By having it still be there, we allow
> for future extensibility.

I agree. It doesn't hurt if the global section stays and it is more
forward-looking.


Best,
Tomas

PS: This email didn't get through at first, so I hope this isn't a repost.


[-- Attachment #2: Type: text/html, Size: 2601 bytes --]

  parent reply	other threads:[~2018-06-25 19:48 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15 23:34 Pieter Wuille
2018-06-16 15:00 ` Peter D. Gray
2018-06-19  9:38 ` Jonas Schnelli
2018-06-19 14:20 ` matejcik
2018-06-19 15:20   ` Jonas Schnelli
2018-06-21 20:28     ` Peter D. Gray
2018-06-19 17:16   ` Pieter Wuille
2018-06-21 11:29     ` matejcik
2018-06-21 17:39       ` Pieter Wuille
2018-06-21 11:44     ` Tomas Susanka
2018-06-19 14:22 ` matejcik
2018-06-21  0:39 ` Achow101
2018-06-21 14:32   ` Tomas Susanka
2018-06-21 15:40     ` Greg Sanders
2018-06-21 19:56     ` Peter D. Gray
2018-06-21 21:39       ` Gregory Maxwell
2018-06-22 19:10       ` Pieter Wuille
2018-06-22 22:28         ` Achow101
2018-06-23 17:00           ` William Casarin
2018-06-23 20:33             ` Andrew Chow
2018-06-24  8:19               ` Andrea
2018-06-24  8:28                 ` Andrew Chow
2018-06-24  9:00                   ` Andrea
2018-06-23 18:27           ` Peter D. Gray
2018-06-25 19:47           ` Tomas Susanka [this message]
2018-06-25 20:10             ` Jonas Schnelli
2018-06-25 20:30             ` Achow101
2018-06-26 15:33               ` matejcik
2018-06-26 16:58                 ` William Casarin
2018-06-26 17:11                   ` Marek Palatinus
2018-06-27 14:11                   ` matejcik
2018-06-26 20:30                 ` Pieter Wuille
2018-06-27 14:04                   ` matejcik
2018-06-27 15:06                     ` Pieter Wuille
2018-06-29  9:53                       ` matejcik
2018-06-29 19:12                         ` Achow101
2018-06-29 20:31                           ` Peter D. Gray
2018-07-04 13:19                           ` matejcik
2018-07-04 18:35                             ` Achow101
2018-07-05 17:23                               ` Jason Les
2018-07-04 19:09                             ` Pieter Wuille
2018-07-05 11:52                               ` matejcik
2018-07-05 22:06                                 ` Pieter Wuille
2018-07-10 12:10                                   ` matejcik
2018-07-11 18:27                                     ` Pieter Wuille
2018-07-11 20:05                                       ` Gregory Maxwell
2018-07-11 20:54                                         ` [bitcoin-dev] BIP 174 thoughts on graphics vv01f
2018-06-26 21:56                 ` [bitcoin-dev] BIP 174 thoughts Achow101
2018-06-27  6:09                   ` William Casarin
2018-06-27 13:39                     ` Andrea
2018-06-27 17:55                     ` Achow101
2018-06-28 20:42                       ` Rodolfo Novak
2018-07-05 19:20                       ` William Casarin
2018-07-06 18:59                         ` Achow101
2018-06-20  0:39 Jason Les

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f8f5b1e3-692a-fc1e-2ad3-c4ad4464957f@satoshilabs.com \
    --to=tomas.susanka@satoshilabs$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox