Douglas Roark [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-01-21 to 2017-12-11
💬 Posted a total of 19 messages
📚 Participated in the following categories: Bitcoin-development, softfork proposal, bitcoin-dev, patch, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 14:45:11

- reply

📅 Original date posted:2015-11-19
📝 Original message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2015/11/19 04:29, Pierre wrote:
> Do you know of any available resources on "segregated witness" ? I
> couldn't find any.
On top of what others have posted, it looks like Pieter has posted
code for a hard fork version over at alpha
(https://github.com/ElementsProject/elements/commit/663e9bd32965008a43a0
8d1d26ea09cbb14e83aa).
I doubt it's everything you need but I think this will give you an
idea of the nuts & bolts for the hard fork version. I'm not aware of
any public soft fork code.
Doug
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJWTiN9AAoJEEOBHRomYjkkGREP/0QAsyOpQ1IWu+qYBOXaoXXg
mDqwqV5Ci3xrOr2EgCA5ZWLhFMP9Ljk+F0zzUGj0dgf6HSXn238nddzqyCntBYyz
wtquSEKHkY8iAJcHB71QiIZAgZb2QDqGAGPRKY8OXXhajoaL/MDwKQpMdBxor640
RNpYlipRET9+Hu9JY9a8zALt4qq0QHxEtHTV+tGA+wN7Ax9Ylsj8zNr8LwXTaPJE
cywHDtXiqw6ZZrh46ii/0K6oruQMjzGqplPMZT02ZfJDY1/oKAQRqtzRFy0plxOr
FCUQmAta91E13g2B2F4oY/bBXzwVfdiXyIZGfcq+3dYpha5eA6uIeO2aiOmBiNuq
avr7A6rCQV1PeDV4GllS2JNMP6q3OaoyvbN35vzXA+DxWqFDRF/rcVZoIoDLzHmK
J1U7L//UXxnzUSZzFUpZl3G5hE4N7A7TwA22L91fTdwIH2JXw9LTVt1Z1O2goAAn
9bzwJ759u1rjzH0159fRCbH8EsuwoWFtyLqlUHXrozg2O/w3D824CLO5TXa3F+HV
hnJogG5Lyj3ntMn2ZvwUdpyVGW48L0s5Pwb4FyusGT/vdjEb+tPuaiTqNgFrkhst
txzSGIbfAsuPozzI5Sfopf4dHsjXsPUi/bUGHhlwdxPvQkhCw/ZKzjAXx8wDiPxi
rE/aCy0vOfeJiJ9NLVkM
=tAD8
-----END PGP SIGNATURE-----

2023-06-07 20:08:36

- 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 20:08:01

- reply

📅 Original date posted:2017-12-01
📝 Original message:On 2017/11/30 14:20, mandar mulherkar via bitcoin-dev wrote:
> I was wondering in terms of mass adoption, instead of long wallet
> addresses, maybe there should be a DNS-like decentralized mapping
> service to provide a user at crypto address?
A few years ago, I was part of an effort with Armory and Verisign to
make something similar to what you're describing.
https://tools.ietf.org/html/draft-wiley-paymentassoc-00 is where you can
find the one and only official draft. I worked on a follow-up with some
changes and some nice appendices, explaining some nice tricks one could
use to make payment management flexible. For various reasons, it never
got published. I think it's an interesting draft that could be turned
into something useful. Among other things, it was able to leverage BIP32
and allow payment requests to be generated that automatically pointed
payees to the correct branch. DNSSEC may have some issues but, AFAIK,
it's as the easiest way to bootstrap identity to a common, reasonably
secure standard.
--
---
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/20171130/ee8ac2e0/attachment-0001.sig>

2023-06-07 19:58:03

- 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

- 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:54:04

- reply

📅 Original date posted:2016-10-16
📝 Original message:Before getting to my reply to Tom's message, I forgot to give my
thoughts on the Nov. 15 date. I think it's a reasonable date. With
various holidays coming up in the West, it's probably best to get the
word out now so that work can progress before some people get sucked
into family obligations and such. A month gives a bit of time without
dragging out the waiting game, IMO.
Now then....
On 2016/10/16 11:20, Tom Zander via bitcoin-dev wrote:
> There have been objections to the way that SegWit has been implemented for a
> long time, some wallets are taking a "wait and see" approach. If you look
> at the page you linked[1], that is a very very sad state of affairs. The
> vast majority is not ready. Would be interesting to get a more up-to-date
> view.
It's not the website's fault if wallet devs aren't updating their
statuses. Besides, "WIP" can mean an awful lot of things. For example, I
know Armory made significant progress with SegWit support as part of
their upcoming 0.95 release. I have full confidence they'll be ready
relatively soon. Other wallets may be ready. Other wallets may be stuck
where they were in the spring. In any event, it's a free country. Unlike
consensus rules and such, it's trivial to move one's funds to a wallet
that fully supports SegWit if that's what one desires.
In addition, I was at the wallet workshop at Scaling Bitcoin last week.
An awful lot of things were on the board as potential discussion points.
I think SegWit was mentioned but wasn't really discussed. I don't think
FlexTrans was even mentioned (and it's off-topic anyway). Wallet devs
are far more concerned about things like UI and standards for HW wallets
than they are about their ability to support SegWit. I think wallet devs
are quite capable of making noise if they felt that SegWit was a bad
feature, or a difficult-to-support feature.
> Wallets probably won't want to invest resources adding support for a feature
> that will never be activated. The fact that we have a much safer alternative
> in the form of Flexible Transactions may mean it will not get activated. We
> won't know until its actually locked in.
A lot of devs have already worked on SegWit support. This has been
covered. Even if they don't support SegWit, the wallets will probably
work just fine. (For awhile, Armory did crash when trying to read SegWit
data in Core's blockchain files. That problem was fixed, and it was
probably a rarity since very few wallets rely directly on Core.) As long
as devs use testnet or regtest to iron out their kinks before hitting
mainnet, I can't think of a single good reason to hold back SegWit
solely due to wallet support.
Also, once again, FlexTrans is off-topic. As others have said, you're
basically being stubborn at this point. If you insist on discussing
FlexTrans, start another thread. It sounds like quite a few devs would
be more than happy to say a word or two about your proposal.
--
---
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/20161016/7c46263a/attachment.sig>

2023-06-07 19:54:02

- reply

📅 Original date posted:2016-10-16
📝 Original message:On 2016/10/16 09:35, Gavin Andresen via bitcoin-dev wrote:
> I asked a lot of businesses and individuals how long it would take them
> to upgrade to a new release over the last year or two.
>
> Nobody said it would take them more than two weeks.
>
> If somebody is running their own validation code... then we should
> assume they're sophisticated enough to figure out how to mitigate any
> risks associated with segwit activation on their own.
In addition, there has been a page up for several months
(https://bitcoincore.org/en/segwit_adoption/) that gauges whether or not
wallets are ready for SegWit. Unfortunately, it appears that the page
hasn't been updated since May. I do know that several wallets have
finished or are close to finishing their support, though.
Would I want anyone to lose money due to faulty wallets? Of course not.
By the same token, devs have had almost a year to tinker with SegWit and
make sure the wallet isn't so poorly written that it'll flame out when
SegWit comes along. It's not like this is some untested, mostly unknown
feature that's being slipped out at the last minute, unlike other
features I could name but won't. :)
--
---
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/20161016/f31664df/attachment.sig>

2023-06-07 19:47:58

- reply

📅 Original date posted:2016-01-21
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2016/1/18 19:58, Ethan Heilman via bitcoin-dev wrote:
> I believe libsecp256k1 just performs Elliptic Curve operations
> required by Bitcoin. OpenSSL is used for all other crypto.
The exact answer, as I understand it, is a bit more nuanced. In
particular, you referenced the PRNG. I believe libsecp256k1, as
currently written, relies on an implementation of RFC 6979 instead of
using a PRNG. I'm guessing this is done for portability reasons (no
need to hook into the OS's RNG).
Otherwise, yes, I believe this answer is basically correct. There are
still some crypto functions not covered by libsecp256k1, at least at
the API level. But, for consensus-critical functionality, I think 0.12
will be rid of OpenSSL.
- --
- ---
Douglas Roark
Cryptocurrency, network security, travel, and art.
https://onename.com/droark
joroark at vt.edu
PGP key ID: 26623924
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJWoEkTAAoJEEOBHRomYjkkoR0QAKmvgmoOdCw7SLP9cFURltXw
Ro8mOfikjp04C6tsshtiKQ1+jq80wBhioVYIL7XiyNU7ZUNdAWSc/wGBCG+YkMeQ
6h02WJZQtTe0PvGVHIgUw6SiV4ZzXBuapXQX0BgEl0pInvQkRRqWtgrqDlWbqJVg
NKzm8Kh+c8JUHEKbhnC45Jgh2JYHpyXcByLHSyGYsPOprjHmsupCPC6qydrRnuaO
r7YHtObK2myOglJ1h6BXir//+XNbk6RiRNf5voONNAR9L+69BBV7hMVVO3eiDZ12
vrNaOIKhDjhDs1kmkFYi7ML/zKBQRXlb7iM8AEpfCUKl/zK9bSNeblP4ZBGPqjCm
9TGCqGjmKEbg7AYXjyMvmw+jZReediJMNYpCdxaSJi+XJZO6EC28pcKsb6pu/9gX
NCLf1T/f2NoyXxc57aTuHNo0SnVaee1z0+IlGSh+5foxhZGbFmPhxOy3WNIubuou
tm0guAXloCCERwVg0OhhQ3YyrlOWz7VnUrT8cteQC+yP353zdnxay7ZmQh9swcyR
VX7yu4xLcxgbQmBIhMyKs9iQnycOrdNhZEfGx4vQ2ZKAj1CPVqrgKxbtY3KuPfvb
YAzfs/iXaqBHH7FN9juLMRGqkzyVzJ9mIsFyLldADvSoc8RSa1IQiZtfPsIU1w1i
UKEl9Qasje80EojNZNz0
=glL2
-----END PGP SIGNATURE-----

2023-06-07 19:46:54

- reply

📅 Original date posted:2015-12-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2015/12/19 08:49, jl2012 via bitcoin-dev wrote:
> P2SH has been introduced for 3.5 years and only about 10% of
> bitcoin is stored this way (I can't find proportion of existing
> P2SH address). A 1-year adoption rate of 40% for segwit is clearly
> over-optimistic unless the tx fee becomes really high.
I don't think one can necessarily conflate P2SH and SegWit uptake. In
the case of P2SH, there's the "if it ain't broke, don't fix it"
problem. P2PKH works just fine for an awful lot of Bitcoin users. Why
should they switch over to P2SH? In the absence of a compelling
reason, they'll probably stick to a proven solution. (You can see that
line of thinking anywhere.) Even Armory, which values security and
whiz-bang features over usability, offers P2SH but keeps it off by
default.
Meanwhile, SegWit fixes multiple problems, or at least fixes some
while also sticking a bit of gum on others. True, it'll rely on wallet
uptake. I just think wallet developers will see the value in it. The
big question, of course, is when they'll enable it by default, which
is the only way SegWit will gain serious traction. My personal,
semi-educated guess is that you'll see 3-6 months of wallet
integration and testnet tweaking, then another 3-6 months of mainnet
availability if explicitly enabled by the user, and finally the switch
being thrown for all wallet users. I'm hoping for the aggressive
timeframes. I'm expecting the conservative ones.
Is 40% optimistic? Maybe, and I'd personally like to see it enabled in
concert with a minimal block size increase. I don't think 40% within a
year of deployment is out of the realm of possibility, though.
- --
- ---
Douglas Roark
Cryptocurrency, network security, travel, and art.
https://onename.com/droark
joroark at vt.edu
PGP key ID: 26623924
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJWdgI/AAoJEEOBHRomYjkkZwsP/iZT+qa/Yp2xIE6ConcTrbbx
IOmz6h4O+ro/Egx/6XrukBSRybn8gsjize279WQWjR0h7O3KS4YAGuR/TKx6IrOw
cz7lZpwC08ZcZb83fUqEqz4q/Rbgp4cPU8WU1niLCYg2OCGqtTEhSSRatmO1ULXp
6KJrBCaoVBzaoqFXx6nXiJF/K1dKZsb/IuFFJZisXEmoDkvTunE82sjHZ+JgmHk9
jhhlk+JU43C7lXXkk+3KPbD+z3dMZNDYrIopaWOUXfk6yXIp8cy7MUK/z58PCm8C
V/pTk0edkMIRxu6ybJLKNNZHqhSQipyEMfG/CojVb6Qtt8zC0RIEUsYj5uDk9RQL
ITxql9RtPHQPx+uoxoCr7Zitx0448YFNpQs6S5/g81vDt7ilh5k5PgnILkMvuA7Y
F6abFvsP/ahmAkisiyDzwMmcM+xzxvJkaY9aDvKy4NNiFw8kUxkAJ2VlMeQvwVTK
2ePzyrFTOGFJRk/a1uTr0aUOxpCdI8rB1O6jcrhmLl2ENRMjN1I3Ksl79Q6h3P+F
zj3hR9CyuXrzoPxAISYF58ot32fil9nEnLcchu2mdWArYKBY2IDWVv7JiK8RCJ8b
2XymxccKsXIUHTrYJfrHg+AeRHkVuV8emyUp95A/8kb8meWbLbmpxOrt6JLEE4k9
qsl9Zkg/0IsCr+JzE6Ko
=696M
-----END PGP SIGNATURE-----

2023-06-07 19:43:53

- 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:35:44

- reply

📅 Original date posted:2015-05-26
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2015/5/26 21:48, Pieter Wuille wrote:
> here is a proposal for how to coordinate future soft-forking
> consensus changes:
> https://gist.github.com/sipa/bf69659f43e763540550
>
> It supports multiple parallel changes, as well as changes that get
> permanently rejected without obstructing the rollout of others.
>
> Feel free to comment. As the gist does not support notifying
> participants of new comments, I would suggest using the mailing
> list instead.
Hi Pieter. Thanks for posting the proposal. I think the concept itself
is pretty solid. I know some people have been proposing alternate
methods too. I hope they'll share here, assuming they haven't already.
As is, my comments concern typos and general copy editing.
- - Just speaking in general, I found the BIP to be a bit hard to read.
AFAIK, the basic facts are accurate. I just found myself having to
re-read certain passages two or three times. A little polish wouldn't
hurt. For example, using the "it" pronoun can be confusing, such as
multiple uses in the abstract. Specifying what "it" is (e.g., "The
proposed change relies on...") would really help. In addition, the way
the "W" value is handled seems like it could be improved a bit. I know
the wording is accurate. Seeing 1000 change to 1001 is still a little
weird.
- - In "Multi-stage soft forks," I presume the second sentence should
end as follows: "[...] with additional validation rules that get
enabled one by _one_." Depending on semantics, I'd consider changing
"one by one" to "incremental steps," but that's your call.
- - I found the "High bits" section to be confusing at first. It looks
like you chose to show everything as little endian data, matching
what's actually in the block. My personal preference would be to
represent the data, for readability purposes, as big endian. I doubt
I'm the only one who finds big endian to be much easier to process
mentally.
- - Some sort of legend showing A, I, W, etc. would really help, as
opposed to just running into them as one goes along. Otherwise, the
alphabet soup can be a bit confusing.
Thanks again.
- --
- ---
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
iQIcBAEBCgAGBQJVZSx5AAoJEGybVGGSrcDXrYEQAOIrsggoZv0LdJHZjPGpEkeb
7ULhO4krZtQmKXjWDP0KnHAsFiyo5EOh1fYFRZz11OCqO4QmteTLPbodZFz47tKp
tIYv5uc0qYhjfo5uLkzxuUky08VE4dUoELfqdbNciC45xHras7Wh/+KXc1a20Fib
TaisWx9aL6VfPf7urM8b6mQ9XMba4YB3e2syAY8AA+qAEEP4DK2V6tuOQJD3kxP2
tbHtJnDvkDoXEY6tnL7fePo9X/IrlXLi8vNWGqPIf/hoiHmdvU+ORwHta7z9YeIO
zi4LRs8n8sYmifY4nt6Wkkc1aoPsmpoXmI3tKgFM2h5bfdg0n3fN3K0nTMWtnR6z
HUq8JhrQkZUP8uunN/23bt94FZolvnHTdL9YuWoyrlJ0gQri5YxV1BAN4hM9oCZy
1SqlSmFRplIFWu45q8/I5duDSphmA4NP2qc59QRjftcGYpNxmzaeSViiCDWzAjI9
qTLZgLTa/nf3TFN8oU8RwquGpwD82/fFo9V+uKdNGj79kdV8WOv4sa9q63OTVimJ
w+r4l1gDZYyToe0heKtV2kL9Tt4HTn23bj7EvU+98uaKEpfWSP8a3BN9mPR7ork/
lNRGEGQ0tvkeDUzKy9IHuAjXo2XkKctbBRJwZJCGc5WW2sN0HdSu/GFPXrOOLf0J
JXqeKpfaS0UriFXkxVHO
=8uNL
-----END PGP SIGNATURE-----

2023-06-07 17:28:52

- reply

📅 Original date posted:2015-01-21
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2015/1/20 19:35, Pieter Wuille wrote:> Hello everyone,
> Comments/criticisms are very welcome, but I'd prefer keeping the
> discussion here on the mailinglist (which is more accessible than
> on the gist).
Nice paper, Pieter. I do have a bit of feedback.
1)The first sentence of "Deployment" has a typo. "We reuse the
double-threshold switchover mechanism from BIP 34, with the same
*thresholds*, [....]"
2)I think the handling of the sighash byte in the comments of
IsDERSignature() could use a little tweaking. If you look at
CheckSignatureEncoding() in the actual code (src/script/interpreter.cpp
in master), it's clear that the sighash byte is included as part of the
signature struct, even though it's not part of the actual DER encoding
being checked by IsDERSignature(). This is fine. I just think that the
code comments in the paper ought to make this point clearer, either in
the sighash description, or as a comment when checking the sig size
(i.e., size-3 is valid because sighash is included), or both.
3)The paper says a sig with size=0 is correctly coded but is neither
valid nor DER. Perhaps this code should be elsewhere in the Bitcoin
code? It seems to me that letting a sig pass in IsDERSignature() when
it's not actually DER-encoded is incorrect.
Thanks.
- ---
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
iQIcBAEBCgAGBQJUv/4vAAoJEGybVGGSrcDXMxkP/1N2lLAloCKdRUpMBLPEZ5jh
bJ4reCeqrMy6JetsKSGfGKdAe7kGkeRl6s8dlHYnpUmnODXU9BCku3zHi3+qm8IC
GZlwSdSSgmRneP7btPula0CG31o7X2UJiDW/2IOZl6ul8b7LB2L56O+Ew+PNm+at
tCfRcpKtq9LYCnRYR0azd4c5YY9/o7zlkpGi8CututzuEa4Rcm92U1extoo2tC/j
nzUfbfcQVL0a7JaRU4VYNceYrcG/xSpKPjsEU/F+5IwnUxL/kebz0EDt1kzm+fOE
EMUMXyYgoyW5VDFNjxu00PnJUfVNCOXN/N/h9eCdskCL3AtH6xg1kzam5OGvpEZS
QDMNSmQl4Zpx5WiATylNkhhzb/8GowamkSFg4SUjBsjpwOTMTIF0Qhnt+DdzwpI2
etxCGds154nL4p/bkulseczwxOZWin9oZxJnCxp40oFl8fva0BwHVx45uMyI61Ko
qRJ9Ol0CDoId3h1EMTt4uyoNxrOzgrj8/+V4BBytOAMMmsfD0VgY68xzdywJxYnC
jgU99huhwtJpn9QT6JAbgPAaboomu6hDCohV+J+DCCkIiYFk1jxp+FQ4xZDzcKeo
gMYpmFefPAxnHvDXf1v1A+Xw8plN6/NREaIpprh7Ep+q/8vYAiwwHfKjubdMkB3D
WnTR5YbqyGxc/Pvh9Ncq
=C/wj
-----END PGP SIGNATURE-----

2023-06-07 17:28:52

- 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-----