Murch [ARCHIVE] / is on Nostr

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

Last Notes

2023-08-09 16:03:59

- reply

📅 Original date posted:2023-08-09
🗒️ Summary of this message: The text contains an HTML attachment that was removed. The URL for the attachment is provided for reference.
📝 Original message:
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230809/ae71b50a/attachment.html>

2023-06-07 23:20:21

- reply

📅 Original date posted:2023-04-05
🗒️ Summary of this message: Murch has proposed an informational BIP to establish a shared vocabulary for various components and aspects of transactions to avoid confusion.
📝 Original message:Hey everyone,
Over the years, I have participated in a few conversations about various
aspects of transactions. Often a chunk of the conversation is spent on
establishing a shared vocabulary. There are many competing terms—e.g. I
can think of at least three additional terms that refer to `scriptPubKey`.
I’ve drafted an informational BIP that proposes terminology for various
components and aspects of transactions. As some established terms are
already contradictory, the proposal does not aim for a perfectly
consistent selection of terms, but rather just to establish a shared
vocabulary to avoid confusion.
Draft: https://github.com/Xekyo/bips/pull/1
Please let me know whether you’d be interested in the creation of such a
BIP.
Cheers,
Murch

2023-06-07 23:16:40

- reply

📅 Original date posted:2022-11-03
📝 Original message:Hi Pieter, hello list,
On 26.10.22 12:39, Pieter Wuille via bitcoin-dev wrote:
> 1. The most straightforward solution is using the BIP process as-is: let BIP324
> introduce a fixed initial table, and future BIPs which introduce new
> messages can introduce new mapping entries for it. In theory, this is no
> worse than the current coordination difficulty about command strings, but
> in practice the risk of collisions due to competing proposals is of course
> significantly larger with 1-byte IDs vs. 12-byte strings.
From what I understand we'll have about 35 message types on the network
with the addition of BIP324. 256 possible IDs sounds like plenty room to
grow, but perhaps we can be a bit more conservative:
We could use the first bit to signal a 2-byte message ID. That allows us
to express 128 IDs with 1 byte, but if we need more, we get a total of
2^15 IDs across 2 bytes.
I would not be too concerned about collisions. Firstly, message types
would probably be announced to the mailing list as part of the
corresponding BIP, secondly, any overlooked collision should become
apparent at implementation time. The risk could perhaps be further
mitigated by encouraging less prevalent message types to use a 2-byte ID.
Cheers,
Murch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221103/fa31bbc7/attachment.sig>

2023-06-07 23:15:25

- reply

📅 Original date posted:2022-10-18
📝 Original message:Hello John,
On 17.10.22 02:23, John Carvalho via bitcoin-dev wrote:
> Simply, 0conf acceptance can be monitored and enforced by the merchant and exposure to doublespends can be both mitigated and limited in size per block. It is less expensive to be double-spent occasionally than to have a delayed checkout experience. Responsible 0conf acceptance is both rational and trusting.
29% of all transactions explicitly signal replaceability (see
https://transactionfee.info/charts/transactions-signaling-explicit-rbf/), trend
rising. If ignoring risk is an acceptable approach now, why would it no
longer work when the remaining 71% of transactions also became subject
to replaceability?
On 17.10.22 02:23, John Carvalho via bitcoin-dev wrote:
> Now RBF just kinda haunts us as the establishment keeps baking it deeper and deeper into Bitcoin, despite almost no one using it, and despite it having negative consequences on more popular use cases.
How can RBF at the same time be hardly used as well as an incalculable risk?
Fact of the matter is that one can neither rely on having seen all
transactions that miners are considering for their block templates, nor
that a replacement be received by the miners before the original is
picked into a block.
We're between seats: first-seen is an unstable gentlemen's agreement,
inevitable to fail eventually once a few defect. Meanwhile propping up
the illusion of "reliable payment promises" is hampering price discovery
of blockspace and complicating protocol development. By converging on
the inevitable outcome and facilitating replaceability for all
transactions, we can rip off the band-aid rather than suffer uncertainty
indefinitely—even if it requires some to honestly reassess their
business approach in light of the natural modus operandi of Bitcoin's
gossip system.
Cheers,
Murch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xACFDB93A9175DCAB_and_old_rev.asc
Type: application/pgp-keys
Size: 119298 bytes
Desc: OpenPGP public key
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/3d7170ac/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/3d7170ac/attachment-0001.sig>

2023-06-07 22:54:06

- reply

📅 Original date posted:2021-05-25
📝 Original message:Hi Bitcoin Devs,
We are writing to share with you a suggested improvement to the current
bitcoin core block building algorithm. In short, currently Bitcoin Core
uses a straightforward greedy algorithm which evaluates each
transaction’s effective fee rate in the context of its unconfirmed
ancestors. This overlooks situations in which multiple descendant
transactions could be grouped with their shared ancestors to form a more
attractive transaction set for block inclusion.
For example, if we have 4 transactions A,B,C, and D, with fee rates and
weights as follows
Tx Fee Weight
A 5 1
B 10 1
C 15 1
D 14 1
And dependencies:
• B is a descendant of A
• C is a descendant of B
• D is a descendant of A
The current algorithm will consider {A,B,C} best which has an effective
fee rate of 10. Our suggested algorithm will also consider {A,B,C,D},
which has an effective fee rate of 11.
Experimental data shows that our suggested algorithm did better on more
than 94% of blocks (99% for times of high congestion). We have also
compared the results to CBC and SAT Linear Programming solvers. The LP
solvers did slightly better, at the price of longer running times. Greg
Maxwell has also studied LP solvers in the past, and his results suggest
that better running times are possible.
The full details are given in this document, and we are happy to hear
any comment, critic or suggestion!
Best,
Mark and Clara
Full details:
https://gist.github.com/Xekyo/5cb413fe9f26dbce57abfd344ebbfaf2#file-candidate-set-based-block-building-md
Research Code:
https://github.com/Xekyo/blockbuilding
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210525/6e8d2ba1/attachment.sig>

2023-06-07 17:54:09

- reply

📅 Original date posted:2016-10-21
📝 Original message:Hello Daniel and others,
A recent version of my Coin Selection Simulator is now available on my
GitHub repository:
https://github.com/Xekyo/CoinSelectionSimulator
Please feel free to write an email or open an issue on GitHub, if you
happen to find errors, have questions about using the simulator, or
(especially!) have interesting results running the simulation on your
own data.
Note that a log and a csv-table with results are posted to the console
by the simulator, so you might want to pipe that somewhere. ;)
There are probably some inefficiency issues, and user experience
improvement opportunities left as I'm currently focusing on my thesis,
yet, I've come to the conclusion that some people might be interested in
taking a look nonetheless even though I haven't gotten around to
polishing the code repository up yet.
Regards
Murch
Am 23.09.2016 um 11:11 schrieb Murch via bitcoin-dev:
> Hi Daniel,
>
> Thank you for your mail.
> My simulation of the Mycelium coin selection does add small change
> outputs to the fee, but I did get your boundary wrong.
> Instead of the 5460, I dropped at the dust boundary which calculates to
> 4440 in my simulation. Therefore, I think that the results in the table
> might be slightly too big, but likely indicative of the actual Mycelium
> behavior.
> I've corrected the boundary in my simulation now and will update my
> simulation results before Scaling Bitcoin. Thank you very much for your
> correction.
>
> Sorry, the simulation code has not been published yet, I plan to do that
> around Scaling Bitcoin or after I turn in my thesis (End of October). I
> will let you know when I do.
>
> It is my understanding that Mycelium doesn't create small change outputs
> but rather hardly ever spends them when received.
>
> You're probably more familiar with the code base (I think you work for
> Mycelium?), so please correct me when I'm wrong:
> Mycelium appears to select UTXO in a FIFO approach, but, after the
> selection, prunes by removing the smallest selected UTXO until the
> excess beyond the spending target is minimized. This post-selection step
> seems the likely reason for Mycelium's small UTXO build-up. (Bitcoin
> Core intermittenly used post-selection pruning also, and apparently this
> did cause a similar increase in UTXO set size then.)
>
> I assume that this will also cause Mycelium to create a huge transaction
> every once in a while when this build-up is enough to fund a transaction
> without a bigger UTXO being selected.
>
> As to how it may be mitigated: BreadWallet uses a very similar FIFO
> approach, but doesn't prune. My simulation result indicates that their
> average UTXO set is much smaller. This has the downside that users could
> be spammed with small transaction outputs that they then would pay for
> spending.
> A balanced approach between these two approaches might be that instead
> of pruning all small inputs, a few of the small inputs could be allowed
> to be selected to slowly drain low-value UTXO out of the wallet by
> spending them over time. In order to avoid the privacy issues such as
> e.g. always spending the oldest UTXO, it would for example be possible
> to implement this as a 75% probability to prune an unnecessary output.
>
> Regards
> Murch
>
> Am 22.09.2016 um 11:33 schrieb Daniel Weigl via bitcoin-dev:
>> Hi,
>>
>> Is your simulation code available somewhere?
>>
>> I was just wondering why mycelium generates a very big UTXO set for <1000sat, because change outputs will never be smaller than
>> 5460sat (=TransactionUtils.MINIMUM_OUTPUT_VALUE). If the change would be lower, it simply is skipped and added to the miner fee:
>> -> https://github.com/mycelium-com/wallet/blob/master/public/bitlib/src/main/java/com/mrd/bitlib/StandardTransactionBuilder.java#L334
>>
>> Does your simulation account for that?
>>
>> It might also be that the small UTXO came from external tx and we never spend them, bec. of pruning/privacy. Not sure how we could optimize that.
>>
>> Cheers,
>> Daniel
>>
>> On 2016-09-21 14:58, Murch via bitcoin-dev wrote:
>>> Hi,
>>>
>>> I'm currently compiling my Master's thesis about Coin Selection and my
>>> presentation proposal to Scaling Bitcoin has been accepted.
>>>
>>> For my thesis, I have analyzed the Coin Selection problem, created a
>>> framework to simulate wallet behavior on basis of a sequence of
>>> payments, and have re-implemented multiple coin selection strategies of
>>> prominent Bitcoin wallets (Bitcoin Core, Mycelium, Breadwallet, and
>>> Android Wallet for Bitcoin).
>>>
>>> As the Scaling Bitcoin site suggests that research should be made
>>> available to this mailing list, I would like to invite you to have a
>>> look at:
>>>
>>> http://murch.one/wp-content/uploads/2016/09/CoinSelection.pdf
>>>
>>> The PDF (176 kB) contains a two page description of my on-going work,
>>> including preliminary simulation results, and three figures showing the
>>> simulated wallets' UTXO compositions at the end of the simulation.
>>>
>>> I can provide further information as requested, and would welcome any
>>> feedback.
>>>
>>> →→ If anyone has another sequence of incoming and outgoing payment
>>> amounts at hand that I could run my simulation on, I'd love to hear
>>> about it.
>>>
>>> Regards
>>>
>>> Murch
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:53:32

- reply

📅 Original date posted:2016-09-23
📝 Original message:Hi Daniel,
Thank you for your mail.
My simulation of the Mycelium coin selection does add small change
outputs to the fee, but I did get your boundary wrong.
Instead of the 5460, I dropped at the dust boundary which calculates to
4440 in my simulation. Therefore, I think that the results in the table
might be slightly too big, but likely indicative of the actual Mycelium
behavior.
I've corrected the boundary in my simulation now and will update my
simulation results before Scaling Bitcoin. Thank you very much for your
correction.
Sorry, the simulation code has not been published yet, I plan to do that
around Scaling Bitcoin or after I turn in my thesis (End of October). I
will let you know when I do.
It is my understanding that Mycelium doesn't create small change outputs
but rather hardly ever spends them when received.
You're probably more familiar with the code base (I think you work for
Mycelium?), so please correct me when I'm wrong:
Mycelium appears to select UTXO in a FIFO approach, but, after the
selection, prunes by removing the smallest selected UTXO until the
excess beyond the spending target is minimized. This post-selection step
seems the likely reason for Mycelium's small UTXO build-up. (Bitcoin
Core intermittenly used post-selection pruning also, and apparently this
did cause a similar increase in UTXO set size then.)
I assume that this will also cause Mycelium to create a huge transaction
every once in a while when this build-up is enough to fund a transaction
without a bigger UTXO being selected.
As to how it may be mitigated: BreadWallet uses a very similar FIFO
approach, but doesn't prune. My simulation result indicates that their
average UTXO set is much smaller. This has the downside that users could
be spammed with small transaction outputs that they then would pay for
spending.
A balanced approach between these two approaches might be that instead
of pruning all small inputs, a few of the small inputs could be allowed
to be selected to slowly drain low-value UTXO out of the wallet by
spending them over time. In order to avoid the privacy issues such as
e.g. always spending the oldest UTXO, it would for example be possible
to implement this as a 75% probability to prune an unnecessary output.
Regards
Murch
Am 22.09.2016 um 11:33 schrieb Daniel Weigl via bitcoin-dev:
> Hi,
>
> Is your simulation code available somewhere?
>
> I was just wondering why mycelium generates a very big UTXO set for <1000sat, because change outputs will never be smaller than
> 5460sat (=TransactionUtils.MINIMUM_OUTPUT_VALUE). If the change would be lower, it simply is skipped and added to the miner fee:
> -> https://github.com/mycelium-com/wallet/blob/master/public/bitlib/src/main/java/com/mrd/bitlib/StandardTransactionBuilder.java#L334
>
> Does your simulation account for that?
>
> It might also be that the small UTXO came from external tx and we never spend them, bec. of pruning/privacy. Not sure how we could optimize that.
>
> Cheers,
> Daniel
>
> On 2016-09-21 14:58, Murch via bitcoin-dev wrote:
>> Hi,
>>
>> I'm currently compiling my Master's thesis about Coin Selection and my
>> presentation proposal to Scaling Bitcoin has been accepted.
>>
>> For my thesis, I have analyzed the Coin Selection problem, created a
>> framework to simulate wallet behavior on basis of a sequence of
>> payments, and have re-implemented multiple coin selection strategies of
>> prominent Bitcoin wallets (Bitcoin Core, Mycelium, Breadwallet, and
>> Android Wallet for Bitcoin).
>>
>> As the Scaling Bitcoin site suggests that research should be made
>> available to this mailing list, I would like to invite you to have a
>> look at:
>>
>> http://murch.one/wp-content/uploads/2016/09/CoinSelection.pdf
>>
>> The PDF (176 kB) contains a two page description of my on-going work,
>> including preliminary simulation results, and three figures showing the
>> simulated wallets' UTXO compositions at the end of the simulation.
>>
>> I can provide further information as requested, and would welcome any
>> feedback.
>>
>> →→ If anyone has another sequence of incoming and outgoing payment
>> amounts at hand that I could run my simulation on, I'd love to hear
>> about it.
>>
>> Regards
>>
>> Murch
>>
>>
>>
>>
>> _______________________________________________
>> 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 17:53:31

- reply

📅 Original date posted:2016-09-21
📝 Original message:Hi,
I'm currently compiling my Master's thesis about Coin Selection and my
presentation proposal to Scaling Bitcoin has been accepted.
For my thesis, I have analyzed the Coin Selection problem, created a
framework to simulate wallet behavior on basis of a sequence of
payments, and have re-implemented multiple coin selection strategies of
prominent Bitcoin wallets (Bitcoin Core, Mycelium, Breadwallet, and
Android Wallet for Bitcoin).
As the Scaling Bitcoin site suggests that research should be made
available to this mailing list, I would like to invite you to have a
look at:
http://murch.one/wp-content/uploads/2016/09/CoinSelection.pdf
The PDF (176 kB) contains a two page description of my on-going work,
including preliminary simulation results, and three figures showing the
simulated wallets' UTXO compositions at the end of the simulation.
I can provide further information as requested, and would welcome any
feedback.
→→ If anyone has another sequence of incoming and outgoing payment
amounts at hand that I could run my simulation on, I'd love to hear
about it.
Regards
Murch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160921/56ec5d2a/attachment.sig>