<unnamed>

Public Key

npub12vlytlltjj7g3s227u9jtx2g8qtsu7gscynnn99k808ydr4vygcqvdqa4q

Profile Code

nprofile1qqs9x0j9ll4ef0ygc990wze9n9yrs9cw0ygvzfeejjmrhnjx36kzyvqpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmc36vcgx

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 20:08:36 CEST

- reply

📅 Original date posted:2017-12-11
📝 Original message:With all due respect, this isn't a BIP. It's idle speculation regarding
what one person considers to be a problem and others may not. Please
read https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki and
try again. Among other things:
- Convince us this is a real issue, and that your data is accurate.
Who's to say which coins are truly lost? Maybe the people controlling
the keys are just laying low, wish to use their coins in 2112, etc.
- Propose formulas for how the miners will take everything into account,
and explain why they're acceptable.
- Write code that implements your ideas.
Good luck!
--
---
Douglas Roark
Cryptocurrency, network security, travel, and art.
https://onename.com/droark
joroark at vt.edu
PGP key ID: 26623924
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 895 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171211/de37c9f0/attachment.sig>

2023-06-07 19:58:03 CEST

- reply

📅 Original date posted:2017-03-28
📝 Original message:On 2017/3/28 10:31, Wang Chun via bitcoin-dev wrote:
> The basic idea is, let's stop the debate for whether we should upgrade
> to 2MB, 8MB or 32MiB. 32MiB is well above any proposals' upper limit,
> so any final decision would be a soft fork to this already deployed
> release. If by 2020, we still agree 1MB is enough, it can be changed
> back to 1MB limit and it would also a soft fork on top of that.
While I think this idea isn't bad in and of itself, there is an
assumption being made that the community would come to consensus
regarding a future soft fork. This, IMO, is a dangerous assumption.
Failure would potentially leave the network at a hard fork well past any
current proposal. It would also potentially lead to miners becoming
hostile players and making political demands. ("Soft fork down to X MB
or I'll shut down 15% of the network hashrate and work to shut down more
elsewhere.") I'd hope we can all agree that such a scenario would be
terrible.
I do agree that the idea of giving everybody plenty of time to plan is
critical. (Telecom providers need months, if not years, to plan for even
simple upgrades, which often are not as simple as they look on paper.) I
just think this proposal, while well-meaning, comes across as a bit of a
trojan horse as-is. I can't get behind it, although it could potentially
be molded into something else that's interesting, e.g., Johnson Lau's
Spoonnet. Fork-to-minimum, while introducing its own potential problems,
would put much less pressure on full nodes, and on the ecosphere as a
whole if the max needed to be soft forked down.
(I'd also like to see SegWit go live so that we can get an idea of how
much pressure there really is on the network, thereby giving us a better
idea of how high we can go. I still think we're flying a bit blind in
that regard.)
--
---
Douglas Roark
Cryptocurrency, network security, travel, and art.
https://onename.com/droark
joroark at vt.edu
PGP key ID: 26623924
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170328/3355f573/attachment.sig>

2023-06-07 19:55:01 CEST

- reply

📅 Original date posted:2016-12-18
📝 Original message:On 2016/12/18 12:07, Alice Wonder via bitcoin-dev wrote:
> I almost did not update to 0.13.0 because the test suite was failing due
> to python errors. How to fix them was posted on bitcointalk.
>
> 0.13.1 came with new python errors in the test suite. So I just said
> fuck it.
>
> When the test suite actually works in my fairly standard environment
> (CentOS) in the distributed release, I will upgrade.
Can you post more info about the problems you're seeing, how you fixed
them, your environment, etc., or at least post an issue on Github? I'm
sure somebody would be happy to help. Some info on how to reproduce the
problems would be very helpful. :)
Thanks.
--
---
Douglas Roark
Cryptocurrency, network security, travel, and art.
https://onename.com/droark
joroark at vt.edu
PGP key ID: 26623924
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161218/89f0aa67/attachment.sig>

2023-06-07 19:43:53 CEST

- reply

📅 Original date posted:2015-10-26
📝 Original message:On 2015/10/23 03:30, Tom Zander via bitcoin-dev wrote:
> On Thursday 22 Oct 2015 17:26:42 Jeff Garzik via bitcoin-dev wrote:
>> It was noted that leveldb is unmaintained, and this is part of researching
>> alternatives that are maintained and reliable.
>
> Apart from it being unmaintained, any links to what are problems with levelDB?
While not exactly the most rigorous link,
https://en.wikipedia.org/wiki/LevelDB#Bugs_and_Reliability seems like an
okay place to start. One thing I can attest to is that, when Armory used
LevelDB (0.8 - 0.92, IIRC), quite a few users had DB corruption issues,
particularly on Windows. Even when a switch to LMDB occurred for 0.93,
loads of complaints would come in from users whose LevelDB-based Core
DBs would fail. I know that the guy who moved Armory over to LMDB would
love to have more time in the day so that he could write a Core patch
that does the same. It's a very sore spot for him.
(FWIW, LMDB seems to work quite nicely, at least once you patch up the
source a little bit. The latest version is also compatible with Core's
cross-compiling scheme. I'd love to see it added to Core one day.)
Doug

2023-06-07 17:28:52 CEST

- reply

📅 Original date posted:2015-01-21
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2015/1/21 15:30, Pieter Wuille wrote:
> Thanks for the comments. I hope I have clarified the text a bit
> accordingly.
You're welcome. All the revisions look good to me.
- ---
Douglas Roark
Senior Developer
Armory Technologies, Inc.
doug at bitcoinarmory.com
PGP key ID: 92ADC0D7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJUwA6WAAoJEGybVGGSrcDXvmEP/A09j4lq2P0RMqrvtwnDQRmH
oimbGwC2a/BbpACBegn0cdFYMURFFcec4gHKyvuN7xR4SRsgQ+Djq/KranAMkYbs
ZQVFGXRWdZhfsh7bY4zbBUj+H8c8PAsKL0D7S8r4iXviuUimXJXqESUYote9Ylz3
rwjiK3oRiCSMpTMiI3eDjrbQt5HHLw3hKL7W6zTerx64eCaO2JsIn/Pk4Krf9xwd
1ejpyqrK/9s90NPB0Qqieqbgg7WoQYP+ZMzFi5oNxtNrZjlOCNSQKLN0IXqnnMnS
+AoB4B5TUGCdLq3Wlo69mhLaLYNaPNHEoGNUwikXqsd5WeqsayuYDl36rI4MLWgB
ZBVO6D2BErqdqMTrmUEurubXMb6CCAuFu6iYjO3vucQ0l+7xD7OW/XiK7ZPNFuwj
2fJCjRHjqgDwKlIUF3Gh7BwRrT2iZRoFYWXDVRBMiJpHvs1+U79pQENp4BmQLWE+
xn3gX9r755mVDJL10MFM6jKijgTCGA2hEFjK2Vu1JJMeVSIGaOdEIen2DxS2mqnZ
b/t9VDxfbFQRw5pj2zHsvFDGBe7DEhvBSqbNtiPrY5/LITeP8Nt4CZ9PHrYPJV5A
ocUx98l1sqy7P0QiYzAEp5tpdjTS17MVNPt84JLJnk7wL+fDRfKKV3A7tI/ziFJe
hjW91YNTIrs+ZFLV/HJc
=Rjcd
-----END PGP SIGNATURE-----