[bitcoin-dev] BIP 177: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks

Damian Williamson willtech at live.com.au
Sun Dec 24 22:20:50 UTC 2017


My mistake, apologies all.


 - I honestly thought everyone just took the next available number and published up their BIP's.


And, I see you have something of a master list.


As a suggestion, would it be worth considering linking to some of that information in the list welcome email? Web search is not always your friend for locating everything relevant.


Regards,

Damian Williamson

________________________________
From: Luke Dashjr <luke at dashjr.org>
Sent: Sunday, 24 December 2017 6:21:24 PM
To: Damian Williamson
Cc: bitcoin-dev at lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 177: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks

BIP 177 is NOT assigned. Do not self-assign BIP numbers!

Please read BIP 2:

    https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki
[https://avatars0.githubusercontent.com/u/528860?s=400&v=4]<https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki>

bips/bip-0002.mediawiki at master · bitcoin/bips · GitHub<https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki>
github.com
Abstract. A Bitcoin Improvement Proposal (BIP) is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its ...



Luke


On Sunday 24 December 2017 2:57:38 AM Damian Williamson via bitcoin-dev wrote:
> BIP 177: UTPFOTIB - Use Transaction Priority For Ordering Transactions In
> Blocks
>
>
> This BIP proposes to address the issue of transactional reliability in
> Bitcoin, where valid transactions may be stuck in the mempool for extended
> periods.
>
>
> There are two key issues to be resolved:
>
>
>   1.  The current transaction bandwidth limit.
>   2.  The current ad-hoc methods of including transactions in blocks
> resulting in variable and confusing confirmation times for valid
> transactions, including transactions with a valid fee that may never
> confirm.
>
>
> It is important with any change to protect the value of fees as these will
> eventually be the only payment that miners receive. Rather than an auction
> model for limited bandwidth, the proposal results in a stable fee for
> priority service auction model.
>
>
> I will post the full proposal up on to my blog in the coming days and,
> re-review incorporating feedback that I have received on and off thread.
> It would not be true to suggest that all feedback received has been
> entirely positive although, most of it has been constructive.
>
>
> The previous threads for this BIP are available here:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/subje
> ct.html
>
>
> Regards,
>
> Damian Williamson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171224/8e260a6c/attachment.html>


More information about the bitcoin-dev mailing list