Good morning Kenshiro,
> >>> I already told you that it is always possible to get around this:
> >>>leverage by use of short options.
> Short the coin to attack, then perform your attack by censorship.
> Coin value will drop due to reduced utility of the coin, then you reap the
> rewards of the
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
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.
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
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
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
>
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
Hi all,
>>> I already told you that it is always possible to get around this: leverage
>>> by use of short options.
Short the coin to attack, then perform your attack by censorship.
Coin value will drop due to reduced utility of the coin, then you reap the
rewards of the short option you
Hi all,
>>>Pools only have short-term power in that they can only temporarily attack
>>>the coin until miners notice and then voluntarily leave.
I agree
>>>GPUs still require electricity to run, and are far easier to source.
Hash change simply means that those with control of energy sources
Hi all,
>>> A 51% attack under proof-of-work is only possible, in general, if some
>>> singular entity were able to have physical control of almost 50%, or some
>>> such close number, of the globe, simply due to the fact that energy
>>> availability is somewhat distributed over the globe.
> On Jul 18, 2019, at 20:45, ZmnSCPxj wrote:
>
> Good morning Kenshiro,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
>> On Thursday, July 18, 2019 11:50 PM, Kenshiro [] wrote:
>>
>> Hi all,
>>
> A 51% attack under proof-of-work is only possible, in
Good morning Kenshiro,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Thursday, July 18, 2019 11:50 PM, Kenshiro [] wrote:
> Hi all,
>
> >>> A 51% attack under proof-of-work is only possible, in general, if some
> >>>singular entity were able to have physical control
12 matches
Mail list logo
