I don't think this is a realistic concern. The incentive compatibility
_already_ exists (just in reverse: miners are refusing transactions that would
increase their total fees in the next block), and as the mempool is already
generally competitive enough it's actually worse the way it is.
But
ev
><bitcoin-dev@lists.linuxfoundation.org> wrote:
>>On Tue, Jan 23, 2018 at 10:49:34PM +, Gregory Maxwell via bitcoin-dev
>>wrote:
>> > On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev
>> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
1. Bitcoin addresses contain a "checksum", which means it's pretty much
impossible to fat finger any address. (Note: most altcoins don't seem to do
this, so fat-fingering is very much a risk). If you can send to an address, you
can be sure there is no mistake.
However, there is a real risk of
+ Weight_B) < Fee_C / Weight_C
>
> On Tue, Jan 23, 2018 at 11:31 AM, Rhavar via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Getting back on topic:
>>
>>> It would definitely introduce DoS vectors by making it much cheaper to use
>
ely worthwhile)
-Ryan
Original Message
On January 22, 2018 3:00 PM, Peter Todd <p...@petertodd.org> wrote:
> On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:
>
>> So my half-baked idea is very simple:
>> Allow users to merge mult
applies to consumer wallets, who typically have less
than a handful of options. But for a service, avoiding change can be the norm
with good coin selection.
---
-Ryan
Original Message
On January 22, 2018 3:00 PM, Peter Todd <p...@petertodd.org> wrote:
> On Mon, Jan
e old tx with economically equivalent summary
> transactions?
>
> The mempool seems like nature's accumulator for pre-mining compression
> opportunities.
>
> On Mon, Jan 22, 2018 at 1:18 PM, Rhavar via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
ou then.
>
> On Mon, Jan 22, 2018 at 1:40 PM, Rhavar via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> So my half-baked idea is very simple:
>>
>> Allow users to merge multiple unconfirmed transactions, stripping extraneous
>>
So my half-baked idea is very simple:
Allow users to merge multiple unconfirmed transactions, stripping extraneous
inputs and change as they go.
This is currently not possible because of the bip125 rule:
"The replacement transaction pays an absolute fee of at least the sum paid by
the original
I think you're under-appreciating how useful the "plausible deniability".
Someone I know was (solo) traveling to the United States when a border agent
asked her to unlocked her phone; thumbed through her apps, ended up finding
tinder and went through all her recent conversations to make sure
The key to understanding how it works is to stop thinking in terms of a block
size limit, but rather a block weight limit. 1 byte of witness data counts as 1
weight, the rest counts for 4 weight. A block must be less than 4 million
weight. There's no separate limits at all, so any saving in the
I don't have anything interesting to add, except that I have been using 'bits'
on my site for over 3 years. It's a great unit that people quickly adapt to,
and it's far more convenient. When dealing with large amounts of money, people
have no problem naturally thinking in "thousand bits" or
> I understand that there would be technical issues to resolve in
> implementation, but, are there no fundamental errors?
Unfortunately your proposal is really fundamentally broken, on a few levels. I
think you might need to do a bit more research into how bitcoin works before
coming up with
And the receiver is arguably the more important party in this
> question. After all the sender has no real incentive for his payment to
> be confirmed; it"s receiver who has.
> On 07/02/2017 10:35 PM, Rhavar via bitcoin-dev wrote:
>> ==Abstract==
>>
>> BIP125 allo
> Perhaps I am not following what you"re saying here.
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
It actually doesn't really matter much.
Let's say I want to pay Alice and Bob (unrelated
ning off replaceable
> transactions
> Local Time: July 2, 2017 3:56 PM
> UTC Time: July 2, 2017 8:56 PM
> From: g...@xiph.org
> To: Rhavar <rha...@protonmail.com>
> bitcoin-dev@lists.linuxfoundation.org <bitcoin-dev@lists.linuxfoundation.org>
> On Sun, Jul 2, 2
==Abstract==
BIP125 allows transactions to opt into replaceability with a primary use case
of allowing users to increase the fees of unconfirming transactions, helping
create
a more efficient fee market place.
However this goal is hindered when the receiver of a transaction spends from the
17 matches
Mail list logo
