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

[George Balch via bitcoin-dev]

If miners leave transactions out of a block they do pay a cost by not being
rewarded those fees.  If they include their own spam transactions to get
back the fee they gain nothing.  Since blocks can have fees resulting in
hundreds of thousands of dollars, it would seem unlikely that miners incur
a huge cost for not including transactions.

On Sun, Jan 28, 2018 at 8:54 AM, Lucas Clemente Vella via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If the miner wants to force fees up, why would he fill up a block with
> placeholder high fee transactions, instead of simply cutting off
> transactions paying less fee than he is willing to take? Is there any
> evidence someone is doing such a thing for whatever reason?
>
> 2018-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>:
>
>> 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 to reward the fees of the current block to the
>> miner of the next block (or X blocks after the current one). That way, if a
>> miner floods its own block with very high fee transactions, those fees are
>> no longer given back to itself, but to the miner of future blocks which
>> could potentially be anyone. Flooding blocks with fake txs is now
>> discouraged. However, filling blocks with real transactions paying real
>> fees is still encouraged because you could be the one to mine the block
>> that would claim this reward.
>>
>> The way to implement this in a backwards-compatible fashion would be to
>> enforce miners to set an anyone-can-spend output in the coinbase
>> transaction of the block (by adding this as a rule for verifying new
>> blocks). The miner of 100 blocks after the current one can add a secondary
>> transaction spending this block's anyone-can-spend coinbase transaction
>> (due to the coinbase needing 100 blocks to mature) and thus claiming the
>> funds. This way, the block reward of a block X is always transferred to the
>> miner of block X+100.
>>
>> Implementing this would require a soft-fork. Since that secondary
>> transaction needs no signature whatsoever, the overhead caused by that
>> extra transaction is negligible.
>>
>> Possible Downside: When the fork is activated, the miners won’t get any
>> reward for mining blocks for a period of 100 blocks. They could choose to
>> power off the mining equipment for maintenance or to save power over that
>> period, so the hashrate could drop temporarily. However, if the hashrate
>> drops too much, blocks would take much longer to mine, and miners wouldn’t
>> want that either since they want to go through those 100 reward-less blocks
>> as soon as possible so they can start getting rewards from mining again.
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
> Lucas Clemente Vella
> lve...@gmail.com
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

[CANNON via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Slight correction to email I just posted titled "NIST 8202 Blockchain 
Technology Overview"
The date in top of email states Jan 20, corrected date is Jan 28th which can be 
validated
also by verifying my signature (gpg includes timestamp when signing).

I also sent email with corrected date to NIST comments email address.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJabnPNAAoJEAYDai9lH2mwzywP/Rr5qlkfihE6SkUZrMRp2G1R
jANSEOMgH3yj7UmNKO2Xqzw93ZyNxNIVAL7z2ru2A6D0ziPgMOUKzyTXbDDpqtJR
mvnI0pe50UpDIbpBMx18X6pGw97LlnEYR81UKeEUPJWDzE1auJiuBr+teHMqVA5O
DjGqYVQM/3LEK2yeKfYcTtxBqnHE3jwGnqV7AviHT6KqxmKuLQe18Rs+wNR9wmWO
RYSsp3lD0sIYAC/snZx1c3NrwnB5kbwTbISzYLF5wK6WOcguoUPTFnZ7x1uEHImt
pbDdgDKnkuUusHTGQJEz+0xYjugcYImP12nx73qrUUJBq17g9BdfhdBGlRXabIzu
STRDw3gwnoqfXcJLeJ8/3ICauA8TCkugp8vXXbQ+Gk5G/DXMYokR/DvxmTzWmvky
58vhrKOEFvVz9FBd6OALVbghQFVC8vtqvXB+AoM5bzHASlN+yOpt7wC4EOROla6f
qSusq3xvp3aybui5tmlTOQtvMV4kxxoqA/HFmJ/Wdxm3/oQdGCHw5qrlMtjILuM5
B5l+7UDbIiw6Vvi/ouGP7OekzJkTZo1tYY/95yXfg3I9cjv6wgEaRzHrVjF3o/FP
FQL4GN/Fnjz7E8VQ/w0ttJ+sRyoIMvd16FcRRIC0LzpsczlWuhpBfdxuSry80Loi
gztvxP9+MJVhJ5kZ27BJ
=BxwT
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Voskuil via bitcoin-dev]

Miners accept less than the optimal (i.e. highest net fee) set of
transactions all the time. The reason is that it takes too much time to
compute the optimal set. All other things being equal, the miner who is
more efficient at computing a set is more profitable.

Intentionally not accepting the most optimal set possible is a cost, not
a source of increased returns. Miners can raise the historical fee level
by paying this real cost, just as can any other person (by submitting a
competitive-fee transaction). They cannot "recover" this cost. They have
no place of advantage in terms of competing for block space.

Finally, historical prices do not determine future prices. Current
competition for block space determines future prices.

e

On 01/28/2018 08:54 AM, Lucas Clemente Vella via bitcoin-dev wrote:
> If the miner wants to force fees up, why would he fill up a block with
> placeholder high fee transactions, instead of simply cutting off
> transactions paying less fee than he is willing to take? Is there any
> evidence someone is doing such a thing for whatever reason?
>
> 2018-01-27 6:45 GMT-02:00 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 to reward the fees of the current block to the
> miner of the next block (or X blocks after the current one). That
> way, if a miner floods its own block with very high fee
> transactions, those fees are no longer given back to itself, but to
> the miner of future blocks which could potentially be anyone.
> Flooding blocks with fake txs is now discouraged. However, filling
> blocks with real transactions paying real fees is still encouraged
> because you could be the one to mine the block that would claim this
> reward.
> 
> The way to implement this in a backwards-compatible fashion would be
> to enforce miners to set an anyone-can-spend output in the coinbase
> transaction of the block (by adding this as a rule for verifying new
> blocks). The miner of 100 blocks after the current one can add a
> secondary transaction spending this block's anyone-can-spend
> coinbase transaction (due to the coinbase needing 100 blocks to
> mature) and thus claiming the funds. This way, the block reward of a
> block X is always transferred to the miner of block X+100.
> 
> Implementing this would require a soft-fork. Since that secondary
> transaction needs no signature whatsoever, the overhead caused by
> that extra transaction is negligible.
> 
> Possible Downside: When the fork is activated, the miners won’t get
> any reward for mining blocks for a period of 100 blocks. They could
> choose to power off the mining equipment for maintenance or to save
> power over that period, so the hashrate could drop temporarily.
> However, if the hashrate drops too much, blocks would take much
> longer to mine, and miners wouldn’t want that either since they want
> to go through those 100 reward-less blocks as soon as possible so
> they can start getting rewards from mining again.
> 
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 
> 
> 
> -- 
> Lucas Clemente Vella
> lve...@gmail.com 
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] NIST 8202 Blockchain Technology Overview

[CANNON via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

January 20 2018

(I am also forwarding this message to the bitcoin mailing list just in case 
there
are other technological errors that could use correction in this draft paper or
anything that should be added with my comments.)

To the authors of this paper,
I am commenting on Draft NISTIR 8202 Blockchain Technology Overview located at
https://csrc.nist.gov/CSRC/media/Publications/nistir/8202/draft/documents/nistir8202-draft.pdf

Just in case that document is modified or removed I have also downloaded
it to redistribute this error ridden draft at a later point if neccesary,
and I also had the Internet Archive save a copy here for sake of archival 
reasons
to give context to this message.

https://web.archive.org/web/20180124170359/https://csrc.nist.gov/CSRC/media/Publications/nistir/8202/draft/documents/nistir8202-draft.pdf

There are a couple things I would like to contribute on regarding some
corrections needed in this paper. I must say, the content in this paper is
making me doubt the credibility of the NIST. I am starting to wonder if the
NIST is also incompetent with lack of credibility just like with most other
government institutions. Falsified information published as truth such as this
only expose their ignorance and incompetence and also propagate such ignorance
to other institutions and people whom rely on NIST for information or research.
The information presented in this paper is technologically invalid and contains
false information. I understand that mistakes happen, but this specific section
regarding "8.1.2 Bitcoin Cash (BCC)" is obviously written without prior 
research.
Even if research was done no citation is included to back these claims.
I ask you to please conduct research and validate information before publishing 
it,
especially when the credibility of the NIST is at stake.

I will proceed to outline some corrections.

1. Bitcoin Cash uses the ticker BCH, BCC is the ticker for BitConnectCoin

2. "When SegWit was activated, it caused a hard fork"
This is incorrect information. Segwit was not a hardfork. Rather segwit was
a softfork meaning that it is backwards compatible with unupgraded nodes and
miners. With it being a softfork it actually prevents a fork in the blockchain
by still being valid to unupgraded nodes and miners. Because segregated witness
is not a hardfork its use is optional.

3. "and all the mining nodes and users who did not want to change started
calling the original Bitcoin blockchain Bitcoin Cash (BCC)"
The original bitcoin blockchain is still called Bitcoin. Segwit did not create
any fork in the blockchain. Bitcoin Cash however was a hard fork that resulted
in a forked blockchain and new altcoin.
Bitcoin is Bitcoin,
Bitcoin Cash is Bitcoin Cash.

4. "Technically, Bitcoin is a fork and Bitcoin Cash is the original
blockchain."
Technically, that statement is not truth.

Bitcoin Cash was forked from the original Bitcoin blockchain to create
the altcoin "Bitcoin Cash" (BCH) by people whom believe that the blocksize
should be large enough to accomodate all individual transactions on the main
chain. Without going into any of my personal opinions of which one is better
(bitcoin vs. "bitcoin cash") technically Bitcoin Cash was a hardfork and is
not the original chain but a forked one. It is a hardfork as the blocks
generated by BCH are incompatible with BTC nodes. Because of this lack of
backwards compatibility, and the resulting fork in blockchain is why BCH is
technically a hardfork.

This is just one section of this paper I have read thus far. It makes me
wonder how many other fallacies are throughout this paper. I also wonder how
many other NIST papers exist out of draft form that contain errors. Even
the smallest amount of research could have prevented this in the case of
this paper, unless you are intentionally pushing false information.

I hope these comments are of benefit to the improvement of this paper.

Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 
Email: can...@cannon-ciota.info

NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD 
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJabmySAAoJEAYDai9lH2mwVPcP/ika01NHFMBbxVU9OKc4Ibrd
12MpWW2sgvB14dm8NIuh/xQeFpxGjKvkwWCzqj0pSOE+WClVdK573MJcZF1hqnR4
iPNIr3noR632Hyl9V3Cst5hg5BiUmwETpsyDXG7q7Oj/bX3QAR+psjahk2H2gA6v
i4m1BP4052eRymznJ8aRQc1ak23C4ylLvjC3RRfNmXozG77N4w+tQvFXq45yQam+
nh/8EIck5D9vNTOtVgzgjVqQwfDgUsxgClqHGLNiUOSSievCQLhz1WynDZZSlKmf
Y1Gd70fBpHdrhLBe/SOLglZXPU2BTlicUoN/t9P+5i4qzPfNxfMW9eRi/Urd4sJX
INUuEUMJ2m5EspFjv3rMT19ELts8WhGskBq/4OCT8Wlb9arzhvrDySzLdX5ij75V
DhIX1r3CMDVN4HNb1V4M+Je4Wgle7oh+LS2QDjBnw3IMfjF37j+3OXiRDrlAkE30
GNg0SooANGBvMIMdjnc8fwIV/TxeNh0vEj8M2a4VjbthiDT4L1a4CzxOqT3eWbvB
YHUdz+hwSnydkj5EhyC2e0XN3zqvgSNYoE8HTvKG78ik49bZpxkssEuMWC5N+KM8
j2pgzbVdJXu08mwxrgf2wylUpR630WAEXkcVg3rOw+irPl1U0VxzNL8eNFZehMe6
nuUyXL4VMlApOgesmrCI
=RQoE
-END PGP SIGNATUR

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

[Moral Agent via bitcoin-dev]

As you point out, depending on the mempool, sometimes a miner makes more
fee by including A and B, while other times a miner makes more fee by
including C (the replacement for A and B) and D (a hypothetical transaction
that cannot be fit into a block that contains A and B but can be fit into a
block with C.

So what are we to make of this? Is it better to relay C or better to not
relay C?

Clearly it is better for the miner if they know about C, because knowing
about C costs them nothing, but not knowing about C will sometimes result
in them earning less fees.

Clearly it is better for the people who are creating C for those
transactions to be mined instead of the more expensive A and B transactions.

Everyone else is better off in that more transactions would get included in
blocks.

A concern about burdening full nodes with extra transactions to relay that
may not be more profitable to mine than the transactions they replace is
still rational -- though intuitively it seems like there would be a limit
on how many times an attacker could cheaply reorganize transactions into
something with a higher fee rate.

Perhaps there are also concerns with reconstruction of blocks from compact
blocks, given that miners would have more decisions to make about which tx
to include?



On Sun, Jan 28, 2018 at 12:29 PM, David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Jan 28, 2018 at 05:43:34PM +0100, Sjors Provoost via bitcoin-dev
> wrote:
> > Peter Todd wrote:
> > > In fact I considered only requiring an increase in fee rate, based on
> the
> > > theory that if absolute fee went down, the transaction must be smaller
> and thus
> > > miners could overall earn more from the additional transactions they
> could fit
> > > into their block. But to do that properly requires considering whether
> or not
> > > that's actually true in the particular state the mempool as a whole
> happens to
> > > be in, so I ditched that idea early on for the much simpler criteria
> of both a
> > > feerate and absolute fee increase.
> >
> > Why would you need to consider the whole mempool?
>
> Imagine a miner is only concerned with creating the next block and his
> mempool currently only has 750,000 vbytes in it.  If two 250-vbyte
> transactions each paying a feerate of 100 nanobitcoins per vbyte (50k
> total) are replaced with one 325-vbyte transaction paying a feerate of
> 120 nBTC (39k total), the miner's potential income from mining the next
> block is reduced by 11k nBTC.
>
> Moving away from this easily worked example, the problem can still exist
> even if a miner has enough transactions to fill the next block.  For
> replacement consideration only by increased feerate to be guaranteed
> more profitable, one has to assume the mempool contains an effectively
> continuous distribution of feerates.  That may one day be true of the
> mempool (it would be good, because it helps keep block production
> regular sans subsidy) but it's often not the case these days.
>
> -Dave
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

[Rhavar via bitcoin-dev]

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 I don't think it makes sense to take a zealous approach on "incentive 
compatibility". Bitcoin is already built on a whole bunch of incentive 
incompatible behaviors, even things as simple as "change outputs" (you'd be 
better off privately giving your transaction to trusted miners without change, 
who deduct the min fee they would've needed and refund the rest OOB). Not to 
mention, we expect miners to avoid reorgs and stuff even if it's in their 
short-term interest.

At least personally, I think DoS risks are the real concern.

-Ryan

 Original Message 
On January 28, 2018 12:29 PM, David A. Harding  wrote:

> On Sun, Jan 28, 2018 at 05:43:34PM +0100, Sjors Provoost via bitcoin-dev 
> wrote:
>
>> Peter Todd wrote:
>>
>>> In fact I considered only requiring an increase in fee rate, based on the
>>> theory that if absolute fee went down, the transaction must be smaller and 
>>> thus
>>> miners could overall earn more from the additional transactions they could 
>>> fit
>>> into their block. But to do that properly requires considering whether or 
>>> not
>>> that's actually true in the particular state the mempool as a whole happens 
>>> to
>>> be in, so I ditched that idea early on for the much simpler criteria of 
>>> both a
>>> feerate and absolute fee increase.
>>
>> Why would you need to consider the whole mempool?
>
> Imagine a miner is only concerned with creating the next block and his
> mempool currently only has 750,000 vbytes in it. If two 250-vbyte
> transactions each paying a feerate of 100 nanobitcoins per vbyte (50k
> total) are replaced with one 325-vbyte transaction paying a feerate of
> 120 nBTC (39k total), the miner's potential income from mining the next
> block is reduced by 11k nBTC.
>
> Moving away from this easily worked example, the problem can still exist
> even if a miner has enough transactions to fill the next block. For
> replacement consideration only by increased feerate to be guaranteed
> more profitable, one has to assume the mempool contains an effectively
> continuous distribution of feerates. That may one day be true of the
> mempool (it would be good, because it helps keep block production
> regular sans subsidy) but it's often not the case these days.
>
> -Dave___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

[David A. Harding via bitcoin-dev]

On Sun, Jan 28, 2018 at 05:43:34PM +0100, Sjors Provoost via bitcoin-dev wrote:
> Peter Todd wrote:
> > In fact I considered only requiring an increase in fee rate, based on the
> > theory that if absolute fee went down, the transaction must be smaller and 
> > thus
> > miners could overall earn more from the additional transactions they could 
> > fit
> > into their block. But to do that properly requires considering whether or 
> > not
> > that's actually true in the particular state the mempool as a whole happens 
> > to
> > be in, so I ditched that idea early on for the much simpler criteria of 
> > both a
> > feerate and absolute fee increase.
> 
> Why would you need to consider the whole mempool? 

Imagine a miner is only concerned with creating the next block and his
mempool currently only has 750,000 vbytes in it.  If two 250-vbyte
transactions each paying a feerate of 100 nanobitcoins per vbyte (50k
total) are replaced with one 325-vbyte transaction paying a feerate of
120 nBTC (39k total), the miner's potential income from mining the next
block is reduced by 11k nBTC.

Moving away from this easily worked example, the problem can still exist
even if a miner has enough transactions to fill the next block.  For
replacement consideration only by increased feerate to be guaranteed
more profitable, one has to assume the mempool contains an effectively
continuous distribution of feerates.  That may one day be true of the
mempool (it would be good, because it helps keep block production
regular sans subsidy) but it's often not the case these days.

-Dave


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Lucas Clemente Vella via bitcoin-dev]

If the miner wants to force fees up, why would he fill up a block with
placeholder high fee transactions, instead of simply cutting off
transactions paying less fee than he is willing to take? Is there any
evidence someone is doing such a thing for whatever reason?

2018-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> 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 to reward the fees of the current block to the miner
> of the next block (or X blocks after the current one). That way, if a miner
> floods its own block with very high fee transactions, those fees are no
> longer given back to itself, but to the miner of future blocks which could
> potentially be anyone. Flooding blocks with fake txs is now discouraged.
> However, filling blocks with real transactions paying real fees is still
> encouraged because you could be the one to mine the block that would claim
> this reward.
>
> The way to implement this in a backwards-compatible fashion would be to
> enforce miners to set an anyone-can-spend output in the coinbase
> transaction of the block (by adding this as a rule for verifying new
> blocks). The miner of 100 blocks after the current one can add a secondary
> transaction spending this block's anyone-can-spend coinbase transaction
> (due to the coinbase needing 100 blocks to mature) and thus claiming the
> funds. This way, the block reward of a block X is always transferred to the
> miner of block X+100.
>
> Implementing this would require a soft-fork. Since that secondary
> transaction needs no signature whatsoever, the overhead caused by that
> extra transaction is negligible.
>
> Possible Downside: When the fork is activated, the miners won’t get any
> reward for mining blocks for a period of 100 blocks. They could choose to
> power off the mining equipment for maintenance or to save power over that
> period, so the hashrate could drop temporarily. However, if the hashrate
> drops too much, blocks would take much longer to mine, and miners wouldn’t
> want that either since they want to go through those 100 reward-less blocks
> as soon as possible so they can start getting rewards from mining again.
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
Lucas Clemente Vella
lve...@gmail.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

[Sjors Provoost via bitcoin-dev]

I can see how merging after the fact could be more practical than appending 
existing transactions.

I think what Moral Agent suggested is the same as your original proposal, 
namely dropping rule 3. Only fee per weight unit increase from rule 4 would 
matter.

The minimum per WU increase could be far higher than the minimum relay fee. The 
few times I’ve used RBF in practice I increased the fee by at least 50%. Rule 4 
could be made more strict. I don’t know what number, if any, would address 
concerns about relay spam?

This wouldn’t be backward compatible. Does that matter as long as there’s 
enough nodes that follow the new rules? Is there a punishment for relaying 
transactions that violate rule 3? Could a recipient using the older rules be 
mislead (in a way that’s worse than the fact that RBF allows the sender to 
replace the transaction with anything they want anyway)?

Peter Todd wrote:
> You'd also be able to push others' txs out of the mempool.
Can you elaborate on this issue?

And wrote:
> payment service for instance where a large number of deposits are aggregated 
> into a smaller number of payments

So this would involve wallets (of users who deposit coins) cooperating with an 
exchange API to consolidate in-mempool transactions?

And wrote:

> In fact I considered only requiring an increase in fee rate, based on the
theory that if absolute fee went down, the transaction must be smaller and thus
miners could overall earn more from the additional transactions they could fit
into their block. But to do that properly requires considering whether or not
that's actually true in the particular state the mempool as a whole happens to
be in, so I ditched that idea early on for the much simpler criteria of both a
feerate and absolute fee increase.

Why would you need to consider the whole mempool? Let’s say a miner is 
considering to replace transaction A and B with transaction C, where C pays a 
higher fee per byte than both A and B. This creates space for ~ one additional 
transaction in the block. It seems to me the miner only needs to check that the 
lowest fee per weight transaction > min_fee(A,B). At least in first 
approximation.

Sjors

> Op 24 jan. 2018, om 17:05 heeft Rhavar via bitcoin-dev 
>  het volgende geschreven:
> 
> 
>> I'm confused, the mempool only sees 1 transaction at a time, first A, then 
>> later B. "the original transactions", plural, should not exist in the 
>> mempool.
>> 
>> B's fee and rate needs to be larger than A's, but B will be greater than or 
>> equal to A anyway. So, just increasing the fee rate will cause a larger fee 
>> anyway.
>> 
>> Am I missing something?
> 
> Kind of. The first case is that you do the "smarter" type of merging, where 
> you get an original transaction and then say add an additional output(s) to 
> it.
> 
> The issue with this, is from a practical perspective is _very_ complex. 
> Because you really need to do a lot of tracking to see which of the two 
> transactions actually confirm. And if you are promising fast payments, you 
> can be stuck in a weird limbo state where you're waiting for the original one 
> to "safely" confirm before it's safe to make a re-payment (even a 
> non-malicious will likely contain the replacement).
> 
> bip125 already supports this use-case, but I will suggest that the logic to 
> deploy this is sufficiently complex that no one is going to attempt any time 
> in the near future.
> 
> 
> But "retroactive transaction merging" is actually pretty approachable problem 
> for a service to implement. You just get N valid transactions you've made, 
> merge them into one. Strip extraneous inputs[1], and combine and alter the 
> change amount.
> 
> The reason this is so appealing to implement, is there is very little 
> complexity. If the "retroactive transaction merge" fails, or doesn't get 
> confirmed, it actually has no impact. If it does get confirmed, that's just 
> pure cost-savings.
> 
> However, the rules of bip125 currently make it (unnecessarily?) unappealing, 
> because I can never lower the absolute amount of fees I pay. Hence I think 
> it'd be pretty sweet if they could be relaxed to support this if it can be 
> done in a pretty risk free way.
> 
> 
> 
> [1] Need to be very careful with that, if you're ever merging a merged 
> transaction.
> 
> 
>> 
>> 
>> On Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bitcoin-dev 
>>  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
  wrote:
> Interesting. I didn't think about this before, but it seems like bip125 is
> rather incentive incompatible right now? If we're assuming a competitive
> mempool, it really doesn't seem generally rational to accept a replacement
> transaction of a lower fee rate.
 
 BIP125 replacement requires that the fee rate increases.  The text of
 the BIP document is written in a confusing way that doesn'

[bitcoin-dev] Does Lightning require millisatoshi unit?

[Damian Williamson via bitcoin-dev]

It seems in a document that I was referenced with this very question that the 
unit for creating invoices on Lightning is millisatoshi. Do we really need to 
invoice for 1000 millisatoshi for a 1 sat transaction?


https://github.com/ElementsProject/lightning/blob/master/README.md#sending-and-receiving-payments

[https://avatars2.githubusercontent.com/u/12729539?s=400&v=4]

lightning/README.md at master · ElementsProject/lightning 
...
github.com
c-lightning is a standard compliant implementation of the Lightning Network 
protocol. The Lightning Network is a scalability solution for Bitcoin, enabling 
secure and ...


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev