Hi Daniel,
Not sure which PRs are you talking about, maybe you missed these points based
on your understanding:
Lot of fancy things won't work in windows shortcut target
It is more suspicious even if you try, compared to something wrapped in *notify
options provided by bitcoin core
This will
I've looked at these PR's and they seem, frankly, bizarre.
You've essentially noticed that if an attacker can run commands on your system,
they can run commands on your system.
If you can convince someone to run arbitrary commands, which is what a desktop
shortcut or a command argument _is_ at
Hello World,
What?
Remove all *notify options from Bitcoin Core (full node implementation used by
99% nodes)
Or one of the below:
notifications.dat
not use system() in runCommand()
Use a new setting in settings.json file, notifypolicy which is 0 by default
(restricted) and can be set to 1
Happy new years devs,
I figured I would share some thoughts for conceptual review that have been
bouncing around my head as an opportunity to clean up the fee paying
semantics in bitcoin "for good". The design space is very wide on the
approach I'll share, so below is just a sketch of how it
> If you don't like the reduction of the block subsidy, well that's a much
> bigger problem.
It is reversible, because you can also increase the block subsidy by using
another kind of soft-fork. For example, you can create spendable outputs with
zero satoshis. In this way, old nodes will accept
