Dan Bryant [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-02 to 2020-11-21
💬 Posted a total of 19 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1h0jpmhuc5ufwtzz92ut7erelpzfu2vrfntc2nr97smq27qfckfwsyc9su0

Profile Code

nprofile1qqstheqam7v2wyh93pz4w9lv3uls3y79xp5e4u9f3jlgds90qyutyhgxfcpqw

Author Public Key

npub1h0jpmhuc5ufwtzz92ut7erelpzfu2vrfntc2nr97smq27qfckfwsyc9su0

Show more details

Last Notes

2023-06-07 18:27:32

- reply

📅 Original date posted:2020-11-21
📝 Original message:I've gathered all the source archives from v0.1.0 to v0.9.0 with the
exception of one.
I can't get v0.1.2 anywhere. None of the crawlers from Web Archive seemed
to have captured it. I realize the build was recalled, but I would still
like to examine it purely out of curiosity.
Does anyone know of a mirror or have a personal copy of "bitcoin-0.1.2.rar"
from 2009 / 2010 that they would be willing to share? Even a checksum
would be nice so I could verify what I had if I ever come across it in the
future.
First and last sighting of it on Web Archive:
*
http://web.archive.org/web/20091127010808/http://sourceforge.net/projects/bitcoin/files
*
http://web.archive.org/web/20101210071124/http://sourceforge.net:80/projects/bitcoin/files/Bitcoin/
On Sat, Nov 14, 2020 at 11:41 PM Dan Bryant <dkbryant at gmail.com> wrote:
> I think I'm set now. I should have everything I need from v0.1.0 to
> 0.3.13 when they changed the compiler. I'll refine it a bit more then
> eventually start posting the binary builds on the repo below. I might go
> ahead and disable the IRC bot to ensure people don't inadvertently spam the
> `#bitcoin` IRC. Since I have a patch process worked out it should be
> fairly straight forward. Since the official builds pickup at v0.8.6, I'll
> likely stop there.
>
> https://github.com/brianddk/bitcoin-archaeology
>
>
> On Sat, Nov 14, 2020 at 11:00 AM Dan Bryant <dkbryant at gmail.com> wrote:
>
>> Finally got it working,but was a bit harder than I expected. I had to
>> forgo the OpenSSL modifications that Satoshi originally suggested. I also
>> switched to Strawberry Perl. Those two changes seemed to fix the OpenSSL
>> build. Everything else was all essentially as documented in v0.4.0, which
>> is the first version to put all the build steps out in detail. The one
>> exception is the bitcoin build itself. There are three minor issues that
>> can be worked around with copy commands.
>>
>> 1. The Makefile points to /wxWidgets/lib/vc_lib/ where it should really
>> point to /wxWidgets/lib/gcc_lib/
>> 2. The Makefile points to /OpenSSL/include where it should really point
>> to /OpenSSL/outinc
>> 3. The Makefile builds to /obj without first creating the directory
>>
>> That covers v0.1.5, and I think it will probably be smooth sailing from
>> there all the way to v0.4.0. I'll verify that my v0.1.5 toolchain can
>> build v0.1.0 and v0.1.3 as well. For anyone interested, here are the
>> binaries I used to create the build environment. All of them are
>> vintage and would have been accessible to Satoshi with the exception of
>> Win2012 and VirtualBox. I'll try to reproduce my work on a Win2000 which
>> is now quasi-open-domain.
>>
>> For anyone wanting to give it a shot...
>>
>> * https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-server-2012
>> *
>> https://download.virtualbox.org/virtualbox/6.1.12/VirtualBox-6.1.12-139181-Win.exe
>> * https://downloads.sourceforge.net/gnuwin32/zlib-1.2.3-bin.zip
>> * https://downloads.sourceforge.net/gnuwin32/bzip2-1.0.5-bin.zip
>> * https://downloads.sourceforge.net/gnuwin32/libarchive-2.4.12-1-bin.zip
>> *
>> https://downloads.sourceforge.net/mingw/binutils-2.19.1-mingw32-bin.tar.gz
>> *
>> https://downloads.sourceforge.net/mingw/gcc-core-3.4.5-20051220-1.tar.gz
>> * https://downloads.sourceforge.net/mingw/gcc-g++-3.4.5-20051220-1.tar.gz
>> *
>> https://downloads.sourceforge.net/mingw/mingwrt-3.15.2-mingw32-dev.tar.gz
>> *
>> https://downloads.sourceforge.net/mingw/mingwrt-3.15.2-mingw32-dll.tar.gz
>> * https://downloads.sourceforge.net/mingw/w32api-3.13-mingw32-dev.tar.gz
>> *
>> https://downloads.sourceforge.net/mingw/mingw32-make-3.81-20080326-2.tar.gz
>> * https://downloads.sourceforge.net/mingw/MSYS-1.0.11.exe
>> * https://downloads.sourceforge.net/mingw/msysDTK-1.0.1.exe
>> * http://strawberryperl.com/download/5.8.8/strawberry-perl-5.8.8.2.zip
>> * https://github.com/bitcoin/bitcoin/archive/v0.1.5.zip
>> * https://downloads.sourceforge.net/wxwindows/wxWidgets-2.8.11.zip
>> * https://github.com/openssl/openssl/archive/OpenSSL_0_9_8h.zip
>> * https://download.oracle.com/berkeley-db/db-4.7.25.NC.zip
>> * https://downloads.sourceforge.net/boost/1.37.0/boost_1_37_0.zip
>> *
>> https://downloads.sourceforge.net/boost/boost-jam/boost-jam-3.1.17-1-ntx86.zip
>>
>>
>> On Wed, Nov 11, 2020 at 9:06 AM Dan Bryant <dkbryant at gmail.com> wrote:
>>
>>> TLDR; How to build old OpenSSL releases in MSYS/MinGW v1.0.11
>>>
>>> In a similar vein to the Github Artic Code Vault, and the Nakamoto
>>> Institute, I thought it would be educational to do a build of the first
>>> three versions of Bitcoin (v0.1.0, v0.1.3, and v0.1.5) [ref1]. Don't
>>> worry, I will keep these on a VLAN and not spam the IRC channel.
>>>
>>> Wanting to be as accurate as possible, I spun up some VMs to try to
>>> recreate the vintage Oct 2009 toolchains that were used. The original
>>> Satoshi posts seem to imply that the builds could be done using Visual C++
>>> version 6.0 or MinGW and MSYS (which were at v1.0.11). Since it looks like
>>> most versions of VC 6 have been purged from the internet, the only option
>>> left is MinGW which is still up on sourceforge. Most things seemed to
>>> build OK, with the exception of OpenSSL, which looks to fail due to some
>>> issues in mk1mf.pl [ref2] Perhaps there was a bad version of perl in
>>> MSYS v1.0.11, I'm not sure.
>>>
>>> So my question is.. Has anyone been here long enough to recall the
>>> steps to build OpenSSL v0.9.8h in MSYS 1.0.11? Or, does anyone know where
>>> to find a non-sketchy copy of Visual C++ 6.0?
>>>
>>> My options so far seem to be.
>>>
>>> 1. Try to find out how Satoshi did the MinGW OpenSSL build back in 2009.
>>> 2. Try to do the OpenSSL build through Cygwin which could
>>> cross-complile to MinGW at the time
>>> 3. Try to do the OpenSSL build through Msys2 with later versions of
>>> perl and libc
>>> 4. Buy some sketchy version of VC 6 on ebay and try that
>>> 5. Patch Bitcoin 0.1.0 to use OpenSSL v1.0.0 where they fixed the perl
>>> bug
>>> 6. Give up and use a precompiled OpenSSL release
>>> 7. Give up and use the Linux build methods introduced in Bitcoin v0.1.6
>>>
>>> I realize this all sounds like a fool's folly, but it seems important
>>> (at some level) to be able to reproduce these old builds. But perhaps it's
>>> just my OCD.
>>>
>>> Thoughts?
>>>
>>> For those interested. The mk1mf.pl bug seems to be in parsing the list
>>> of headers through either the var_add, clean_up_ws, or do_copy_rule subs.
>>> I see both the headers and header directories being parsed, but the
>>> directories are dropped when building the make rules causing make to assume
>>> all headers are at root, failing the build. Perhaps there is a version
>>> sed, basename or dirname that is missing in MSYS, but I've failed to find
>>> the dependency yet.
>>>
>>> * ref1: https://satoshi.nakamotoinstitute.org/code/
>>> * ref1:
>>> https://github.com/openssl/openssl/blob/OpenSSL_0_9_8h/util/mk1mf.pl
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201121/40fc4057/attachment.html>

2023-06-07 18:27:31

- reply

📅 Original date posted:2020-11-15
📝 Original message:I think I'm set now. I should have everything I need from v0.1.0 to 0.3.13
when they changed the compiler. I'll refine it a bit more then eventually
start posting the binary builds on the repo below. I might go ahead and
disable the IRC bot to ensure people don't inadvertently spam the
`#bitcoin` IRC. Since I have a patch process worked out it should be
fairly straight forward. Since the official builds pickup at v0.8.6, I'll
likely stop there.
https://github.com/brianddk/bitcoin-archaeology
On Sat, Nov 14, 2020 at 11:00 AM Dan Bryant <dkbryant at gmail.com> wrote:
> Finally got it working,but was a bit harder than I expected. I had to
> forgo the OpenSSL modifications that Satoshi originally suggested. I also
> switched to Strawberry Perl. Those two changes seemed to fix the OpenSSL
> build. Everything else was all essentially as documented in v0.4.0, which
> is the first version to put all the build steps out in detail. The one
> exception is the bitcoin build itself. There are three minor issues that
> can be worked around with copy commands.
>
> 1. The Makefile points to /wxWidgets/lib/vc_lib/ where it should really
> point to /wxWidgets/lib/gcc_lib/
> 2. The Makefile points to /OpenSSL/include where it should really point to
> /OpenSSL/outinc
> 3. The Makefile builds to /obj without first creating the directory
>
> That covers v0.1.5, and I think it will probably be smooth sailing from
> there all the way to v0.4.0. I'll verify that my v0.1.5 toolchain can
> build v0.1.0 and v0.1.3 as well. For anyone interested, here are the
> binaries I used to create the build environment. All of them are
> vintage and would have been accessible to Satoshi with the exception of
> Win2012 and VirtualBox. I'll try to reproduce my work on a Win2000 which
> is now quasi-open-domain.
>
> For anyone wanting to give it a shot...
>
> * https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-server-2012
> *
> https://download.virtualbox.org/virtualbox/6.1.12/VirtualBox-6.1.12-139181-Win.exe
> * https://downloads.sourceforge.net/gnuwin32/zlib-1.2.3-bin.zip
> * https://downloads.sourceforge.net/gnuwin32/bzip2-1.0.5-bin.zip
> * https://downloads.sourceforge.net/gnuwin32/libarchive-2.4.12-1-bin.zip
> *
> https://downloads.sourceforge.net/mingw/binutils-2.19.1-mingw32-bin.tar.gz
> * https://downloads.sourceforge.net/mingw/gcc-core-3.4.5-20051220-1.tar.gz
> * https://downloads.sourceforge.net/mingw/gcc-g++-3.4.5-20051220-1.tar.gz
> *
> https://downloads.sourceforge.net/mingw/mingwrt-3.15.2-mingw32-dev.tar.gz
> *
> https://downloads.sourceforge.net/mingw/mingwrt-3.15.2-mingw32-dll.tar.gz
> * https://downloads.sourceforge.net/mingw/w32api-3.13-mingw32-dev.tar.gz
> *
> https://downloads.sourceforge.net/mingw/mingw32-make-3.81-20080326-2.tar.gz
> * https://downloads.sourceforge.net/mingw/MSYS-1.0.11.exe
> * https://downloads.sourceforge.net/mingw/msysDTK-1.0.1.exe
> * http://strawberryperl.com/download/5.8.8/strawberry-perl-5.8.8.2.zip
> * https://github.com/bitcoin/bitcoin/archive/v0.1.5.zip
> * https://downloads.sourceforge.net/wxwindows/wxWidgets-2.8.11.zip
> * https://github.com/openssl/openssl/archive/OpenSSL_0_9_8h.zip
> * https://download.oracle.com/berkeley-db/db-4.7.25.NC.zip
> * https://downloads.sourceforge.net/boost/1.37.0/boost_1_37_0.zip
> *
> https://downloads.sourceforge.net/boost/boost-jam/boost-jam-3.1.17-1-ntx86.zip
>
>
> On Wed, Nov 11, 2020 at 9:06 AM Dan Bryant <dkbryant at gmail.com> wrote:
>
>> TLDR; How to build old OpenSSL releases in MSYS/MinGW v1.0.11
>>
>> In a similar vein to the Github Artic Code Vault, and the Nakamoto
>> Institute, I thought it would be educational to do a build of the first
>> three versions of Bitcoin (v0.1.0, v0.1.3, and v0.1.5) [ref1]. Don't
>> worry, I will keep these on a VLAN and not spam the IRC channel.
>>
>> Wanting to be as accurate as possible, I spun up some VMs to try to
>> recreate the vintage Oct 2009 toolchains that were used. The original
>> Satoshi posts seem to imply that the builds could be done using Visual C++
>> version 6.0 or MinGW and MSYS (which were at v1.0.11). Since it looks like
>> most versions of VC 6 have been purged from the internet, the only option
>> left is MinGW which is still up on sourceforge. Most things seemed to
>> build OK, with the exception of OpenSSL, which looks to fail due to some
>> issues in mk1mf.pl [ref2] Perhaps there was a bad version of perl in
>> MSYS v1.0.11, I'm not sure.
>>
>> So my question is.. Has anyone been here long enough to recall the steps
>> to build OpenSSL v0.9.8h in MSYS 1.0.11? Or, does anyone know where to
>> find a non-sketchy copy of Visual C++ 6.0?
>>
>> My options so far seem to be.
>>
>> 1. Try to find out how Satoshi did the MinGW OpenSSL build back in 2009.
>> 2. Try to do the OpenSSL build through Cygwin which could
>> cross-complile to MinGW at the time
>> 3. Try to do the OpenSSL build through Msys2 with later versions of perl
>> and libc
>> 4. Buy some sketchy version of VC 6 on ebay and try that
>> 5. Patch Bitcoin 0.1.0 to use OpenSSL v1.0.0 where they fixed the perl bug
>> 6. Give up and use a precompiled OpenSSL release
>> 7. Give up and use the Linux build methods introduced in Bitcoin v0.1.6
>>
>> I realize this all sounds like a fool's folly, but it seems important (at
>> some level) to be able to reproduce these old builds. But perhaps it's
>> just my OCD.
>>
>> Thoughts?
>>
>> For those interested. The mk1mf.pl bug seems to be in parsing the list
>> of headers through either the var_add, clean_up_ws, or do_copy_rule subs.
>> I see both the headers and header directories being parsed, but the
>> directories are dropped when building the make rules causing make to assume
>> all headers are at root, failing the build. Perhaps there is a version
>> sed, basename or dirname that is missing in MSYS, but I've failed to find
>> the dependency yet.
>>
>> * ref1: https://satoshi.nakamotoinstitute.org/code/
>> * ref1:
>> https://github.com/openssl/openssl/blob/OpenSSL_0_9_8h/util/mk1mf.pl
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201114/33a421d0/attachment-0001.html>

2023-06-07 18:27:31

- reply

📅 Original date posted:2020-11-14
📝 Original message:Finally got it working,but was a bit harder than I expected. I had to
forgo the OpenSSL modifications that Satoshi originally suggested. I also
switched to Strawberry Perl. Those two changes seemed to fix the OpenSSL
build. Everything else was all essentially as documented in v0.4.0, which
is the first version to put all the build steps out in detail. The one
exception is the bitcoin build itself. There are three minor issues that
can be worked around with copy commands.
1. The Makefile points to /wxWidgets/lib/vc_lib/ where it should really
point to /wxWidgets/lib/gcc_lib/
2. The Makefile points to /OpenSSL/include where it should really point to
/OpenSSL/outinc
3. The Makefile builds to /obj without first creating the directory
That covers v0.1.5, and I think it will probably be smooth sailing from
there all the way to v0.4.0. I'll verify that my v0.1.5 toolchain can
build v0.1.0 and v0.1.3 as well. For anyone interested, here are the
binaries I used to create the build environment. All of them are
vintage and would have been accessible to Satoshi with the exception of
Win2012 and VirtualBox. I'll try to reproduce my work on a Win2000 which
is now quasi-open-domain.
For anyone wanting to give it a shot...
* https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-server-2012
*
https://download.virtualbox.org/virtualbox/6.1.12/VirtualBox-6.1.12-139181-Win.exe
* https://downloads.sourceforge.net/gnuwin32/zlib-1.2.3-bin.zip
* https://downloads.sourceforge.net/gnuwin32/bzip2-1.0.5-bin.zip
* https://downloads.sourceforge.net/gnuwin32/libarchive-2.4.12-1-bin.zip
* https://downloads.sourceforge.net/mingw/binutils-2.19.1-mingw32-bin.tar.gz
* https://downloads.sourceforge.net/mingw/gcc-core-3.4.5-20051220-1.tar.gz
* https://downloads.sourceforge.net/mingw/gcc-g++-3.4.5-20051220-1.tar.gz
* https://downloads.sourceforge.net/mingw/mingwrt-3.15.2-mingw32-dev.tar.gz
* https://downloads.sourceforge.net/mingw/mingwrt-3.15.2-mingw32-dll.tar.gz
* https://downloads.sourceforge.net/mingw/w32api-3.13-mingw32-dev.tar.gz
*
https://downloads.sourceforge.net/mingw/mingw32-make-3.81-20080326-2.tar.gz
* https://downloads.sourceforge.net/mingw/MSYS-1.0.11.exe
* https://downloads.sourceforge.net/mingw/msysDTK-1.0.1.exe
* http://strawberryperl.com/download/5.8.8/strawberry-perl-5.8.8.2.zip
* https://github.com/bitcoin/bitcoin/archive/v0.1.5.zip
* https://downloads.sourceforge.net/wxwindows/wxWidgets-2.8.11.zip
* https://github.com/openssl/openssl/archive/OpenSSL_0_9_8h.zip
* https://download.oracle.com/berkeley-db/db-4.7.25.NC.zip
* https://downloads.sourceforge.net/boost/1.37.0/boost_1_37_0.zip
*
https://downloads.sourceforge.net/boost/boost-jam/boost-jam-3.1.17-1-ntx86.zip
On Wed, Nov 11, 2020 at 9:06 AM Dan Bryant <dkbryant at gmail.com> wrote:
> TLDR; How to build old OpenSSL releases in MSYS/MinGW v1.0.11
>
> In a similar vein to the Github Artic Code Vault, and the Nakamoto
> Institute, I thought it would be educational to do a build of the first
> three versions of Bitcoin (v0.1.0, v0.1.3, and v0.1.5) [ref1]. Don't
> worry, I will keep these on a VLAN and not spam the IRC channel.
>
> Wanting to be as accurate as possible, I spun up some VMs to try to
> recreate the vintage Oct 2009 toolchains that were used. The original
> Satoshi posts seem to imply that the builds could be done using Visual C++
> version 6.0 or MinGW and MSYS (which were at v1.0.11). Since it looks like
> most versions of VC 6 have been purged from the internet, the only option
> left is MinGW which is still up on sourceforge. Most things seemed to
> build OK, with the exception of OpenSSL, which looks to fail due to some
> issues in mk1mf.pl [ref2] Perhaps there was a bad version of perl in
> MSYS v1.0.11, I'm not sure.
>
> So my question is.. Has anyone been here long enough to recall the steps
> to build OpenSSL v0.9.8h in MSYS 1.0.11? Or, does anyone know where to
> find a non-sketchy copy of Visual C++ 6.0?
>
> My options so far seem to be.
>
> 1. Try to find out how Satoshi did the MinGW OpenSSL build back in 2009.
> 2. Try to do the OpenSSL build through Cygwin which could
> cross-complile to MinGW at the time
> 3. Try to do the OpenSSL build through Msys2 with later versions of perl
> and libc
> 4. Buy some sketchy version of VC 6 on ebay and try that
> 5. Patch Bitcoin 0.1.0 to use OpenSSL v1.0.0 where they fixed the perl bug
> 6. Give up and use a precompiled OpenSSL release
> 7. Give up and use the Linux build methods introduced in Bitcoin v0.1.6
>
> I realize this all sounds like a fool's folly, but it seems important (at
> some level) to be able to reproduce these old builds. But perhaps it's
> just my OCD.
>
> Thoughts?
>
> For those interested. The mk1mf.pl bug seems to be in parsing the list
> of headers through either the var_add, clean_up_ws, or do_copy_rule subs.
> I see both the headers and header directories being parsed, but the
> directories are dropped when building the make rules causing make to assume
> all headers are at root, failing the build. Perhaps there is a version
> sed, basename or dirname that is missing in MSYS, but I've failed to find
> the dependency yet.
>
> * ref1: https://satoshi.nakamotoinstitute.org/code/
> * ref1:
> https://github.com/openssl/openssl/blob/OpenSSL_0_9_8h/util/mk1mf.pl
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201114/41d8e903/attachment.html>

2023-06-07 18:27:30

- reply

📅 Original date posted:2020-11-11
📝 Original message:TLDR; How to build old OpenSSL releases in MSYS/MinGW v1.0.11
In a similar vein to the Github Artic Code Vault, and the Nakamoto
Institute, I thought it would be educational to do a build of the first
three versions of Bitcoin (v0.1.0, v0.1.3, and v0.1.5) [ref1]. Don't
worry, I will keep these on a VLAN and not spam the IRC channel.
Wanting to be as accurate as possible, I spun up some VMs to try to
recreate the vintage Oct 2009 toolchains that were used. The original
Satoshi posts seem to imply that the builds could be done using Visual C++
version 6.0 or MinGW and MSYS (which were at v1.0.11). Since it looks like
most versions of VC 6 have been purged from the internet, the only option
left is MinGW which is still up on sourceforge. Most things seemed to
build OK, with the exception of OpenSSL, which looks to fail due to some
issues in mk1mf.pl [ref2] Perhaps there was a bad version of perl in MSYS
v1.0.11, I'm not sure.
So my question is.. Has anyone been here long enough to recall the steps
to build OpenSSL v0.9.8h in MSYS 1.0.11? Or, does anyone know where to
find a non-sketchy copy of Visual C++ 6.0?
My options so far seem to be.
1. Try to find out how Satoshi did the MinGW OpenSSL build back in 2009.
2. Try to do the OpenSSL build through Cygwin which could cross-complile to
MinGW at the time
3. Try to do the OpenSSL build through Msys2 with later versions of perl
and libc
4. Buy some sketchy version of VC 6 on ebay and try that
5. Patch Bitcoin 0.1.0 to use OpenSSL v1.0.0 where they fixed the perl bug
6. Give up and use a precompiled OpenSSL release
7. Give up and use the Linux build methods introduced in Bitcoin v0.1.6
I realize this all sounds like a fool's folly, but it seems important (at
some level) to be able to reproduce these old builds. But perhaps it's
just my OCD.
Thoughts?
For those interested. The mk1mf.pl bug seems to be in parsing the list of
headers through either the var_add, clean_up_ws, or do_copy_rule subs. I
see both the headers and header directories being parsed, but the
directories are dropped when building the make rules causing make to assume
all headers are at root, failing the build. Perhaps there is a version
sed, basename or dirname that is missing in MSYS, but I've failed to find
the dependency yet.
* ref1: https://satoshi.nakamotoinstitute.org/code/
* ref1: https://github.com/openssl/openssl/blob/OpenSSL_0_9_8h/util/mk1mf.pl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201111/bfd33ca1/attachment.html>

2023-06-07 18:26:36

- reply

📅 Original date posted:2020-08-21
📝 Original message:It's been 5 years since minrealytxfee was lowered. At the time
bitcoin was trading for $255 and it was agreed that the fee of 5000
sat/vkB was too high. It was lowered to 1000 sat/vkB. In regards to
how much anti-DoS protection that provided, it comes out to $0.00255 /
vkB in USD terms. To have parity with the last reduction, we would
need to reduce minrealytxfee to 22 sat/vKB, though an even more
conservative reduction to 100 or 50 sat/vKB would be welcome.
With the growing adoption of LN, there is a need for ultra-low-fee
on-chain TXNs. Having these queue and confirm overnight, or even
waiting until the Sunday lull would still probably be welcome to many
users. The fact that the mempool is going empty at least every week
indicates that miners have not reached the floor of what they are
willing to mine.
About 2 years ago there was a PR (#13922) to try to make a reduction
from 1000 to 200 sat/vkB. It was widely accepted but the submitter
eventually closed it in favor of PR #13990.
If minrelaytxfee is already parameterized and configurable in
bitcoin.conf, how could it be detrimental to operation of a node to
change the default?
References:
* https://github.com/bitcoin/bitcoin/commit/9e93640be6c49fa1505ba5c5df8c89210da5a6e4
* https://github.com/bitcoin/bitcoin/pull/13922
* https://github.com/bitcoin/bitcoin/pull/13990

2023-06-07 18:09:05

- reply

📅 Original date posted:2017-12-28
📝 Original message:I was considering starting a BIP, but wanted to ask the thread if anything
like this was already done or in the works. My proposal is to expand the
TXN format to include chain-height (block number) in the TXN. This would
allow nodes / miners to age the TXN and choose (optionally) not to
rebroadcast it after a certain age threshold. Currently (as I understand
it), nodes and miners keep effectively a "seen-list" of TXNs and age them
based upon when they were last seen. This is very effective as it reduces
TXN size and frees the TXN from having to declare its age. The downside to
this is that those TXNs could be broadcast forever, assuming (big assume)
that the UTXO never got spent.
The goal here is not to enhance the protocol... if anything this would
increase TXN cost as it would add a few bytes to it. The goal here is to
make it easier for users to know with better certainty when an TXN is going
to age out. Obviously RBF is a better solution, but there may be some
instances when a user wants to effectively cancel a TXN.
Possible abuse vectors might include:
* Bad party broadcasting a low fee TXN at the edge of the age-out threshold
and trying to get goods, realizing the TXN will age out at the very next
block.
If this proposal might be something that core would entertain in a BIP
proposal I'll start drafting something. If there are suggestions about
where to place the block number to have minimal impact and ensure backward
compatibility, that would be great to. If this is simply silly and should
not be entertained, no harm there either.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171228/8dd7f6b2/attachment.html>

2023-06-07 18:09:01

- reply

📅 Original date posted:2017-12-21
📝 Original message:Thank you... I've updated.
> New schemes should probably NOT be based on the current one.
Fair enough... I still think there are those who would still like an
existing sign/verify BIP to reference.
On Thu, Dec 21, 2017 at 5:09 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Thursday 21 December 2017 10:26:25 PM Dan Bryant via bitcoin-dev wrote:
> > https://github.com/brianddk/bips/blob/legacysignverify/
> bip-0xyz.mediawiki
>
> It's not even correct... Your first "verify message" step is not possible;
> you
> can't get a public key from an address.
>
> What is actually done, is using the signature + message to perform key
> recovery, to extract the public key of the signer, and then hashing that
> and
> comparing it to the address provided.
>
> > Although this is a well established functionality, it has never been
> > published in a BIP. My proposal is simply to provide a reference point
> for
> > future expansion of these capabilities into new address schemes.
>
> New schemes should probably NOT be based on the current one.
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171221/9543aa61/attachment-0001.html>

2023-06-07 18:09:00

- reply

📅 Original date posted:2017-12-21
📝 Original message:https://github.com/brianddk/bips/blob/legacysignverify/bip-0xyz.mediawiki
Although this is a well established functionality, it has never been
published in a BIP. My proposal is simply to provide a reference point for
future expansion of these capabilities into new address schemes.
Original reference thread [Sign / Verify message against SegWit P2SH
addresses]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171221/1407a823/attachment.html>

2023-06-07 18:08:35

- reply

📅 Original date posted:2017-12-21
📝 Original message:legacy message sign verify BIP to get the ball rolling.
early draft:
https://github.com/brianddk/bips/blob/legacysignverify/bip-0xyz.mediawiki
On Tue, Dec 19, 2017 at 3:36 PM, Pavol Rusnak <stick at satoshilabs.com> wrote:
> On 08/12/17 19:25, Dan Bryant via bitcoin-dev wrote:
> > I know there are posts, and an issue opened against it, but is there
> > anyone writing a BIP for Sign / Verify message against a SegWit address?
>
> Dan, are you still planning to write this BIP?
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171221/ce3abe15/attachment-0001.html>

2023-06-07 18:08:33

- reply

📅 Original date posted:2017-12-08
📝 Original message:I know there are posts, and an issue opened against it, but is there anyone
writing a BIP for Sign / Verify message against a SegWit address?
I realize it is not a feature in wide use, but I think it still serves an
important purpose, such as when proof of assets are requested.
ref: https://github.com/bitcoin/bitcoin/issues/10542
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171208/3315b91a/attachment.html>

2023-06-07 18:07:50

- reply

📅 Original date posted:2017-11-20
📝 Original message:Is there any incentive for miners to pick segwit transactions over
non-segwit transaction. Do they require less, equal, or more compute to
process?
On Nov 20, 2017 11:46 AM, "Johnson Lau via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
We can’t “just compute the Transaction ID the same way the hash for signing
the transaction is computed” because with different SIGHASH flags, there
are 6 (actually 256) ways to hash a transaction.
Also, changing the definition of TxID is a hardfork change, i.e. everyone
are required to upgrade or a chain split will happen.
It is possible to use “normalised TxID” (BIP140) to fix malleability issue.
As a softfork, BIP140 doesn’t change the definition of TxID. Instead, the
normalised txid (i.e. txid with scriptSig removed) is used when making
signature. Comparing with segwit (BIP141), BIP140 does not have the
side-effect of block size increase, and doesn’t provide any incentive to
control the size of UTXO set. Also, BIP140 makes the UTXO set permanently
bigger, as the database needs to store both txid and normalised txid
On 21 Nov 2017, at 1:24 AM, Praveen Baratam via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Bitcoin Noob here. Please forgive my ignorance.
>From what I understand, in SegWit, the transaction needs to be serialized
into a data structure that is different from the current one where
signatures are separated from the rest of the transaction data.
Why change the format at all? Why cant we just compute the Transaction ID
the same way the hash for signing the transaction is computed?
--
Dr. Praveen Baratam
about.me <http://about.me/praveen.baratam>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171120/7fe1e946/attachment.html>

2023-06-07 17:38:50

- reply

📅 Original date posted:2015-09-01
📝 Original message:Keep in mind... Legal or Not, many ISPs (Comcast for example) prohibit
offering up network services (which a full node would supply) from
your residence.
I checked AT&T's TOS and they have a carve-out on equipment that is scary
http://www.att.com/legal/terms.internetAttTermsOfService.html
>Regardless of whether the equipment used to access your Service (modem, gateway, etc.) is owned by you or AT&T, AT&T reserves the right to manage such equipment for the duration of your Service, and retains exclusive rights to data generated by the equipment. Neither you nor a third party may change, interfere with, or block access to equipment data or settings.
AT&T seams to imply they implicitly have Admin rights to all
"equipment" that connects to their network. Clearly an overreach that
needs to be clarified, but there it is.
As for Comcast, they simply forbid network "services" that serve
anyone off-premise.
http://www.xfinity.com/Corporate/Customers/Policies/HighSpeedInternetAUP.html
> [MAY NOT] use or run dedicated, stand-alone equipment or servers from the Premises that provide network
content or any other services to anyone outside of your Premises local
area network (“Premises
LAN”), also commonly referred to as public services or servers.
Examples of prohibited
equipment and servers include, but are not limited to, email, web
hosting, file sharing, and proxy
services and servers
Technically, P2P is prohibited in the Comcast TOS, or at least by my
reading. I realize that Comcast with deny this tooth and nail, but if
they ever want to exercise the prohibition, it is clearly spelled out
in their TOS
My recommendation is to file a complaint with the FCC to bring up your
issue as well as any overreach they spell out in the AUP or TOS.
As for me... I simply subscribed to a VPN. That gives me both privacy
(to a degree) and flexibility to open or close whatever ports I want.
On Tue, Sep 1, 2015 at 2:16 AM, odinn via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Another note on this subject to add to the stuff people have already
> mentioned...
>
> If you have the AT&T landline but don't use AT&T's standard internet /
> tv (what they call Uverse) offering - that is, if you prefer to use
> some local internet provider - you are probably better off (in terms
> of avoiding not only this sort of blockage/censorship but as well,
> potentially getting a better privacy policy that isn't going to be
> like AT&T's long-term data retention). You can check directly with
> the various local small ISPs to see what their policies are
> specifically on ports and whatnot.
>
> Ideally your ISP should let you:
>
> port forward to SOMEPORTNUMBER for tcp and udp
>
> (above may or may not be helpful for some if you are using
> decentralized markets)
>
> have port 8333 open
>
> (above is for bitcoin of course)
>
> Supposing you have FTTN because you are paying a local ISP for
> internet service, and that local ISP has contracted with AT&T to be
> able to provide service in an area where old-style DSL has been phased
> out, thus your local ISP is essentially providing you AT&T FTTN.
> (FTTN is Fiber to the Node, FTTN-BP is FTTN Bonded Pair). Even if a
> local ISP has its own privacy policy posted which is different from
> AT&T, everything is subject to AT&T data retention because the FTTN.
> So get yourself a VPN (or set up your own) for your connection. Tor
> will run through the VPN.
>
> General observations - TWC stores your IP and other stuffs for 6
> months or longer. Same for Comcast. Verizon retains your stuffs for
> 18 month minimum, probably longer though. Qwest/Century, 1 year.
> Cox, 6 months. AT&T retains for longer than a year. This is just
> what they are telling you, the reality is it's probably longer due to
> stuff like this:
> https://www.lawfareblog.com/odni-and-doj-release-last-section-215-collec
> tion-order
>
>
>
>
>
>
>
>
>
> Zach G via bitcoin-dev:
>> I have been struggling to get port 8333 open all year, I gave up
>> and was using blockchain for months despite a strong desire to stay
>> on Bitcoin Core, but now the issue has reached critical mass since
>> I'm using the python Bitcoin server module. I have literally spent
>> my entire day trying to open 8333, I thoroughly made sure it was
>> open on the router and computer and it's still closed. Strangely
>> enough I got it open for 30 seconds once today but something closed
>> it immediately.
>>
>> After hours of phone calls and messaging AT&T finally told me the
>> truth of what was going on, and only because I noticed it myself
>> and demanded an answer. The internet is being routed through a
>> DVR/cable box, and they confirmed the DVR also has a firewall. To
>> make this even more absurd they refused to turn the firewall off
>> because it is their equipment. So effectively they can firewall any
>> port they want even if the customer asks them not to, in the
>> unlikely event the customer figures it out.
>>
>> Perhaps this is the driving force behind the inexplicable and
>> massive decline in Bitcoin nodes. Bitcoin is being censored by the
>> ISPs themselves, and they won't even tell you that. I had to get in
>> touch with headquarters and threaten to rip it out of the wall to
>> get a proper answer.
>>
>>
>>
>> _______________________________________________ bitcoin-dev mailing
>> list bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> - --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -----BEGIN PGP SIGNATURE-----
>
> iQEcBAEBCgAGBQJV5VDeAAoJEGxwq/inSG8CvkIH/jy4Vo+My3xeBdvFQmxkJWyQ
> U5mv2zWEvBYw71Xy1EDzQY1AhEBmatUU1eu2AbOqXdUR4511FxCNzFmTxy6roEiz
> EehBkvXNbBCbEzLRisjxuQw34OKM+xfieCqE1mzJok2uSdLMMQLcbWL1/k3/OmS5
> 9O9z/wMXqU1Jc19MTK+vF1Lz5ilnRn3hEbTaCN3ivYnYFa0DpBH9r0Y07UcoJ6Wr
> ui/x0sSSuupAGzOkZ75HQ8yeQXckeAu6TB3/jE8QEqNUmAJkmR8eK4ofXZWFrIjy
> mOKeQL4c+jRQnTR8pt+y89g2QIpzFoHaV5T+WvQuC1t8xNOrxLgYFXWgl0dhoYE=
> =UCLC
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:41:54

- reply

📅 Original date posted:2015-07-11
📝 Original message:I think a compromise will be somewhere in the middle. I think most people
would be OK with TXs that don't have enough fees for P2P transfer to stay
in deadmans land. Most people are stuck in a situation where they payed
enough to get it into (and keep it in) the pool, but not enough to get it
out.
If we could get CPFP that only worked on TXs that met the minimum threshold
for peer propagation, then I think we would be in much better position to
battle this spam flood.
On Sat, Jul 11, 2015 at 3:28 PM, Micha Bailey <michabailey at gmail.com> wrote:
> Right. The issue (AIUI) is that, right now, even though transactions are
> evaluated for inclusion as a group with CPFP, they're not yet evaluated for
> relaying as a unit, nor can they be, because the current p2p protocol
> doesn't have a way to send multiple transactions in a single protocol
> message to signify that they should be evaluated together.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150711/9ba24f71/attachment.html>

2023-06-07 15:41:53

- reply

📅 Original date posted:2015-07-10
📝 Original message:On Fri, Jul 10, 2015 at 11:31 AM, Jeff Garzik <jgarzik at gmail.com> wrote:
> This is a good explanation but it does not address reachability. TX_a, the
> first tx sent out on the network, presumably has insufficient fee to get
> mined - which also means it did not necessarily even reach all miners.
>
> Simply sending out TX_b with added fee does not guarantee that nodes
> suddenly have TX_a, which they may have ignored/dropped before.
True... there are two propagation thresholds... "-minrelaytxfee"
(defaults to 1000 sotoshi/kbyte) and "relaypriority" (defaults to
True). If -relaypriority is True, then items with a priority above
57600000 (currently <ref1>) will still be relayed, even if their TxFee
is below MinRelayTxFee.
Therefore even if miners are using bitcoind rules for mempool tx
creation, they can still configure how and what they propagate.
The flip-side of this is that a transactions priority will go up the
longer it ages (in the mempool). So it would be possible (if
relaypriority was on) for even a lowfee transaction to become
relayable eventually simply based on relaypriority
ref1: https://en.bitcoin.it/wiki/Transaction_fees
On Fri, Jul 10, 2015 at 12:02 PM, Justus Ranvier
<justus at openbitcoinprivacyproject.org> wrote:
> CPFP is initiated by the recipient of the parent transaction, and so if
> the recipient is creating this transaction in the first place they must
> have a copy of the parent transaction which can/should broadcast at the
> same time.
>
> If the child reaches a CPFP miner, then presumably the parents made it
> as well (any path between the sender and the miner that doesn't relay
> the parent should reject the child as trying to spend non-existent
> coins), so both of the transactions can be mined at the same time.
If the recipient is running a full node with incoming connections.
I'm not sure if SPV clients rebroadcast both spend and receive
transactions.

2023-06-07 15:41:52

- reply

📅 Original date posted:2015-07-10
📝 Original message:Some miners have voluntarily deployed CPFP.
I had a thread about it earlier this month where some other ideas got
tossed around.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009304.html
The specific pull request to get it into the reference implementation
is still open based on a merge conflict
https://github.com/bitcoin/bitcoin/pull/1647
Peter Todd has another thread on RBF which you mentioned earlier
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html
There is also a beautiful example of CPFP in action from Eligius in
this transaction:
https://blockchain.info/tx/4cc3e2b6407ae8cdc1fd62cb3235f9c92654277684da8970db19a0169e44c68c
Follow the spent outputs and you will see the person is trying to
incentive the transaction by upping the fees of dependent
transactions. It set in the mempool until Eligius won a block, then
it made it into the chain. CPFP still works, but only in an Eligius
block (that I can see). So it's better than nothing.

2023-06-07 15:41:35

- reply

📅 Original date posted:2015-07-15
📝 Original message:Offering a bounty for this feature
Specifically...
Anyone who can put a CPFP transaction creation feature into any wallet
featured on the bitcoin homepage (ref1) can claim this bounty. The
funds are being raised by donation. The funds will be dispersed from
the following address when the bounty is claimed:
3FEUByMeaxrNmBCVYjvsnhyAjiUdat5i7M
Currently there isn't much in there, but I welcome angels to fill the bucket.
Here's proof that the multisig address is not 1 of 1:
https://bitcointalk.org/index.php?topic=1122956.0
Bounty announce: https://bitcointalk.org/index.php?topic=1123464.0
ref1: https://bitcoin.org/en/choose-your-wallet

2023-06-07 15:41:35

- reply

📅 Original date posted:2015-07-09
📝 Original message:FYI, looks like someone was trying to boost up a transaction tonight
and managed to get it pushed through.
parent: 4cc3e2b6407ae8cdc1fd62cb3235f9c92654277684da8970db19a0169e44c68c
child: 161b302d1af8b6eacf1140726b26c67fa72ecf4f7f7e6cd8d83ef492b8b490ea
gchld: 4f6821b50c046ae40d488aa18d88d41c9d0686daedf835b68b8c5086b73939fd
ggch: 0c159d19f6452f12512a4ec16868a3af00fe381a0913f4fc69b3fc14c4588aa9
gggch: 4e4f96c5ba416961be347ffc496e8ce12046191ab7fb252e88966ce365d2bc5f
though it's position in the block doesn't seem to be a priority / fee cut line.

2023-06-07 15:41:33

- reply

📅 Original date posted:2015-07-06
📝 Original message:On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:
> This is called child pays for parent and there is a three year old pull
> request implementing it:
>
> https://github.com/bitcoin/bitcoin/pull/1647
Understood... When I wrote the BIP proposal I was assuming
(incorrectly) that CPFP TX selection was already being done by miners,
but I see now that certain trees could bloom the TX selection latency
as miners would need to be more dependency aware. Perhaps the BIP66
orphan block chain shows that some miners may not always be counted on
to ensure that all TX stuffed in a block have dependencies met.
Certainly not until the PR1647 is fully merged and deployed.
On Wed, Jul 1, 2015 at 11:57 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> PR#1647 only addresses miner policy, though, right? I believe the BIP is
> addressing the user-facing side of this functionality. CPFP mining policy
> does very little good if wallets don't offer any way for users to goose up
> incoming transactions.
On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:
> The points regarding sweep transaction UI is out of scope for a BIP I'm
> afraid. I suggest talking with wallet authors, and if agreement can be
> found writing a pull request.
Yes... although I certainly admit, I didn't know about CPFP or I would
have called it out as a requirement for this UI enhancement request.
I'll see if I can't get some wallet authors interested in this as a
feature enhancement when PR1647 commits.
Perhaps there are risks raised if CPFP is not enabled but these sweep
tx enter the mempool. If miners take the high fee "children" but
ignore the low fee "parents" then the child might enter the blockchain
without the parent. If miners were light on block validation,
wouldn't it be possible that the child may go forward with many
confirmations, while the parent patiently waits in the mempool? This
could be bad since spending the child may look good, as it might have
many confirmations, while its parent has few.
On Fri, Jul 3, 2015 at 4:56 PM, Peter Todd <pete at petertodd.org> wrote:
> "Replace-by-fee scorched-earth without child-pays-for-parent",
> Peter Todd, Bitcoin-development mailing list, Apr 28th 2014
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html
Very good! So if I follow, RPF can work one of two ways:
In the "countermeasure" form, spender gives receiver a partially
signed "countermeasure" transactions with juiced up fees.
In the "anyonecanpay" form, spender signs the transaction with
ANYONECANPAY bit allowing the reviver to add fees at will.
One question I did have about RBF is this.. Is it correct to presume
that the spender doesn't send the incomplete "countermeasure"
transaction to the network? If they did, wouldn't they get flagged on
DoS code banning them from peers?
Corollary question. If the "countermeasure" transaction is not
broadcast, is it sent to the receiver via back channel (email, etc)
I'll try to clean up the draft BIP to include CPFP dependencies and
RBF capabilities. Whether it belongs in a BIP or a PR, its just a doc
to outline my thoughts at this point. Not burning a whole in my head,
so may take some time.
Thx.

2023-06-07 15:41:32

- reply

📅 Original date posted:2015-07-02
📝 Original message:This is a process BIP request to add functionality to the Bitcoin-Core
reference implementation. If accepted, this could also add
flexibility into any future fee schedules.
https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki
Note, left the formatting in, since mediawiki is a fairly light markup.
==================================
<pre>
BIP: nn
Title: Sweep unconfirmed transactions by including their outputs in
high fee transactions
Author: Dan Bryant <dkbryant at gmail.com>
Status: Draft
Type: Process
Created: 2015-07-01
</pre>
==Abstract==
This BIP describes an enhancement to the reference client that
addresses the need incentive inclusion of unconfirmed transactions.
This method will create new high fee (or bounty) transactions that
spend the desired unconfirmed transactions. To claim the high fee
(bounty) transactions, miners will need to include the desired
unconfirmed transactions.
==Motivation==
There are times when an individual receives a payment from someone
that is in a poorly crafted transaction. This transaction may include
no fees, or insufficient fees to be included by many miners. The
recipient would be willing to pay a nominal transaction fee to have
the payment transaction swept into the next block, but has no simple
way to craft this incentive.
This BIP could be highly desirable for merchants who may have little
control over the type of wallets their customers use. A merchant will
want to ensure that all POS transactions to their hot wallet be given
a high probability of inclusion in the next block. This BIP would
allow the merchant to sweep all their POS transactions currently in
the mempool into one high fee sweep, thus greatly increasing the
chance that they are in the next block.
Although many wallets have the ability to tailor the transaction fees
of payments that are sent, this BIP is unique in the sense that it
allows people to offer a bounty for transactions that are incoming.
==Specification==
This BIP would have two implementations; an automatic sweep of
incoming unconfirmed transaction setting, and a manual sweep of
unconfirmed transaction setting. Both would have the ability to set
the fee amount the user would like to pay for the sweep.
====Automatic sweep of incoming unconfirmed transactions====
An automatic sweep configuration may be ideal for merchants who want
to ensure that their incoming transactions are not skipped over by
miners. An automatic sweep setting would consist of four fields,
<tt>'''sweep_fee'''</tt>, <tt>'''skipped_count'''</tt>, and
<tt>'''btc_threshold'''</tt>
Currently, the standard transaction fee is 0.0001 BTC, a generous
sweep bounty would be 0.001 BTC. Skipped-count will control the age
of unconfirmed transactions to include in the sweep. If skipped-count
is set to three, then any incoming transaction that remains
unconfirmed for 3 blocks would trigger a sweep. A skipped-count of 0
would trigger a sweep whenever any transaction is skipped, or if it
reaches an age of 10 minutes, regardless of how long the current block
is taking.
As a safeguard to paying a bounty for small "dust" transactions, a
minimum btc-threshold would be required for any automatic
configuration. A good starting threshold would be 0.10 BTC. These
automatic settings would allow a wallet implementing this BIP to
automatically perform a sweep of unconfirmed transactions whenever
more than 0.10 BTC of incoming transactions were detected in the
mempool. Furthermore, no more than one automatic sweep would be
performed in any 10 minute window.
Whenever a sweep is triggered, all incoming unconfirmed transactions
should be swept, not simply the ones that triggered the sweep. These
would include new transactions as well as dust transactions. Each
sweep transaction would go to a new wallet address since recycling
wallet addresses is poor practice.
====Manual sweep of incoming unconfirmed transactions====
A manual sweep of incoming unconfirmed transactions would be a special
type of "Send" in the current reference implementation. A manual
sweep would auto-fill a send transaction with all currently
unconfirmed incoming transactions in the mempool. The fee field would
be completely settable by the user and would auto-fill with the
suggestions of 0.001 BTC
A manual sweep would also be available as a context option when
selecting any unconfirmed transaction.
==Compatibility==
Wallet software that does not support this BIP will continue to
operate without modification.
==Examples==
<pre>
//unconf_tx = ef7c0cbf6ba5af68d2ea239bba709b26ff7b0b669839a63bb01c2cb8e8de481e
//hifee_tx = f5a5ce5988cc72b9b90e8d1d6c910cda53c88d2175177357cc2f2cf0899fbaad
//rcpt_addr = moQR7i8XM4rSGoNwEsw3h4YEuduuP6mxw7 # recipient controlled addr.
//chng_addr = mvbnrCX3bg1cDRUu8pkecrvP6vQkSLDSou # recipient controlled addr.
// UNCONF_TX - Assume a zero fee TX that miners are refusing in mempool
{
"txid" : "$unconf_tx",
//...
"vin" : [
//...
],
"vout" : [
{
"value" : 1.50000000,
"n" : 0,
"scriptPubKey" : {
//...
"addresses" : [
"$rcpt_addr"
]
}
}
]
}
// HIFEE_TX - Requires UNCONF_TX to be included in order to claim the
// high (0.001 BTC) fee. Note this transaction is going from one
// address to another in the same wallet. Both are controlled by the
// recipient.
{
"txid" : "$hifee_tx",
//...
"vin" : [
{
"txid" : "$unconf_tx",
"vout" : 0
//...
}
],
"vout" : [
{
"value" : 1.49900000,
"n" : 0,
"scriptPubKey" : {
//...
"addresses" : [
"$chng_addr"
]
}
}
]
}
</pre>