MimbleWimble has the freaky property that transactions and thus blocks
can transform from invalid to valid by the addition of new
transactions and blocks. Depending on how MimbleWimble blocks and
transactions are validated this could cause hardforks in the
blockchain. However if we are careful in h
ey ought to be doing anyway because
> reorging a compacted chain requires redownloading the whole blockchain, super
> slow), this attack would be prohibitively expensive...and not have a big
> payoff.
>
>
> Cheers
> Andrew
>
>
>
> On Wed, Mar 15, 2017 at 04:28:24PM -0400, Ethan
, there is the potential for forks that
>> last
>> for a substantial amount of time. But I think if everybody has their
>> threshold
>> at several thousand blocks (which they ought to be doing anyway because
>> reorging a compacted chain requires redownloading the whol
ck with an out of range (too far in the future) timestamp.
>>>
>>> Because there is no consensus threshold on the depth at which nodes
>>> switch
>>> from full to compact validation, there is the potential for forks that
>>> last
>>> for a su
g!
>
> - Igno
>
>
> Original Message
> Subject: Re: [Mimblewimble] Potentional method of hardforking MimbleWimble
> via freaky invalid to valid block transitions
> Local Time: March 15, 2017 8:01 PM
> UTC Time: March 16, 2017 3:01 AM
> From: j
a
wrote:
> On Wed, Mar 15, 2017 at 06:06:58PM -0400, Ethan Heilman wrote:
>> >I've argued elsewhere that compact validation is not weaker than full
>> >validation, in the sense that it still guarantees the invariants of "no net
>> >inflation or theft".
&
>You can not apply any changes to existing blocks, as that will invalidate
>their PoW.
The changes are not being applied to the block headers. Instead what
is being modified is which transactions are sent with a block. For
instance in Bitcoin if you delete a transaction when sending a block
peopl
Os which he has that I don't.
6. I validate the fork with my new UTXO set and kernels. i.e. I compute
isBalanced( ABCDEFG )?
7. If it passes I adopt the fork.
On Thu, Mar 16, 2017 at 12:36 PM, Andrew Poelstra
wrote:
> On Thu, Mar 16, 2017 at 12:23:45PM -0400, Ethan Heilman wrote:
&
ncluding your local mempool and also
caching recently cut-through transactions so you can undo them
quickly.
On Thu, Mar 16, 2017 at 12:57 PM, Andrew Poelstra
wrote:
> On Thu, Mar 16, 2017 at 12:50:57PM -0400, Ethan Heilman wrote:
>> >The problem with this is that if I've got
efficient if I told you which
UTXO to delete, but that information does not need to be recorded in
the blockchain.
On Thu, Mar 16, 2017 at 1:24 PM, Ethan Heilman
wrote:
>>I like this in principle, but how efficiently is it possible for us to do
> this diffing?
>
> We could probabl
Grin is a blocksnake rather than a blockchain:
It constricts transactions (valueshuffle),
eats them whole,
and then digests them (cut-throughs).
Grins mascot should be a snake in the shape of a G. This would also look
nice on a hat.
On Wed, Nov 15, 2017 at 10:27 AM, Fola Adejumo wrote:
> I made
>Your feedback on the policy and how we can improve it would be extremely
valuable.
Very glad to see this, excellent work. I think Grin will act as an
excellent model for similar projects.
Two ideas I've been thinking about.
1. On the page which advertises what researchers have found which
vulne
>From my perspective Luke's comments are one of the clearest examples of
concern trolling I've yet seen on the internet.
>a systemic law of organisations that all contributions from all
contributors be valued
As anyone who has cooked a meal will agree not all contributions are
welcome. Arsenic do
13 matches
Mail list logo
