<unnamed>

Public Key

npub1uzzuglt5nr4mhea9rt4773ae5tcwcvu4zzt5eg6uxcda2l20as0qqpalry

Profile Code

nprofile1qqswppwy046f36amu7j346l0g7u69u8vxw23p96v5dwrvx740487c8sprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqyxhwumn8ghj7mn0wvhxcmmvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hswnn3nu

Publishing to

relay.snort.social

nos.lol

relay.damus.io

Last Notes

2023-06-09 13:05:14 UTC

- reply

📅 Original date posted:2022-02-14
📝 Original message:
Good Afternoon,
I am briefly reading the suggestion subject titled this email message.
The problem this idea addresses is not new, it is as old as computer
science with complexity and security varying from unused products in a
supermarket database to unused bank accounts and records of transactions
for archival. In the former, it is of no consequence to remove unused
products from the database if the itemised sales history is not
necessary and the report data is maintained ie. where the reporting is
stored generated. Once the products are removed it is impossible to
regenerate the detailed reports that called on the product-specific and
sales information. Archival works in a manner to remove data from
commonly used tables and to optimise them and if the data is later
required it can be recalled from larger possibly slower storage, or
simply kept in a larger less optimised table, in either case, all of the
data is still available. In the latter, it is a matter of consequence
and although archival is possible it is still necessary to ensure that
all archives are backed up, and the data can never be removed. This is
because if in an example transaction data is deleted after seven years
then it is no longer possible to see how an account has its balance and
an empty account with no transactions may be removed while actually
still holding a significant balance. If a mistake is made the result is
the same. This is because we allowed deletion of accounting records.
Actually, the recommendation from Computer Science all along is the same
as our case with Bitcoin - nothing should be deleted from the Blockchain
forever. For one substantiative reason, this is because it is necessary
for any client to be able to validate the blockchain in its entirety and
some clients may only be receiving information as to the state of the
blockchain from you. When you keep the entire blockchain you validate to
everybody else that you have the correct records. I arbitrarily object
to the use of pruned nodes but find them useful since the process of
validation is completed in its entirety when a new node comes online
even if it is pruned, but if only pruned nodes are available then
everybody has to believe the other nodes and this is unacceptable for
Bitcoin. It should be if some node is archiving UTXO's then it should
count as a pruned node, but my suggestion is, instead of making a
programming change just set your node with the parameter `prune=1` if
you wish to allow manually pruning from the Blockchain to a specific
height when you wish, or `prune= {>550} automatically prune blocks to
stay under target size in MiB`. My chain state database after all is
only 4.9GB and is hardly a concern for any operation of the standard
Bitcoin Core client. The answer, again, is you should just leave it and
get used to dealing with the bigger database.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
duigco.org DUIGCO API
and other projects
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this
email if misdelivered.

2023-06-07 23:00:07 UTC

- reply

📅 Original date posted:2021-10-17
📝 Original message:Good Afternoon,
I am certain that as soon as we identify solutions they should be
implemented. Basic life skills assert that procrastination is always a
form of failure, where we could have realised and accomplished further
yet we waited and in our present state could not ascertain what was in
our benefit.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
duigco.org DUIGCO API
and other projects
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this
email if misdelivered.
On 2021-10-15 08:27, James Lu via bitcoin-dev wrote:
> Making Bitcoin function after 2038 is by definition a hard fork
>
> I feel if we do HF, we should bundle other HF changes with it...
>
> On Wed, Oct 13, 2021 at 5:19 PM vjudeu via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> It seems that Bitcoin Core will stop working in 2038 because of
>> assertion checking if the current time is non-negative. Also, the
>> whole chain will halt after reaching median time 0xffffffff in 2106.
>> More information: https://bitcointalk.org/index.php?topic=5365359.0
>>
>> I wonder if that kind of issues are possible to fix in a soft-fork
>> way. _______________________________________________
>> 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