<unnamed>

Public Key

npub1jjaydndmznp5g07v9cf83dq6667rdgk4j52f662qv5k6klsky53sruchtw

Profile Code

nprofile1qqsffwjxeka3fs6y8lxzuyncksddd0pk5t2e29yad9qx2tdt0ctz2gcpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet5qydhwumn8ghj7un9d3shjtnsda3kket5dehhxarj9e3k7mgpr9mhxue69uhhyetvv9ujuur0vd4k2arnw3ezucm0d58rgcvp

Publishing to

nos.lol

relay.damus.io

relay.primal.net

relay.pocketnostr.com

relay.pocketstr.com

Last Notes

2023-06-07 17:55:27 UTC

- 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:46:48 UTC

- 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 UTC

- 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.