Hi,
On June 15, 2018 4:34 PM, Pieter Wuille via bitcoin-dev
wrote:
>
> Hello all,
>
> given some recent work and discussions around BIP 174 (Partially
> Signed Bitcoin Transaction Format) I'd like to bring up a few ideas.
> First of all, it's unclear to me to what extent projects have already
Hi all,
After reading the comments here about BIP 174, I would like to propose the
following changes:
- Moving redeemScripts, witnessScripts, and BIP 32 derivation paths to
per-input and per-output data
I think that by moving these three fields into input and output specific maps,
the format
Hi,
On June 25, 2018 12:47 PM, Tomas Susanka via bitcoin-dev
wrote:
> 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
> curre
Hi,
On June 26, 2018 8:33 AM, matejcik via bitcoin-dev
wrote:
>
>
> hello,
>
> in general, I agree with my colleague Tomas, the proposed changes are
>
> good and achieve the most important things that we wanted. We'll review
>
> the proposal in more detail later.
>
> For now a couple mi
Hi,
On June 26, 2018 11:09 PM, William Casarin wrote:
>
>
> Hey Andrew,
>
> If I'm reading the spec right: the way it is designed right now, you
>
> could create hundreds of thousands of zero bytes in the input or output
>
> key-value arrays. As far as I can tell this would be considered
Hi,
I do not think that protobuf is the way to go for this. Not only is it another
dependency
which many wallets do not want to add (e.g. Armory has not added BIP 70 support
because
of its dependency on protobuf), but it is a more drastic change than the
currently proposed
changes. The point of
Hi,
On July 4, 2018 6:19 AM, matejcik wrote:
>
>
> hello,
>
> we still have some concerns about the BIP as currently proposed - not
>
> about the format or data contents, but more about strictness and
>
> security properties. I have raised some in the previous e-mails, but
>
> they mig
Hi,
‐‐‐ Original Message ‐‐‐
On July 5, 2018 12:20 PM, William Casarin wrote:
>
>
> I have another concern with the format. (my original bip comment for some
> context: [1])
>
> It looks like the one of the reasons I was confused is because you can
>
> only parse the format prope
Hi,
Since the BIP is already in proposed status, I think that we should specify the
non-witness utxo to just be "witness or non-witness" serialization. This
maintains compatibility with things that have already implemented but also
maintains the forwards compatibility that is needed.
Andrew
Feel free to re-implement Bitcoin Core in Python. It's open source software and
you can do whatever you want.
However Bitcoin Core is not going move to Python and rewrite everything in
Python. Besides the fact that Python is far less efficient than C/C++,
rewriting Bitcoin Core in any other lan
The seed is encoded as a WIF private key. Decoding as WIF will result in the 32
byte seed that can be used as specified in BIP 32.
Andrew
Original Message
On Apr 5, 2022, 6:55 PM, Tobin Harding via bitcoin-dev wrote:
> Hi,
>
> Does anyone have software that successfully parses
11 matches
Mail list logo
