<unnamed>

Public Key

npub1yvcp7ayqy5xa3qgtz9hj9hdn5c9shp6tuvrxu3tw99qj6dveq2csqu4zp6

Profile Code

nprofile1qqszxvqlwjqz2rwcsy93zmezmke6vzctsa97xpnwg4hzjsfdxkvs9vgpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqrzw979

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-08 01:10:05 CEST

- reply

📅 Original date posted:2022-06-12
📝 Original message:Even if demand for block space is currently not needed to pay for security
due to the block rewards, demand for BTC itself is needed for those rewards
to be worth anything.
Bitcoin, as a proof of work system, is only secure at scale. Therefore
continued growth and user adoption are both critical for Bitcoin's
security. Perhaps the question then becomes
who feels that Bitcoin is inevitable, and who feels it is possible that it
can damaged or destroyed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220612/cd752803/attachment.html>

2023-06-08 01:07:50 CEST

- reply

📅 Original date posted:2022-04-22
📝 Original message:>*A change that increases the number of use cases of Bitcoin affects all
users and is *not* non-invasive. More use cases means more blockchain usage
which increases the price of a transaction for *everyone*.*
This manages to be both incorrect and philosophically opposed to what
defines success of the project . Neither the number of ways that people
figure out how to innovatively harness Bitcoin's existing capabilities, nor
the number or complexity of any optional transaction types that the Bitcoin
protocol supports have any bearing on transaction fees. Demand for
blockspace from transactions, which is just plain *use* - and not *use
cases* - is what could drive up transaction fees.
On the philosophical level, as designers of the system, we all hope and
work to make Bitcoin so useful, appealing, and secure that there is massive
demand for blockspace, even in the face of high transaction fees. As an
individual thinking only of their next on-chain transaction, it is
understandable that one might hope for low fees and partially-filled
blocks. Longer term, the health of the system can both be measured by and
itself depends on high transaction demand and fee pressure.
If you were trying to argue that CTV is invasive because it may increase
transaction demand and therefore cost users more fees, that is 1) an
endorsement of CTV's desirability and 2) reveals that you consider any
increased free-market competition (i.e. more demand) to be "invasive".
*>I like the maxim of Peter Todd: any change of Bitcoin must benefit *all*
users. *
As for Peter Todd's "any change of Bitcoin must benefit *all* users", that
is absolutely a reasonable thing to consider. However, in order to make
practical use of that maxim, we must adopt in our minds a *generic*, or
"model user", and then replicate them so that we may meaningfully
understand a least a proxy for "all users". In reality, there will always
be someone (and at this point, probably a "user" too) who wouldn't benefit
from a change, or at least think they won't. Some users of Bitcoin may even
want Bitcoin to fail, so we cannot afford assume that people have alignment
of goals or vision just by virtue of being a 'user'.
Corey
> _______________________________________________
> 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/20220422/4cbf6200/attachment-0001.html>

2023-06-07 19:52:55 CEST

- reply

📅 Original date posted:2016-08-28
📝 Original message:*One of my biggest fears about using any wallet is the "whoops, cosmic ray
flipped a bit while producing receiving address; SFYL!" possibility. For
high value cold storage, I always generate my addresses on two independent
machines using two different pieces of software. Am I nuts for doing that?*
A randomly flipped bit would be extremely unlikely to yield a valid
address, however, I still think it you are wise to use independent routes
to confirm that your addresses match the keys. I do the same when I
generating my cold storage key pairs. I think malicious address
substitution is an under appreciated attack vector.
Regarding this thread in general, would it make sense for this proposal to
include standards for multi-sig wallet interoperability? A whole spectrum
of attacks would be made less likely - and easy for typical users to guard
against - by using wallets on separate devices AND where the wallet
software was written and provided by different parties.
On Mon, Aug 22, 2016 at 9:50 AM, Moral Agent via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> It would be nice if the detached signer and the normal wallet could both
> verify the correctness of generated addresses before you cause coins to be
> sent there.
>
> e.g. the hardware wallet could give its master public key to Bitcoin Core
> and you can thereafter generate your receiving addresses on Core, with the
> option to have the HW wallet validate them.
>
> One of my biggest fears about using any wallet is the "whoops, cosmic ray
> flipped a bit while producing receiving address; SFYL!" possibility. For
> high value cold storage, I always generate my addresses on two independent
> machines using two different pieces of software. Am I nuts for doing that?
>
> With the above scheme, you are pretty well protected from losing money if
> your HW wallet is defective. You could still lose it if the HW wallet was
> evil of course, but that strikes me as much more likely to be discovered
> quickly.
>
> _______________________________________________
> 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/20160828/65c0f30a/attachment.html>

2023-06-07 19:49:36 CEST

- reply

📅 Original date posted:2016-03-03
📝 Original message:Since the root cause of what you are trying to address is the reward
having, I'd suggest considering an adjustment to the having schedule.
Instead of their being a large supply shock every four years, perhaps the
reward could drop every 52,500 blocks (yearly), or even at each difficulty
adjustment, in such a way that the inflation curve is smoothed out. The
exponential decay rate would be preserved, so overall economic philosophy
would be preserved.
I'm guessing hesitance to this approach would lie in a reluctance to tinker
with Bitcoin's 'economic contract', and slippery slope concerns about might
be the next change (21M?). However, I think it could actually increase
confidence in the system if the community is able to demonstrate a good
process for making such decisions, and show that we can separate the
meaningful underlying principles, such as the coin limit and overall
inflation rate, from what is more akin to an implementation detail, as I
consider the large-step reward reduction to be.
I'm not too worried about the impact of the having as is, but adjusting the
economic parameter would be a safer and simpler way to address the concerns
than to tinker with the difficulty targeting mechanism, which is at the
heart of Bitcoin's security
On Wed, Mar 2, 2016 at 6:56 AM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> We are coming up on the subsidy halving this July, and there have been some
> concerns raised that a non-trivial number of miners could potentially drop
> off
> the network. This would result in a significantly longer block interval,
> which
> also means a higher per-block transaction volume, which could cause the
> block
> size limit to legitimately be hit much sooner than expected. Furthermore,
> due
> to difficulty adjustment being measured exclusively in blocks, the time
> until
> it adjusts to compensate would be prolonged.
>
> For example, if 50% of miners dropped off the network, blocks would be
> every
> 20 minutes on average and contain double the transactions they presently
> do.
> Even double would be approximately 850-900k, which potentially bumps up
> against the hard limit when empty blocks are taken into consideration. This
> situation would continue for a full month if no changes are made. If more
> miners drop off the network, most of this becomes linearly worse, but due
> to
> hitting the block size limit, the backlog would grow indefinitely until the
> adjustment occurs.
>
> To alleviate this risk, it seems reasonable to propose a hardfork to the
> difficulty adjustment algorithm so it can adapt quicker to such a
> significant
> drop in mining rate. BtcDrak tells me he has well-tested code for this in
> his
> altcoin, which has seen some roller-coaster hashrates, so it may even be
> possible to have such a proposal ready in time to be deployed alongside
> SegWit
> to take effect in time for the upcoming subsidy halving. If this slips, I
> think it may be reasonable to push for at least code-readiness before July,
> and possibly roll it into any other hardfork proposed before or around that
> time.
>
> I am unaware of any reason this would be controversial, so if anyone has a
> problem with such a change, please speak up sooner rather than later. Other
> ideas or concerns are of course welcome as well.
>
> Thanks,
>
> Luke
> _______________________________________________
> 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/20160303/89c572a7/attachment-0001.html>

2023-06-07 19:48:46 CEST

- reply

📅 Original date posted:2016-02-07
📝 Original message:We don't have any evidence of how fast nodes will upgrade when faced with
an impending hard fork, but it seems like a very safe assumption that the
upgrade pace will be significantly faster. The hard fork case it is:
"upgrade or be kicked off the network". In the previous cases it has been,
"here's the latest and greatest, give it a go!". Also, there will be
alerts sent out warning people of the situation, prompting them to take
action.
It is unclear if this will translate into more or less than 6x the adoption
speed of previous instances, but the idea that it would be faster is
solid. 28 days is aggressive, but again, it is only 28 days from when the
fork triggers. Compatible software is already available for anyone who
wants to prepare.
It is also of significance that this proposed fork, and this debate, has
been going on for many, many months. If someone proposed a forking concept
today, wrote the BIP tomorrow, deployed it next week, miners adopted it
instantly, and 28 days later it was the flag day, those 28 days would be in
a different context. There is no surprise here.
On Sun, Feb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Is it me or did Gavin ignore Yifu's direct questions? In case you missed
> it Gavin --
>
> ~
> "We can look at the adoption of the last major Bitcoin core release to
> guess how long it might take people to upgrade. 0.11.0 was released on 12
> July, 2015. Twenty eight days later, about 38% of full nodes were running
> that release. Three months later, about 50% of the network was running
> that release, and six months later about 66% of the network was running
> some flavor of 0.11."
>
> On what grounds do you think it is reasonable to assume that this update
> will roll out 6x faster than previous data suggested, as oppose to your own
> observation of 66% adoption in 6 month. or do you believe 38% node
> upgrade-coverage (in 28 days ) on the network for a hard fork is good
> enough?
>
> There are no harm in choosing a longer grace period but picking one short
> as 28 days you risk on alienating the nodes who do not upgrade with the
> aggressive upgrade timeline you proposed.
> ~~
>
> When Gavin writes "Responding to "28 days is not long enough" :
>
> I keep seeing this claim made with no evidence to back it up. As I said,
> I surveyed several of the biggest infrastructure providers and the btcd
> lead developer and they all agree "28 days is plenty of time."
>
> For individuals... why would it take somebody longer than 28 days to
> either download and restart their bitcoind, or to patch and then re-run
> (the patch can be a one-line change MAX_BLOCK_SIZE from 1000000 to
> 2000000)?"
>
> ~~
>
> Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
> propositional a priori logic, but empirical evidence that. As for why
> people take longer, who knows, we simply know from passed experience that
> it in fact does take longer.
>
> It's extremely frustrating to read Gavin's comments, it's hard to believe
> he is engaging in earnest discussion.
>
> On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
>> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
>> > bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
>> wrote:
>> > > > If you have a node that is "old" your node will stop getting new
>> > > > blocks. The node will essentially just say "x-hours behind" with "x"
>> > > > getting larger every hour. Funds don't get confirmed. etc.
>> > >
>> > > Until someone decides to attack you. Then you'll get 6, 10, maybe more
>> > > blocks confirming a large 10000 BTC payment. If you're just a normal
>> end
>> > > user (or perhaps an automated system), you'll figure that payment is
>> good
>> > > and irreversibly hand over the title to the house.
>> >
>> > There will be approximately zero percentage of hash power left on the
>> > weaker branch of the fork, based on past soft-fork adoption by miners
>> (they
>> > upgrade VERY quickly from 75% to over 95%).
>>
>> I'm assuming there are literally ZERO miners left on the weaker branch.
>> The attacker in this scenario simply rents hashing for a few days in
>> advance
>> to build his fake chain, then broadcasts the blocks to the unsuspecting
>> merchant at ~10 block intervals so it looks like everything is working
>> normal
>> again. There are lots of mining rental services out there, and miners
>> quite
>> often do not care to avoid selling hashrate to the highest bidder
>> regardless
>> of what they're mining. 10 blocks worth costs a little more than 250 BTC -
>> soon, that will be 125 BTC.
>>
>> Luke
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> Steven Pine
> (510) 517-7075
>
> _______________________________________________
> 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/20160207/db587ac0/attachment.html>

2023-06-07 19:46:34 CEST

- reply

📅 Original date posted:2015-12-17
📝 Original message:A planned hardfork, similar to certain softforks, leaves users with some
reduction in security. It does not leave them defenseless. Consider the
following:
1: Hard to be robbed on the basis of hashpower.
In reality the old chain will see mining all but stop, and blocks would be
hours to days apart even if a couple percentage points of hashpower failed
to switch over. Six confirmations would certainly take days. If the fork
can be scheduled at the beginning of a difficulty period, the old chain
would almost certainly not even ever make it to the next retargeting.
2: Hard to be robber on the basis of awareness.
Expect there to be fairly widespread coverage in the Bitcoin press, and as
the fork draws near, maybe coverage in business and tech publications.
Further, the alert keys will certainly be used, so node operators will get
the message directly.
3: There still needs to be a targeted attack by a fraudster on an unaware
node operator.
To fall victim, one needs to give up something of value to an attacker in
exchange for Bitcoins (on the old chain). The typical uninitiated
full-node user (probably a small subset anyway) is typically going to be
buying bitcoin from a trusted source, and then saving or spending them, or
perhaps gambling. They are not, typically, going to be providing a service
or selling goods in exchange for Bitcoin unless they are at least somewhat
aware of what is going on in the Bitcoin space. It's possible, of course,
but we are talking about small numbers here of people who fit the above.
All three parts of the above would have to go perfectly wrong for someone
to loose out. Someone somewhere will probably get scammed as a result of a
hardfork. That stinks, and we should make reasonable efforts to help them
avoid that fate. But at this point in Bitcoin's development, it is still
in beta, it's still an economic experiment, and we can't allow the software
to become hamstrung out of fear that some inattentive user might bungle
their security. If they merely waited for 6 confirmations, as is the
standard advice, they would be waiting for days. If that along doesn't
give them a hint that something is wrong, it might still be too early days
for them to be playing with Bitcoin for anything important.
I support a hardfork deployment that takes 80% of hashpower activate + a
4-month delay.
On Wed, Dec 16, 2015 at 9:32 PM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There are at least 2 proposals on the table:
>
> 1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately
> equals to 2MB actual limit
>
> 2. BIP102: 2MB actual limit
>
> Since the actual limits for both proposals are approximately the same, it
> is not a determining factor in this discussion
>
> The biggest advantage of SWSF is its softfork nature. However, its
> complexity is not comparable with any previous softforks we had. It is
> reasonable to doubt if it could be ready in 6 months
>
> For BIP102, although it is a hardfork, it is a very simple one and could
> be deployed with ISM in less than a month. It is even simpler than BIP34,
> 66, and 65.
>
> So we have a very complicated softfork vs. a very simple hardfork. The
> only reason makes BIP102 not easy is the fact that it's a hardfork.
>
> The major criticism for a hardfork is requiring everyone to upgrade. Is
> that really a big problem?
>
> First of all, hardfork is not a totally unknown territory. BIP50 was a
> hardfork. The accident happened on 13 March 2013. Bitcoind 0.8.1 was
> released on 18 March, which only gave 2 months of grace period for everyone
> to upgrade. The actual hardfork happened on 16 August. Everything completed
> in 5 months without any panic or chaos. This experience strongly suggests
> that 5 months is already safe for a simple hardfork. (in terms of
> simplicity, I believe BIP102 is even simpler than BIP50)
>
> Another experience is from BIP66. The 0.10.0 was released on 16 Feb 2015,
> exactly 10 months ago. I analyze the data on https://bitnodes.21.co and
> found that 4600 out of 5090 nodes (90.4%) indicate BIP66 support.
> Considering this is a softfork, I consider this as very good adoption
> already.
>
> With the evidence from BIP50 and BIP66, I believe a 5 months
> pre-announcement is good enough for BIP102. As the vast majority of miners
> have declared their support for a 2MB solution, the legacy 1MB fork will
> certainly be abandoned and no one will get robbed.
>
>
> My primary proposal:
>
> Now - 15 Jan 2016: formally consult the major miners and merchants if they
> support an one-off rise to 2MB. I consider approximately 80% of mining
> power and 80% of trading volume would be good enough
>
> 16 - 31 Jan 2016: release 0.11.3 with BIP102 with ISM vote requiring 80%
> of hashing power
>
> 1 Jun 2016: the first day a 2MB block may be allowed
>
> Before 31 Dec 2016: release SWSF
>
>
>
> My secondary proposal:
>
> Now: Work on SWSF in a turbo mode and have a deadline of 1 Jun 2016
>
> 1 Jun 2016: release SWSF
>
> What if the deadline is not met? Maybe pushing an urgent BIP102 if things
> become really bad.
>
>
> In any case, I hope a clear decision and road map could be made now. This
> topic has been discussed to death. We are just bringing further uncertainty
> if we keep discussing.
>
>
> Matt Corallo via bitcoin-dev 於 2015-12-16 15:50 寫到:
>
>> A large part of your argument is that SW will take longer to deploy
>> than a hard fork, but I completely disagree. Though I do not agree
>> with some people claiming we can deploy SW significantly faster than a
>> hard fork, once the code is ready (probably a six month affair) we can
>> get it deployed very quickly. It's true the ecosystem may take some
>> time to upgrade, but I see that as a feature, not a bug - we can build
>> up some fee pressure with an immediate release valve available for
>> people to use if they want to pay fewer fees.
>>
>> On the other hand, a hard fork, while simpler for the ecosystem to
>> upgrade to, is a 1-2 year affair (after the code is shipped, so at
>> least 1.5-2.5 from today if we all put off heads down and work). One
>> thing that has concerned me greatly through this whole debate is how
>> quickly people seem to think we can roll out a hard fork. Go look at
>> the distribution of node versions on the network today and work
>> backwards to get nearly every node upgraded... Even with a year
>> between fork-version-release and fork-activation, we'd still kill a
>> bunch of nodes and instead of reducing their security model, lead them
>> to be outright robbed.
>>
>>
> _______________________________________________
>
> 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/20151216/5e55d210/attachment.html>