Yes it is allowed in TxOuts. And yes it is designed to save space. But the
problem is Bob can’t assume Alice understands the new TxOuts format. If Bob
really wants to save space this way, he should first ask for a new BIP173
address from Alice. Never try to convert a P2PKH address to a P2SH or B
> On Aug 28, 2017, at 8:29 AM, Alex Nagy via bitcoin-dev
> wrote:
>
> If Alice gives Bob 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a, is there any way Bob
> can safely issue Native P2WPKH outputs to Alice?
>
No, and the whole issue of compressed vs uncompressed is a red herring. If
Alice gives Bob 1
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 T
2017-08-28 19:12 GMT+02:00 Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
>
> 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 (sav
On Mon, Aug 28, 2017 at 3:50 PM, Riccardo Casatta via bitcoin-dev
wrote:
> Hi everyone,
>
> the Bitcoin headers are probably the most condensed and important piece of
> data in the world, their demand is expected to grow.
>
> When sending a stream of continuous block headers, a common case in IBD
On Mon, Aug 28, 2017 at 3:29 PM, Alex Nagy via bitcoin-dev
wrote:
> If Alice gives Bob 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a, is there any way Bob
> can safely issue Native P2WPKH outputs to Alice?
Absolutely not. You can only pay people to a script pubkey that they
have specified.
Trying to constr
2017-08-28 18:13 GMT+02:00 Greg Sanders :
> Is there any reason to believe that you need Bitcoin "full security" at
> all for timestamping?
>
This is a little bit out of the main topic of the email which is the
savings in bandwidth in transmitting headers, any comment about that?
P.S. As a pers
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.
/digression
On Mon, Aug 28, 2017 at 12:25 PM, Riccardo Casatta <
riccardo.casa...@gmail.com> wrote:
>
> 2017-08-28 18:13 GMT+02:00 Greg Sander
Is there any reason to believe that you need Bitcoin "full security" at all
for timestamping?
On Mon, Aug 28, 2017 at 11:50 AM, Riccardo Casatta via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi everyone,
>
> the Bitcoin headers are probably the most condensed and important pie
Hi everyone,
the Bitcoin headers are probably the most condensed and important piece of
data in the world, their demand is expected to grow.
When sending a stream of continuous block headers, a common case in IBD and
in disconnected clients, I think there is a possible optimization of the
transmi
Let's say Alice has a P2PKH address derived from an uncompressed public key,
1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a (from
https://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key).
If Alice gives Bob 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a, is there any way Bob can
safely issue
11 matches
Mail list logo
