damian at willtech.com.au [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-10-17 to 2022-02-24
💬 Posted a total of 14 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, Pre-BIP
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:04:48

- reply

📅 Original date posted:2022-02-24
📝 Original message:Not all people who have been stolen from believe that they have lost the
right and title to what has been stolen and in many cases they have not.
I do not excuse Bitcoin that it is impossible to have any individual
Bitcoin identified but also I do not care, if I receive Bitcoin honestly
I do not care what their history was. What if they were taken from a
brothel? It is not a matter for an ordinal to determine if a satoshi is
fungible. It is truth in effect that each satoshi is newly created to
the new UTXO and the old satoshi destroyed. -DA.
On 2022-02-23 18:31, Casey Rodarmor wrote:
>> The least reasonable thing I could expect is some claimed former
>> holder of some ordianls turning up to challenge me that it was their
>> stolen Bitcoin was some of what I received.
>
> I think it's unlikely that this would come to pass. A previous owner
> of an ordinal wouldn't have any particular reason to expect that they
> should own it after they transfer it. Similar to how noting a dollar
> bill's serial number doesn't give you a claim to it after you spend
> it. From the BIP:
>
>> Since any ordinal can be sent to any address at any time,
>> ordinals that are transferred, even those with some public history,
>> should be considered to be fungible with other satoshis with no such
>> history. [1]
>
>
>
> Links:
> ------
> [1]
> https://github.com/casey/ord/blob/master/bip.mediawiki#backward-compatibility

2023-06-07 23:04:46

- reply

📅 Original date posted:2022-02-23
📝 Original message:Well done, your bip looks well presented for discussion. You say to
number each satoshi created? For a 50 BTC block reward that is
5,000,000,000 ordinal numbers, and when some BTC is transferred to
another UTXO how do you determine which ordinal numbers, say if I create
a transaction to pay-to another UTXO. The system sounds expensive
eventually to cope with approximately 2,100,000,000,000,000 ordinals. If
I understand ordinals 0 to 5,000,000,000 as assigned to the first
Bitcoin created from mining block-reward. Say if I send some Bitcoin to
another UTXO then first-in-first-out algorithm splits those up to assign
1 to 100,000,000 to the 1 BTC that I sent, and 100,000,001 to
5,000,000,000 are assigned to the change plus if any fee?-DA.
On 2022-02-23 11:43, Casey Rodarmor via bitcoin-dev wrote:
> Briefly, newly mined satoshis are sequentially numbered in the order
> in
> which they are mined. These numbers are called "ordinal numbers" or
> "ordinals". When satoshis are spent in a transaction, the input
> satoshi
> ordinal numbers are assigned to output satoshis using a simple
> first-in-first-out algorithm.

2023-06-07 23:04:46

- reply

📅 Original date posted:2022-02-23
📝 Original message:At the moment it is indisputable that a particular satoshi cannot be
proven, an amount of Bitcoin is a bag of satoshi's and no-one can tell
which ones are any particular ones **so even if you used the system of
ordinals privately, and it might make interesting for research, I cannot
see that it would be sensible to be adopted** as it can only cause
trouble. If I receive some Bitcoin I cannot know if some or any of those
have been at any point in the past been stolen, I assume the transaction
is honest, and in all likelihood it is likely that it is. The least
reasonable thing I could expect is some claimed former holder of some
ordianls turning up to challenge me that it was their stolen Bitcoin was
some of what I received.
NACK
-DA.
On 2022-02-23 18:02, damian at willtech.com.au wrote:
> Well done, your bip looks well presented for discussion. You say to
> number each satoshi created? For a 50 BTC block reward that is
> 5,000,000,000 ordinal numbers, and when some BTC is transferred to
> another UTXO how do you determine which ordinal numbers, say if I
> create a transaction to pay-to another UTXO. The system sounds
> expensive eventually to cope with approximately 2,100,000,000,000,000
> ordinals. If I understand ordinals 0 to 5,000,000,000 as assigned to
> the first Bitcoin created from mining block-reward. Say if I send some
> Bitcoin to another UTXO then first-in-first-out algorithm splits those
> up to assign 1 to 100,000,000 to the 1 BTC that I sent, and
> 100,000,001 to 5,000,000,000 are assigned to the change plus if any
> fee?-DA.
>
> On 2022-02-23 11:43, Casey Rodarmor via bitcoin-dev wrote:
>> Briefly, newly mined satoshis are sequentially numbered in the order
>> in
>> which they are mined. These numbers are called "ordinal numbers" or
>> "ordinals". When satoshis are spent in a transaction, the input
>> satoshi
>> ordinal numbers are assigned to output satoshis using a simple
>> first-in-first-out algorithm.

2023-06-07 23:00:29

- reply

📅 Original date posted:2021-11-05
📝 Original message:Good Afternoon,
Talk about the present and the future is misguided if it concludes that
the decentralisation of a project itself is responsible even if the
operation of the project is to produce a specification, and a software
capable of performing transactions in a decentralised manner. There is
no advantage or disadvantage to the project to have several choices of
the software implementation unless buffoons are misguided and wish to
attack fungibility or consensus, which the operation of consensus must
defend, in which case use [Bitcoin Core at version
21](https://github.com/bitcoin/bitcoin/tree/0.21) and [create a
fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo) and
start developing. As you can see [Bitcoin Core version 20 has been
modified](https://github.com/bitcoin/bitcoin/branches) and no longer
passes checks similarly with version 18 which makes it more difficult to
compile make build. A person't own contributions are theirs, to delegate
is responsible, to try and create a seven headed lion to keep under
command like one would a gryphon is an infirmity.
Creating a properly delegated organisation, being a foundation for the
purpose of the maintenance of the consensus of Bitcoin a fungible
decentralised currency and the Bitcoin Core software is the sort of
thing I would easily consider but it is far more centralised to be an
operable concern. In short, as at the beginning, Bitcoin needs a few
heroes that can understand the whitepaper and write software and if the
work is too much one organisational foundation that does is correctly
stewardship. To decentralise one's own work only requires that there are
several offices available for those you employ to delegate to, but still
there requires for your project a headship.
Once the currency is fungible as you should now consider, just today
there was a public announcement that the Commonwealth Bank Of Australia
is going to allow buying and selling Bitcoin as one of its services, the
primary requirements are to defend the existing consensus as the right
of trade in every UTXO has value because of that consensus, and
particularly because of the ease of that trade.
I do not expect anybody is eligible to be dictated to in the Bitcoin
project, but people, be sensible, everybody has worked hard and the
project is becoming a success. Opportunities to further develop the
software of the coin and the protocol do not form part of the current
value, hardly. Several groaning seven headed lion's are
counterproductive if all they do is search for opportunities for change.
Change is the diametrically opposed of consensus and is consensus that
brings fungibility. You can already make any manner of instrument for
smart contract with your solicitor's office. What is necessary is the
operation of the Bitcoin protocol. The alternative to the deliberately
chosen consensus is a democracy, and you cannot build any software with
democracy, and people do not know what is good for them or they could
govern themselves. A few lessons in history assures government is
necessary to enshrine law and insist as the delegates of democracy for
its operation, to ensure a civilised and decent civility can exist.
Please, if you have concerned for Bitcoin, revoke your positions until
you fight for consensus.
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-11-05 01:17, Prayank via bitcoin-dev wrote:
> Hi Kate,
>
>> He is taking the most sensible way forward, decreasing bus factor.
>
> Agree. Work being shared with other maintainers is an improvement.
>
>> Read: https://laanwj.github.io/2021/01/21/decentralize.html
>
> Interesting blog post. First paragraph talks about strange
> expectations, not sure what other people expected however I expected
> present maintainers will always have respect for the Founder of
> Bitcoin, keep important docs in repository, website etc. forever and
> respond with appropriate things if any rich scammers try to remove
> anything important. Anyway that chapter is over and this PR will
> always remain in history for others to see and make their own opinions
> about it: https://github.com/bitcoin-core/bitcoincore.org/pull/740
>
> What followed it (whitepaper being shared on different websites) was
> true decentralization and we need something similar in other aspects
> of full node implementations. Few things that can improve
> decentralization:
>
> 1.More people using alternative full node implementations. Right now
> 98% of nodes use Bitcoin Core.
>
> 2.More people like Luke Dashjr and Amir Taaki who do not simp for
> anyone. Being a contributor or maintainer in Bitcoin full node
> implementation is different from other open source projects. It was
> never going to be easy and it will get difficult with time,
>
> 3.More people from different countries getting involved in important
> roles.
>
> 4.Few anons.
>
> 5.Individuals and organizations who fund different Bitcoin projects
> should consider contributing in alternative. full node implementations
> as well. Maybe start with Bitcoin Knots.
>
> I am sure lot of people will find this controversial or disagree with
> it however this is my opinion and things that I think can improve
> Bitcoin. Will quote something from my recent medium post about a dev
> meetup and Knots:
>
> Accepting the problems, looking for solutions and trying to improve
> things is the best approach we as engineers can follow to do better
> things in Bitcoin. Irrational optimism is as toxic as irrational
> pessimism.
>
> https://prayankgahlot.medium.com/op-halloween21-and-bitcoin-knots-b8a4da4fa0bd
>
> Only ~1337 blocks left for Taproot to activate. So cheers to another
> soft fork being a success and Bitcoin improving regularly. Thanks to
> everyone who contributed including reviewers. Hoping most of the
> people will start using latest version of Bitcoin Core or other full
> node implementations soon.
>
> .
>
> --
>
> Prayank
>
> A3B1 E430 2298 178F
>
> Oct 21, 2021, 01:48 by mercedes.catherine.salazar at gmail.com:
>
>> Hi Owen,
>>
>> On Wed, Oct 20, 2021 at 9:25 PM Owen Gunden via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Wed, Oct 20, 2021 at 04:47:17PM +0200, Prayank wrote:
>>>
>>>>> It seems confusing to have two sites that seemingly both
>>> represent
>>>
>>>>> bitcoin core.
>>>
>>>>
>>>
>>>> There is only one website which represents Bitcoin Core full
>>> node
>>>
>>>> implementation. You can download Bitcoin Core from
>>>
>>>> https://bitcoincore.org
>>>
>>> I also notice that, as of 22.0, Wladimir is no longer signing the
>>>
>>> releases, and I have no trust in my gpg network of the people who
>>> seem
>>>
>>> to have replaced him.
>>
>> He is taking the most sensible way forward, decreasing bus factor.
>>
>> Read: https://laanwj.github.io/2021/01/21/decentralize.html
>>
>>> Given the level of security at stake here, my eyebrows are raised
>>> at
>>>
>>> this combination of items changing (new website + new gpg signers
>>> at the
>>>
>>> same time).
>>
>> Don't worry and build your own release;
>>
>> but if you do, always verify the tree hash.
>>
>> Trust signed annotated tags.
>>
>> Cheers!
>>
>>> _______________________________________________
>>>
>>> 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

2023-06-07 23:00:07

- 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