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
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
> >
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. Luckily
> 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 giv
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
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, and
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 gu
