Good morning Mike,
> > The problem with transaction being pruned is that the data in them might
> now be used in a *future* `OP_PUBREF`.
>
> I can see how pruning is needed for scalability, and pruning can be made
> compatible with a reference to a transaction. If a transaction is pruned,
> t
ZmnSCPxj,
> Lightning uses a "short channel ID" which is basically an index of block
number + index of transaction + index of output to refer to channels.
Oh wow, this is very similar to the PUBREF proposal. In fact the OP_PUBREF4
operation could be modified to take the tuple: (block number, inde
Good morning Mike,
> I think that this implication affects other applications built on the
> blockchain, not just the PubRef proposal:
>
I believe not?
Current applications use txids to refer to previous transactions, so even a
short-ranged history rewrite will mostly not affect them --- they
ZmnSCPxj,
I think that this implication affects other applications built on the
blockchain, not just the PubRef proposal:
> There is a potential for a targeted attack where a large payout going to
a `scriptPubKey` that uses `OP_PUBREF` on a recently-confirmed transaction
finds that recently-con
Good morning Mike,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Sunday, July 28, 2019 4:03 AM, Mike Brooks wrote:
> Hey ZmnSCPxj,
>
> As to your first point. I wasn't aware there was so much volatility at the
> tip, also 100 blocks is quite the difference! I agree
Hey ZmnSCPxj,
As to your first point. I wasn't aware there was so much volatility at the
tip, also 100 blocks is quite the difference! I agree no one could
references a transaction in a newly formed blocks, but I'm curious how this
number was chosen. Do you have any documentation or code that yo
Fungibility is a good question for inductive reasoning. After all, what is
a claim without some rigger?
There exists some set of wallets 'w' which contain a balance of satoshi too
small to recover because it doesn't meet the minimum transaction fee
required to confirm the transaction. These wall
On Fri, Jul 19, 2019, 12:13 William Casarin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hello Mike,
>
> Mike Brooks via bitcoin-dev
> writes:
>
> > Motivation
> >
> > Giving scripts the ability to refer to data on the blockchain will reduce
> > transaction sizes because ke
Hi,
On Fri, 19 Jul 2019 at 17:49, Mike Brooks wrote:
> Users will adopt whatever the client accepts - this feature would be
> transparent.
>
My skepticism was based in an assumption on my part that most such data is
produced by actors with a track record of neglecting transaction
efficiency. I'
Hi,
On Fri, 19 Jul 2019 at 14:00, Mike Brooks via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Giving scripts the ability to refer to data on the blockchain will reduce
> transaction sizes because key material does not have to be repeated in
> every Script.
>
Given that address re
Good morning Mike,
> PubRef is not susceptible to malleability attacks because the blockchain is
> immutable.
This is not quite accurate.
While very old blocks are indeed immutable-in-practice, chain tips are not, and
are often replaced.
At least specify that such data can only be referred to i
Hello Mike,
Mike Brooks via bitcoin-dev
writes:
> Motivation
>
> Giving scripts the ability to refer to data on the blockchain will reduce
> transaction sizes because key material does not have to be repeated in
> every Script. Users of the network are rewarded with smaller transaction
> sizes
I noticed that this Merkle tree we are building is made more expensive by
including repetitive data. So, this proposal draws inspiration from LZ78,
an algorithm which constructs a dictionary of repetitive strings which are
then referred to by their index. What if the blockchain already built a
dic
13 matches
Mail list logo
