Re: [bitcoin-dev] Signature bundles

2018-04-02 Thread Rusty Russell via bitcoin-dev
Anthony Towns via bitcoin-dev writes: > If you've got one bundle that overpays fees and another that underpays, > you can safely combine the two only if you can put a SIGHASH_ALL sig in > the one that overpays (otherwise miners could just make their own tx of > just the overpaying bundle). This i

Re: [bitcoin-dev] Signature bundles

2018-04-02 Thread Anthony Towns via bitcoin-dev
On Tue, Apr 03, 2018 at 09:16:45AM +0930, Rusty Russell via bitcoin-dev wrote: > Proposal: Two bits: SIGHASH_BUNDLESTART/SIGHASH_INBUNDLE > > > A signature needs to indicate that signs only part of a transaction's > inputs and outputs (a.k.a. a "bundle"). Bundles can be combined > togeth

[bitcoin-dev] Low-bandwidth transaction relay

2018-04-02 Thread Gleb Naumenko via bitcoin-dev
Hi all, I have a couple of ideas regarding transaction relay protocol and wanted to share it with and probably get some feedback. I did some emulation and simulation and found out that around 90% of INV messages sent by public-IP nodes are idle (duplicate), obviously because each node creates 8

[bitcoin-dev] Signature bundles

2018-04-02 Thread Rusty Russell via bitcoin-dev
Hi all! Since there's activity on new signature types, I think it's worth considering a more flexible alternative to SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. See Usefulness for why. Proposal: Two bits: SIGHASH_BUNDLESTART/SIGHASH_INBUNDLE A signature needs to indicate that signs on