Jannis Froese [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-04-20 to 2014-06-04
💬 Posted a total of 5 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:22:18

- reply

📅 Original date posted:2014-06-04
📝 Original message:There are reasons to have assertions enabled by default in software like
Bitcoin Core, where incorrect behaviour can be costly. But this comes at
a prize: our assertions have to satisfy certain performance
requirements. It's no longer possible to do expensive, redundant checks
in performance critical code, which is one of the main advantages of
asserts. Imho, asserts are not intended for small range checks etc, but
are meant for checks that a hash hasn't changed, that a tree structure
is still a tree, that data is still sorted, or that data structures are
in sync.
I think most concerns about the current use of asserts would be resolved
if the currently used asserts would be changed to a nicer definition
which is independent of NDEBUG, and a second class of debugging asserts
would be introduced, which is exclusively for expensive, redundant
checks and is disabled by NDEBUG.
Am 2014-06-04 12:15, schrieb Gregory Maxwell:
> On Wed, Jun 4, 2014 at 2:51 AM, Mike Hearn <mike at plan99.net
> <mailto:mike at plan99.net>> wrote:
>
> Hi Ron,
>
> FYI your mail is being spamfoldered due to Yahoo's DMARC policy
> and the brokenness of the SF.net mailing list software. I would
> not expect to get replies reliably whilst this is the case. I
> think we should move away from SF.net for hosting mailing lists
> personally, because it's this list that's at fault not Yahoo, but
> until then you may wish to send to the list with a different email
> address.
>
> As to your question,
>
> assert() should have *no* side effects, that is the problem.
>
> See
> http://books.google.com/books?id=L5ZbzVnpkXAC&pg=PA72&lpg=PA72&dq=Gotcha+%2328+Side+Effects&source=bl&ots=Rn15TlPmje&sig=tymHqta0aSANwaM2GaXC-1Di_tk&hl=en&sa=X&ei=uVKNU47fCcvTsAT6goHIBA&ved=0CCAQ6AEwAA#v=onepage&q=Gotcha%20%2328%20Side%20Effects&f=false
>
> a great book, BTW. Everyone who thinks they know what they
> are doing when they write C++ should read this book! They
> will realize that they don't know Jack Roll Eyes
>
> Why weren't these and all the other examples of amateur, i.e.,
> non-professional, software fixed way back in version 0.3.0 in
> 2010, before any more releases were done? And why were these
> and other sub-standard coding practices continued and expanded
> in later releases, right up until the present?
>
>
> Back in 2010 most code was still being written by Satoshi so
> perhaps you should ask him. Regardless, it's very common for
> professional codebases to require assertions be enabled. For
> example the entire Google C++ codebase uses always-on assertions
> that have side effects liberally: it's convenient and safe, when
> you have the guarantee the code will always run, and the
> performance benefits of compiling out assertions are usually
> non-existent.
>
> So for this reason I think Bitcoin Core currently will fail to
> build if assertions are disabled, and that seems OK to me.
>
>
> As a matter of procedure we do not use assertions with side effects---
> the codebase did at one point, but have cleaned them up. In an
> abundance of caution we also made it refuse to compile without
> assertions enabled: A decision who's wisdom was clearly demonstrated
> when not long after, some additional side-effect having assert was
> contributed. In the real world errors happen here and there, and
> making robust software involves defense in depth.
>
> Considering the normal criticality of the software it should always be
> with the assertions. Without them is an untested configuration. It
> would probably be superior to use our own assertion macros (for one,
> they can give some better reporting...) that don't have the baggage
> ordinary assertions have, but as a the codebase is a production thing,
> making larger changes all at once to satisfy aesthetics would be
> unwise... simply refusing to compile in that untested, unsupported
> configuration is prudent, for the time being.
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140604/602a213b/attachment.html>

2023-06-07 15:20:49

- reply

📅 Original date posted:2014-05-03
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03.05.2014 02:54, Ben Davenport wrote:
> No one quotes amounts as 63 k$ or 3 M$. The accepted standard at
> least in the US is <currency-symbol><amount><modifier>, i.e. $63k
> or $3M.
As you said, that's in the US, and I strongly suspect the sole reason
is that in the US the currency symbol is written in front of the
amount. I often pronounce $10k as ten kilodollar, using it exactly
like a SI-prefix.
The much better argument against SI prefixes is that the prefixes for
values less than 1 tend to be much less well known: Most people know
that kilo means 1000, many know that mega means 1,000,000, but few
know that micro means 0.0000001, and those that do tend to confuse
micro and nano.
Jannis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIbBAEBAgAGBQJTZTmNAAoJEBrvn3PsoRcmrzYP9R0cch42wV+I21MNVbWEEhfw
GjuCqE2Vz7QtI4nhRZ0Eas+MOY6iZD1c2A7cr4BjWx+MdQQwJSMKg/UKruE3j9xs
4QAFQtjvQ69Yd5ztq3ISWM/DpGfPXRvRdIf02ldz0Sf4HMxvqHCcYov3/laOrFnF
3ECpd+JLrU/Wq/HWwuFFXbfyQnpn+9LHx5gcfhV/pW7PwAjwzeaKhY1neQRHhQWq
pD8iv2dikqs30nO6bhnrCv/u0N+2iwV4e+J0E+kpBwrCZLeG8MirRRdnLruJ5mnT
nGyRNdfPKl5n0Gm4AFkBC3a4VIYwOxAzxdfA55Hn27yxll0GFEQNqR9OCNblGUbQ
RWa3Nywa22aYHOTi7evmuP6dVFjF4T8dl8LzDBmeawBsbOeHAUYJgLoHezdwEoto
Dt01ML4CmCINnPIFiuab17gpUYg7OXKomOQPrdyaVnP2abgvQCV5bYhMnKKVa25U
mW5PK02stxKcTEyHBsz0BG8zmdx5+7A5ySaUHrXs+l3YNBp3idlDUeYIsEBKFAtR
vNEGLbV2ZvteOb+tflxuPSjgIaMHD9w6vX2l7+VgkRTms743s/wbQuLb2fXq7osM
zws5D/L74zG1ZwsNM04Ygs2GJoJhkb1QXxY9EuoIeiuK3nVeJEWeRGHBEmqCXOPx
FB/2U/d69fUTbvUzOXA=
=Qo8z
-----END PGP SIGNATURE-----

2023-06-07 15:20:24

- reply

📅 Original date posted:2014-04-26
📝 Original message:Am 2014-04-26 22:17, schrieb Mike Hearn:
> Bitcoin is not a vendor, so I doubt that would work.
By my interpretation of RFC 6838, the Bitcoin Foundation or even Gavin
himself could register a vendor tree for Bitcoin. In the case of the
foundation registering, getting the subtree named vdn.bitcoin should be
no problem.
> I doubt we should spend any time on this. The chance of a string
> collision is extremely low. The current mime types are fine.
It's mostly about the good feeling of having followed the rules and
proper procedures, I doubt that there is a difference in practice

2023-06-07 15:19:57

- reply

📅 Original date posted:2014-04-24
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 24.04.2014 14:15, Mike Hearn wrote:
> Beyond needing to double balances, what if the shop is selling me a
> phone on contract? So the actual cost of the phone is lower than
> the real price on the assumption of future revenue. Alice double
> spends (aka steals) the phone, paying double the artifically lower
> cost but still making a good saving. Bob does not end up with
> "nothing", he ends up in the red.
Nearly every payment system in existence has this problem: you have to
be able to enforce the contract out-of-band. The scenario you describe
is no worse than a payment network with instant, secure confirmations
because Alice could just as well refuse to make the second payment.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTWUYdAAoJEBrvn3PsoRcmT28QAJNbxjLRPYvkIfizeHoAFRH2
pNfd9458/AECJ6muGAs+tYeDw9uhYMVPnbMLZOwzgPl8HE5NN9XbGjCpwpNzsEK4
a8zb5CsonBh+xBNgbx1CIjCNYYQLd2qmgxMVaH4R7VWS+DgVBjfKq5MnM0vdSNcw
SSzb9dMEjgl1cOZa07CG4GuPwEUIFiCVygjYSrGP2E8qCepKvH+0webIXk7COqZK
SyhTdhS+dsdgGW5Mm8cA8zIVPaWYXMo88kOq2S4fIs5HiWtnVXQ9ljJ4r2Py1SEO
H3u4lMWc7Hu0PUW6b6K+uDQfyJtRNi0diJSswseA37v6BeQW4zYMNfL40AsnG+Fv
MusJFtBqHzXKhAeE/zpwi5QWs/qHvRYlETifIMKMrQldssDJo15ed/M8wNCZRobv
Q7K3XKOt228nUUP2FrZl1I4wGWwkBMpzP89t8HMrTZYV2EFWqE+lu9oXcEjz9k12
64UXiWXU0jRAhMiCAvQUL7fKaOb9TXfGPy+3+bZOAtKM5M582+0d94EObA67SBsm
O4H5vLTwS041x1cndW0NDxDbtM+IAuu2Jorzqzcie3ld7cqsKAyDbSk3i1C7zQzG
hvI6FxIy0n6GA9ciw8RM44Q4zPVxYQ4e/MMby9ko7otmL5HLlOCnOUmJ/JHn+QJG
Z7MDRkKAslLUUEqzgQWb
=HNO6
-----END PGP SIGNATURE-----

2023-06-07 15:19:00

- reply

📅 Original date posted:2014-04-20
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I agree that a unit based on 1e-6 BTC is easier to use in practice
than BTC. The name microbitcoin is ok-ish. Nearly all countries
officially use the SI-system, but that doesn't mean that the average
citizen knows all the SI prefixes. Mega, kilo and milli are
universally understood, micro not so much. This is a serious
accessibility concern.
But I dislike the term bit for the already stated reasons: It's
already used in various languages for various things. Simply using
Satoshis may be easier and is universally understood.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTVAgZAAoJEBrvn3PsoRcmWYgP/0JMXmJjzdBFBQscl3+yA987
4zD+W+7o/wPqRmtCU9voJ1PFj9zM6zagHAz455wjnF4IwdgYZjqtadyfxgP5Mg8p
WGoplGQPWJ5KorsQfbiJP8uTOfTzJK5p6Aw9DwscN4aBjCMaHskvyWGVpE8U7ibQ
Pk+a6lX1UUOnjm/G7v5UDKFSlUGAe0GCTnI8FDjxAfF8mzS9XzMSPCfbZfoc7eEx
F7yKkAQGZCDJKP4y6oenj4CGXn100KSZEmombNQ7PeOEwqcKsd1RgPtHWTZzb0Ya
hk2sSnEEt05uwyYsGRnb1EYUwiSS/6sgT9m7fU3bpFf3dWqGuMweSVuGgCTMPrRb
3ei18TJAI59lF/du5zbhQOujpNx/ocmf538hcpFkqaM3RTpeXifaSAefp37S5Zbq
xw013M5T55SmJZYQwdWTFA689kvmOT1N33ht2QtSszl6ZJDFOrwICdcIqMsS6a0a
cGcigi2Ru4M9J7w7wk448ky22Z8VjZrKTQFqhiKzoRk2t0N/SQbKSFKCm7ffsAB/
7EGB9cA3va5ZFBnDAae84Vj0RAMJDHYO7VZIg/mF5qNs8YWs6okQoeJ8FMfNAhW2
pDgZdJfl46lnzfQvgiV/jAMkFr/oSj0UZUPAWXbaGcAm3ZFNO4B0SgNB2VYUfLIe
VNW1pzTKiwL83RjNTGfV
=EPvS
-----END PGP SIGNATURE-----

2023-06-07 15:19:00

- reply