Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

2018-01-27 Thread Russell O'Connor via bitcoin-dev
On Tue, Jan 23, 2018 at 1:44 AM, Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Jan 23, 2018 at 12:30:06AM +, Gregory Maxwell via bitcoin-dev > wrote: > > One point that comes up while talking about merkelized scripts is can > > we go about making

[bitcoin-dev] Proposal: rewarding fees to next block miner

2018-01-27 Thread Nathan Parker via bitcoin-dev
Miners can fill their blocks with transactions paying very high fees at no cost because they get the fees back to themselves. They can do this for different purposes, like trying to increase the recommended fee. Here I propose a backwards-compatible solution to this problem. The solution would be

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

2018-01-27 Thread Matt Corallo via bitcoin-dev
Gah, please no. I see no material reason why cross-input signature aggregation shouldn't have the signatures in the first n-1 inputs replaced with something like a single-byte push where a signature is required to indicate aggregation, and the combined signature in the last input at whatever

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

2018-01-27 Thread Gregory Maxwell via bitcoin-dev
Not incentive compatible. Miners would prefer to include transactions paying fees via alternative mechanisms (anyone can spend outputs, direct pay to miner outputs, or completely out of band), if they even paid attention to internal fees at all they would give a lot more weight to direct payment

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

2018-01-27 Thread Eric Voskuil via bitcoin-dev
The OP premise is flawed: https://github.com/libbitcoin/libbitcoin/wiki/Fee-Recovery-Fallacy as is the idea that side fees are incentive incompatible: https://github.com/libbitcoin/libbitcoin/wiki/Side-Fee-Fallacy e On 01/27/2018 11:06 AM, Gregory Maxwell via bitcoin-dev wrote: > Not