Hi Varunram,
On Wed, Mar 13, 2019 at 3:41 PM Varunram Ganesh
wrote:
>
> I like your idea of a signet as it would greatly help test reorgs and stuff
> without having to experiment with regtest. But I'm a bit concerned about
> running a common signet (Signet1) controlled by a trusted entity. I
Hi Anthony,
On Wed, Mar 13, 2019 at 12:23 PM Anthony Towns wrote:
>
> Maybe make the signature be an optional addition to the header, so
> that you can have a "light node" that doesn't download/verify sigs
> and a full node that does? (So signatures just sign the traditional
> 80-byte header,
I’ve solved the same problem in a different way.
1) Submit a transaction
2) Collect all reject messages (that have matching txid in the reject data)
3) Wait 16 seconds after first error message received (chosen semirandomly
from trial and error) before processing errors
4) Wait for our txid to be
> I'd like to better understand this, but it would be easier to just
> read the code than ask a bunch of questions. I tried looking for the
> handling of reject messages in Android Bitcoin Wallet and BitcoinJ
> and didn't really find and handling other than logging exceptions.
> Would you mind
On 12/03/2019 23.14, Gregory Maxwell via bitcoin-dev wrote:
> On Tue, Mar 12, 2019 at 7:45 PM Andreas Schildbach via bitcoin-dev
> wrote:
>> These two cases are understood and handled by current code. Generally
>> the idea is take reject messages serious, but don't overrate the lack
>> of.
On Wed, Mar 13, 2019 at 06:41:47AM +, ZmnSCPxj via Lightning-dev wrote:
> > - alternatively, we could require every script to have a valid signature
> > that commits to the input. In that case, you could do eltoo with a
> > script like either:
> > CHECKSIGVERIFY CHECKSIG
> >
Hello Kalle,
I like your idea of a signet as it would greatly help test reorgs and stuff
without having to experiment with regtest. But I'm a bit concerned about
running a common signet (Signet1) controlled by a trusted entity. I guess
if someone wants to test signet on a global scale, they could
Good morning aj,
First off, I have little to no idea of the issues at the lower-level Bitcoin.
In any case ---
> - alternatively, we could require every script to have a valid signature
> that commits to the input. In that case, you could do eltoo with a
> script like either:
>
>
On Fri, Mar 08, 2019 at 03:20:49PM -0500, Matt Corallo via bitcoin-dev wrote:
> To make testing easier, it may make sense to keep the existing block header
> format (and PoW) and instead apply the signature rules to some field in the
> coinbase transaction.
Maybe make the signature be an optional
Hi all,
The following has some more thoughts on trying to make a NOINPUT
implementation as safe as possible for the Bitcoin ecosystem.
One interesting property of NOINPUT usage like in eltoo is that it
actually reintroduces the possibility of third-party malleability to
transactions -- ie, you
Hi Matt,
On Mon, Mar 11, 2019 at 10:23 PM Matt Corallo
wrote:
> I think you may have misunderstood part of the motivation. Yes, part of
> the motivation *is* to remove OP_CODESEPARATOR wholesale, greatly
> simplifying the theoretical operation of checksig operations (thus somewhat
> simplifying
On Tue, Mar 12, 2019 at 6:39 PM Jacob Eliosoff
wrote:
> Also, if future disabling isn't the point of making a tx type like
> OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite
> support of these oddball features, what do we gain by making them hard to
> use/mine?
>
The
Hi Matt,
(I moved your comment to this thread, where I think it is more relevant).
This is a fair point. I concede that as far as Sighash Type Byte is
concerned, the type of change is fairly similar to BIP 68 (though I don't
think the argument applies to OP_CODESEPARATOR).
I might rephrase what
On Wed, Mar 13, 2019 at 12:42 AM Jacob Eliosoff via bitcoin-dev
wrote:
> Also, if future disabling isn't the point of making a tx type like
> OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite
> support of these oddball features, what do we gain by making them hard to
>
14 matches
Mail list logo
