Ferdinando M. Ametrano [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-10-28 to 2020-11-16
💬 Posted a total of 7 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:27:34

- reply

📅 Original date posted:2020-11-16
📝 Original message:After having checked that the BIP174 test vectors do not cover the
*proprietary* and *proof-of-reserves* types, I went ahead and submitted a
PR to the bips repo for the removal of those fields from the PSBT
specifications
https://github.com/bitcoin/bips/pull/1038
--
*Ferdinando M. Ametrano*
www.ametrano.net/about
On Tue, Nov 17, 2020 at 12:01 AM Ferdinando M. Ametrano <
ferdinando at ametrano.net> wrote:
> Hi all,
>
> While implementing PSBT support in the *btclib* library (
> https://github.com/btclib-org/btclib), I have failed to understand the
> rationale for the *proprietary* and *proof-of-reserves* types.
>
> First off, at face value they have nothing to do with the operations
> intrinsically required to finalize a valid transaction from PSBT
> manipulation.
>
> Moreover, whatever information content they can provide for non-standard
> PSBT manipulation, that content could stay in the *unknown* field without
> any loss of generality. How to structure and deal with unknown data would
> be the responsibility of proprietary software or users wanting to provide
> proof-of-reserve. As long as BIP174 clearly prescribes that unknown data
> must be kept during PSBT manipulation, that should be enough.
>
> Let me stress the above point: I have a project where we include
> proprietary information in the PSBT. Any PSBT software supporting unknown
> data gently keeps our proprietary information and our proprietary software
> retrieves that data from serialized PSBT with no problem. There is no need
> for a PSBT implementation to provide explicit support for *proprietary*
> and *proof-of-reserves* types.
>
> My last conclusion is reinforced by the evidence of all PSBT
> implementations I know of, including bitcoin core and HWI, not implementing
> proprietary and proof-of-reserve types. There is a high probability that
> part of BIP174 would be just ignored.
>
> Am I missing something?
>
> Thanks
> --
> *Ferdinando M. Ametrano*
> www.ametrano.net/about
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201117/3fe0ccf0/attachment.html>

2023-06-07 18:27:34

- reply

📅 Original date posted:2020-11-16
📝 Original message:Hi all,
While implementing PSBT support in the *btclib* library (
https://github.com/btclib-org/btclib), I have failed to understand the
rationale for the *proprietary* and *proof-of-reserves* types.
First off, at face value they have nothing to do with the operations
intrinsically required to finalize a valid transaction from PSBT
manipulation.
Moreover, whatever information content they can provide for non-standard
PSBT manipulation, that content could stay in the *unknown* field without
any loss of generality. How to structure and deal with unknown data would
be the responsibility of proprietary software or users wanting to provide
proof-of-reserve. As long as BIP174 clearly prescribes that unknown data
must be kept during PSBT manipulation, that should be enough.
Let me stress the above point: I have a project where we include
proprietary information in the PSBT. Any PSBT software supporting unknown
data gently keeps our proprietary information and our proprietary software
retrieves that data from serialized PSBT with no problem. There is no need
for a PSBT implementation to provide explicit support for *proprietary* and
*proof-of-reserves* types.
My last conclusion is reinforced by the evidence of all PSBT
implementations I know of, including bitcoin core and HWI, not implementing
proprietary and proof-of-reserve types. There is a high probability that
part of BIP174 would be just ignored.
Am I missing something?
Thanks
--
*Ferdinando M. Ametrano*
www.ametrano.net/about
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201117/0e8032c8/attachment.html>

2023-06-07 15:27:02

- reply

📅 Original date posted:2014-10-28
📝 Original message:On Tue, Oct 28, 2014 at 11:00 PM, Thomas Zander <thomas at thomaszander.se>
wrote:
> you didn't read the
> archives where these ideas have been brought forward and discussed, a
> consensus was reached. (it wasn't so basic afterall)
> The fact that people don't want to repeat the discussion just for your
> sake is
> not the same as people not listening to those arguments.
I didn't start the thread and so didn't research the archive. Until two
posts ago there was no reference about the issue being discussed before. A
link would have been much kinder than harsh dismissal. I will research and
read.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/7900e3d4/attachment.html>

2023-06-07 15:27:02

- reply

2023-06-07 15:27:01

- reply

📅 Original date posted:2014-10-28
📝 Original message:> > In november 2008 bitcoin was a much younger ecosystem,
>
> Or very old, indeed, if you are using unsigned arithmetic. [...]
>
:-) I meant 2012, of course, but loved your wit
> > and the halving happened during a quite stable positive price trend
>
> Hardly,
>
>
> http://bitcoincharts.com/charts/mtgoxUSD#rg60zczsg2012-10-01zeg2012-12-01ztgSzm1g10zm2g25zv
indeed!
http://bitcoincharts.com/charts/mtgoxUSD#rg60zczsg2012-08-01zeg2013-02-01ztgSzm1g10zm2g25zv
> There is a lot more complexity to the system than the subsidy schedule.
>
who said the contrary?
This thread is, in my opinion, a waste of time.
>
it might be, I have some free time right now...
many people have performed planning around the current
> behaviour. The current behaviour has also not shown itself to be
> problematic (and we've actually experienced its largest effect already
> without incident), and there are arguable benefits like encouraging
> investment in mining infrastructure.
>
I would love a proper rebuttal of a basic economic argument. If increased
competition will push mining revenues below 200% of operational costs, then
the halving will suddenly switch off many non profitable mining resources.
As of now the cost per block is probably already about 100USD, probably in
the 50-150USD.
Dismissed mining resources might even become cheaply available for
malevolent agents considering a 51% attack. Moreover the timing would be
perfect for the burst of any existing cloud hashing Ponzi scheme.
>From a strict economic point of view allowing the halving jump is looking
for trouble. To each his own.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/c85c0aa9/attachment.html>

2023-06-07 15:27:01

- reply

📅 Original date posted:2014-10-28
📝 Original message:On Tue, Oct 28, 2014 at 10:34 PM, Neil <kyuupichan at gmail.com> wrote:
> Economically a halving is almost the same as a halving in price (as fees
> take up more of the pie, less so).
>
> Coincidentally the price has halved since early July to mid-October, and
> we've not even seen difficulty fall yet.
>
because mining profits are many times operational costs. This might change
because of competition, in that case halving in price will become
problematic.
It amazes me that basic economic considerations seems completely lost here,
especially when it comes to mining. We should have learned the lesson of
how a small error in the incentive structure has lead from "one CPU, one
vote" to an oligopoly which might easily become a monopoly in the near
future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/236689cb/attachment.html>

2023-06-07 15:27:01

- reply

2023-06-07 15:27:01

- reply

2023-06-07 15:27:00

- reply

📅 Original date posted:2014-10-28
📝 Original message:On Tue, Oct 28, 2014 at 10:43 PM, Gregory Maxwell <gmaxwell at gmail.com>
wrote:
> > As of now the cost per block is probably already about 100USD, probably
> in
> > the 50-150USD.
>
> This is wildly at odds with reality. I don't mean to insult, but
> please understand that every post you make here consumes the time of
> dozens (or, hopefully, hundreds) of people. Every minute you spend
> refining your post has a potential return of many minutes for the rest
> of the users of the list.
>
> At current difficulty, with a SP30 (one of the
> leading-in-power-efficiency) marginal break-even is ~1144.8852 * $/kwh
> == $/btc.
>
> At $0.10/kwh each block has an expected cost right now, discounting
> all one time hardware costs, close to $3000.
>
yes, you're right I meant about $100USD per BTC, i.e. $2500 per block.
Because of my mistake I'll shut up and go back researching the archive on
this issue.
Thank you for the kind summary of the many good reasons why halving is a
non-issue. Very much appreciated, especially considering how precious is
your time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/2e7c0fc3/attachment.html>

2023-06-07 15:27:00

- reply

2023-06-07 15:26:47

- reply

📅 Original date posted:2014-10-28
📝 Original message:On Oct 25, 2014 9:19 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
> We had a halving, and it was a non-event.
> Is there some reason to believe next time will be different?
In november 2008 bitcoin was a much younger ecosystem, with less liquidity
and trading, smaller market cap, and the halving happened during a quite
stable positive price trend.
In the next months competition might easily drive down mining margins, and
the reward halving might generate unexpected disruption in mining
operations.
Moreover, halving is not strictly necessary to respect the spirit of
Nakamoto's monetary rule and its 21M limit. At the beginning of the 3rd
reward era (block 420000, in 2017) a new reward function could become
effective R(b)=k*2^(-h*b/210000) where b is the block number and R(b) is
the reward. The parameters h and k can be calibrated so that R(419999)=25
and sum_b{R}=21M
If the increased issuance speed in the third era is considered
problematic, then each era could have its own R_e(b)=k_e*2^(-h_e*b/210000)
fitted to the amount of coins to be issued in that era according to the
current supply rule, e.g. fitting k_e and h_e to R(419999)=25 and
sum_{b}_e=2,625,000.
Would such a BIP have any chance to be considered? Am I missing something?
Nando
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/c338fcc4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: btc-blkzoomed (1).png
Type: image/png
Size: 18254 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/c338fcc4/attachment.png>