Chris [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-11-30 to 2019-07-26
💬 Posted a total of 8 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-06-07 18:19:38

- reply

📅 Original date posted:2019-07-26
📝 Original message:On 7/23/19 10:47 AM, Andreas Schildbach via bitcoin-dev wrote:
> 3) Afaik, it enforces/encourages address re-use. This stems from the
> fact that the server decides on the filter and in particular on the
> false positive rate. On wallets with many addresses, a hardcoded filter
> will be too blurry and thus each block will be matched. So wallets that
> follow the "one address per incoming payment" pattern (e.g. HD wallets)
> at some point will be forced to wrap their key chains back to the
> beginning. If I'm wrong on this one please let me know.
Maybe someone who knows better can confirm but I thought I read the the
fp rate on the filter was chosen assuming a wallet would average a
certain number of addresses (ie, they assumed use of an HD wallet). Your
criticism might be valid for wallets that well exceed the average.

2023-06-07 18:02:05

- reply

📅 Original date posted:2017-06-01
📝 Original message:On 06/01/2017 06:10 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
> One aspect which isn't in this BIP draft is direct support for unconfirmed
> transactions. I consider such a feature an important UX feature for mobile
> phones, and something which I've personally seen as an important
> UX-experience when on-boarding new users to Bitcoin.
Totally agree. My first thought is maybe you could keep bip37 filtering
as optional for unconfirmed transactions. Since you're only interested
in incoming transactions in this case you can create one big filter with
all your wallet's addresses and reuse that filter. The bip37 privacy
issues mainly come up when trying to get the filter to match both
incoming and outgoing transactions, which is not needed in this case.
Otoh, if you download the block from the same peer that you gave a bip37
filter then they could probably test the txs in the block against both
filters. :/

2023-06-07 17:55:27

- reply

📅 Original date posted:2017-01-09
📝 Original message:Maybe I was too premature. The script wiki (which I realize might not be
up to date) says only one pushdata is allowed but I don't see that in
the code.
https://github.com/bitcoin/bitcoin/blob/e8cfe1ee2d01c493b758a67ad14707dca15792ea/src/policy/policy.cpp#L49
Am I missing something or am I correct to assume that multiple pushdatas
in op_return would normally be considered standard?
On 01/08/2017 10:08 PM, Luke Dashjr wrote:
> On Monday, January 09, 2017 2:09:09 AM Chris via bitcoin-dev wrote:
>> Would there be an objection to making op_return outputs with two
>> pushdatas standard (same max data size)?
> Standards (BIPs) need to describe a specific use case and protocol for doing
> it.
>
> As you note, the default policy on most nodes is to allow such outputs.
>
> Luke
>

2023-06-07 17:55:27

- reply

📅 Original date posted:2017-01-09
📝 Original message:Would there be an objection to making op_return outputs with two
pushdatas standard (same max data size)?
Use case is mostly tagging transactions so they can be returned by bloom
filtering nodes:
OP_RETURN <tag> <data>
Since bip37 nodes test each data element in each output script (which I
believe applies to op_return as well?) it provides a lightweight way of
fetching transactions where the tag matches a specific pattern.
It appears a sizable number of nodes/miners already accept such
transactions as this one was mined in the first block...
https://blockchain.info/tx/400b4738f1e4eab4062e085623b9a3a71670f5c0d42e32dbe5a4e71da5baabe0
- Chris

2023-06-07 17:50:00

- reply

📅 Original date posted:2016-03-24
📝 Original message:Thanks for doing some work on this Jonas. It's something I've been
interested in for a while. I haven't had an opportunity to read the bips
but I will do so soon and comment.
As far as the use cases others mentioned, connecting and SPV wallet to
your full node is certainly one. It would make it easy to, say, connect
the android bitcoin-wallet to your own node. I've hacked on that wallet
to make it connect to my .onion node, but it's very slow border-line
unusable. Basic encryption and authentication would make that viable.
Also, while bloom filtering in bitcoinj is broken, it could be fixed by
just creating a single filter and filling it with 1000 addresses and
persisting it to disk. The main issue is you can't restore from seed
that way and would have to revert to what bitcoinj does now and blow
your privacy. If you had the ability to make an encrypted connection to
a trusted node just for restoring from seed, you could save your privacy
during a restore.
On 03/23/2016 11:24 AM, Jonas Schnelli via bitcoin-dev wrote:
>
>
> _______________________________________________
> 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/20160324/d7789436/attachment.html>

2023-06-07 17:46:48

- reply

📅 Original date posted:2015-12-18
📝 Original message:On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org
<mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> 2) The risk of an old full node wallet accepting a transaction whose
> coins passed through a script that depends on the softforked rules.
>
There's that, but there's also a case where an attacker creates a
majority chain that follows the old rules but not the new ones.
Non-upgraded nodes would accept a transaction on what they believe to be
the consensus chain only to find that when they try to spend those coins
no one accepts them because they were part of an invalid chain.
This has the effect of dropping non upgraded nodes to a form of spv
security without their consent.
This is in contrast to a hard fork where a full node operator could
explicitly set their node to accept higher version blocks that it can't
validate. They get the soft fork functionality back but they have at
least consented to it rather than have it forced on them. Doing forks
that way would also have the benefit of notifying the user they are
accepting unvalidated coins, whereas they wont know that in a soft fork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/94b6565b/attachment.html>

2023-06-07 17:45:47

- reply

📅 Original date posted:2015-12-09
📝 Original message:On 12/08/2015 10:12 AM, Gavin Andresen via bitcoin-dev wrote:
> Why segwitness as a soft fork? Stuffing the segwitness merkle tree in
> the coinbase is messy and will just complicate consensus-critical code
> (as opposed to making the right side of the merkle tree in
> block.version=5 blocks the segwitness data).
Agreed. I thought the rule was no contentious hark forks. It seems
hardly anyone opposes this change and there seems to be widespread
agreement that the hardfork version would be much cleaner.

2023-06-07 17:45:03

- reply

📅 Original date posted:2015-11-30
📝 Original message:On 11/16/2015 07:42 PM, Peter Todd via bitcoin-dev wrote:
> Sequence is used for opting in as it is the only "free-form" field
> available for that purpose. Opt-in per output was proposed as well by
> Luke-Jr, however the CTxOut data structure simply doesn't contain any
> extra fields to use for that purpose.
What is wrong with using they same scheme as sighash_single?
If input 0 has nSequence < maxint-1 then output 0 is replaceable.
For fee bumps you would just stick the change in position zero and
reduce the value.
You get FFS functionality without the hassle of addition other inputs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151129/dc16d383/attachment.html>