Douglas Roark [ARCHIVE]

⚠️ 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.

Public Key

npub12vlytlltjj7g3s227u9jtx2g8qtsu7gscynnn99k808ydr4vygcqvdqa4q

Profile Code

nprofile1qqs9x0j9ll4ef0ygc990wze9n9yrs9cw0ygvzfeejjmrhnjx36kzyvq5ex7c4

Author Public Key

npub12vlytlltjj7g3s227u9jtx2g8qtsu7gscynnn99k808ydr4vygcqvdqa4q

Show more details

Last Notes

2023-06-09 12:45:28

- reply

📅 Original date posted:2015-12-17
📝 Original message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello. I wanted to throw an idea out into the open and see if anybody
had any thoughts.
Earlier this year, I worked on an effort to attach payment data to
DNSSEC via DANE[1]. This included working on an RFC draft[2] that
explained the concept. The idea was to use the DNSSEC system as a
database of sorts that could get trusted payment info out to users. If
you wanted to pay Top Quality Widgets for their goods, you could look
them up on the DNS system and be reasonably certain that you were
actually paying them. The setup was designed to allow for all manner
of payment methods, with ACH and Bitcoin being the first two to be
supported.
(Note that the effort eventually fell by the wayside before a
much-improved second RFC draft could get out the door; the first draft
barely touches Bitcoin at all. If anybody's interested, I can provide
a basic outline of what was going to be in it, at least on the Bitcoin
side.)
I'm wondering what others think of this idea, and how it could apply
to Lightning. The main hangup out the gate would be that the payment
info has to be attached to a domain (e.g., topqualitywidgets.com) that
supports the scheme. This would, in all likelihood, mean custom
domains would be needed where support for the scheme was explicitly
included. This could be tricky.
Despite that hangup, I think this is an interesting scheme that may be
worth exploring, perhaps in a modified form. We had the scheme set up
where, on the Bitcoin side, the keys were really flexible and could
support things like per-user payment addresses (i.e., static addresses
weren't mandatory). I thought it was pretty slick, but hey, I'm biased.
:)
One related-but-separate thing to keep in mind is that, if there is
any sort of ID at host scheme deployed in Lightning, it really ought to
support internationalization. [3] suggests taking the ID and hashing
it with SHA-256.
Any thoughts? I really like the idea of having some sort of
quasi-permanent method for storing data without having to rely on a
complicated scheme to find other nodes in the network. It should be
optional, of course, and should work alongside any mandatory schemes
to find other users on the network.
Thanks.
[1]
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities
[2] https://tools.ietf.org/html/draft-wiley-paymentassoc-00
[3] https://tools.ietf.org/html/draft-ietf-dane-smime-09
- --
- ---
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
iQIcBAEBCgAGBQJWcxdpAAoJEEOBHRomYjkkdDAP/1eCph6RSQJoUAWo4AONWQEp
nF9C55nRhNdtoMZI52cTN1gU75PS3HNnEfmE0oejZdlt31E+A3V7ibyzOQaHAPzm
ZyVD5/Ke29k+IxPhuk++AMLDJsCbdW/U284NMf3d6yWLZGYCDxaNVEIgs96jHuLN
c1Ot827Wcl19D18SZjYSXeCXrYkXEZs5MQuGjw1sPOo/z8UdWHBAY9J8y8+bhS48
4/ZHQMq+XVawrl+p65vIKwhrQvaq0PgtWjHSyG/5lTQEKQMphDppPXQRyyMdbzX8
JO7Agrjp4MVcwccvsW6oCID+o49l3qeLY+A6sBqcgjCRIgcP3pEbsBb8zCWTNMH/
/lTkywMisEGctbdO3IKHXGXlmOLMb96jiwY1UJBr7yws0IxPM5F/Lw7PufojrcPQ
uPe/kQ1RSMQaDDQnxGRiY796g9OImNImhZu0WcyRoR91Mu4stJkOABHdwu2voZA8
DrJRGJ+BbP0xV8dSGn1dqpnlAMIqKhWfUc67GPoLdgsPd021VbzlctXfLlQe8cWG
qvLwsgnzvpzPn4MmCPrGyGg+cCOgH0XWBUeFPnPUZIFP5bosTGvXUPrsaJw+qkd+
fiYxQlm9QuhNtdmhIMAapbfsSoiRgxhPb8PsKb6tkj/blk4QI8m5p2GRVY+2BBOr
LPHm5WXTCn1XgdCXOZM8
=3chy
-----END PGP SIGNATURE-----

2023-06-09 12: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 18: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 18: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 17: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 17: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 17:54:11

- reply

📅 Original date posted:2016-10-27
📝 Original message:Am attempting to move this over to bitcoin-discuss, as this (IMO) isn't
appropriate for dev and is borderline trolling. I won't be replying on
dev beyond this reply. I'll also try to keep this reply technical in
nature. (If this continues on discuss, no promises. :) )
On 2016/10/27 08:38, Andrew via bitcoin-dev wrote:
> I have been reading recently through the history of soft forks provided
> by Bitcoin Core:
> https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-record-of-blockchain-soft-forks.
That list is incomplete.
https://www.reddit.com/r/Bitcoin/comments/2y4mq2/list_of_soft_and_hard_forks/cp68q4q/
is closer to the reality of the situation and is probably still incomplete.
> It has led me to think that there is a deceiving notion that soft forks
> do not force Bitcoin users to upgrade software. Yes, it's true that the
> past soft forks still allow old nodes to accept blocks under the tighter
> rules as valid, but what about miners who are still using old software?
> What about users who want to make a transaction using the old rules?
> Those people are no longer able to do those things. And if they want to
> do those things, a hard fork will result.
I don't see a particularly strong movement rallying for the right to use
sigs without strict DER, previously NOP opcodes that now do something,
etc. I'd imagine that a soft fork that "truly" forced people to do
things they didn't want would be much more controversial than SegWit.
> Remember what happened when BIP 66 was activated?
What, you mean miners who were deploying cheap hacks in order to eke out
a bit more hashpower? They got what they deserved.
> Obviously every one can debate about what should be the definition of a
> soft fork, but whatever that is, I think it is unacceptable how sloppily
> the past soft forks have been deployed. I can think of many ways in
> which we could have these new features that the soft forks provided, but
> without forcing the new rules, and simply making them features that can
> be used on an individual miner or transaction signer basis.
Well then, lay it on us. If your idea is so great, people will come
around to it eventually. As is, the only thing I can see is a load of
switches that would cause the code to act in all manner of weird ways.
New features would have to plan for every single possible use case,
including bizarre use cases that should have no basis in reality.
Congratulations. New feature deployment is now far more complicated, and
Bitcoin, depending on one's viewpoint, will become further stuck in the
mud feature-wise.
> Now that Segregated witness is scheduled to be deployed on November 15,
> we should take a look at this "soft fork" as well. I like the idea of
> Segregated Witness, but from conversations on Reddit and IRC, I see
> people saying that this soft fork will be like the others: requiring a
> hard fork in order to revert it. Is this true? I am getting conflicting
> messages by reading the BIP. It says that if all transactions are
> non-segwit, then a node will validate the block as before. But if we
> pass the threshhold (usually 95 % for 1000 blocks) will miners mining
> non-segwit blocks be ignored? This is not good...
I'd imagine that, if a block has zero SegWit Txes, everything will
function as it did before. It's not like SegWit forces everyone to use
SegWit when sending coins. It's just an optional method for sending coins.
> Now, we can't go back in time and fix the deployment of the soft forks,
> but I do propose one clean way to fix things: Remove all the previously
> "soft forked" rules for non segwit transactions, and require them only
> for segwit transactions. But make segwit optional! In addition to what I
> talked about above, this may also relieve some tensions of people who
> are not comfortable with segwit and are thinking of joining a hard fork
> like the Bitcoin Unlimited project.
Can you clearly define all the rules that you will remove? Are you going
to include things like the original OP_VER opcode (see
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011938.html
for why this would be, IMO, a bad idea)? What about the multi-byte
opcodes (e.g., OP_PUBKEYHASH), which were hard forked off the network
but were technically soft forks since nobody had actually used them on
the network?
> Unless people can give me a good explanation as to why we are deploying
> soft forks in such forceful manner, or Bitcoin Core accepts my proposal,
> then I will have no choice but to create a new client (I'm thinking to
> call it Bitcoin Authentic), that will be just as Bitcoin Core but will
> always follow the chain with the most work regardless of whether soft
> fork rules are respected, and I would put at least CHECKLOCKTIMEVERIFY
> as mandatory within segwit transactions.
If you're going to create yet another Core fork, you'd better be sure to
define just how "authentic" you want to be. I'm guessing you don't want
the overflow output Tx fix (i.e., "the 92 billion Bitcoin bug") removed,
but that one was arguably a soft fork too. Sure, Satoshi committed it
and didn't even give the miners a chance to vote, but he still "forced"
everyone to deploy it. If freedom über alles is what you seek, you'll
need to revert just about everything Satoshi included too, which will be
difficult since a lot of his fixes have been drastically changed in the
code (albeit in a manner where they still function as intended).
--
---
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/20161027/bf440693/attachment.sig>

2023-06-07 17: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 17: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 17: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 17: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 17:45:49

- reply

📅 Original date posted:2015-12-21
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2015/12/20 20:50, Mark Friedenbach via bitcoin-dev wrote:
> I am fully in support of the plan laid out in "Capacity increases
> for the bitcoin system".
>
> This plan provides real benefit to the ecosystem in solving a
> number of longstanding problems in bitcoin. It improves the
> scalability of bitcoin considerably.
>
> Furthermore it is time that we stop bikeshedding, start
> implementing, and move forward, lest we lose more developers to
> the toxic atmosphere this hard-fork debacle has created.
Another +1 here. While I'd still like to see some sort of short-term
bump happen this year - good points have been raised about SegWit
uptake by wallet devs, for one thing - I really do think this is one
of the last pieces of the puzzle that'll make Bitcoin reasonably
stable and robust. If people have legitimate concerns, that's great,
and they should be addressed. I just worry that more navel-gazing and
bikeshedding will play into the hands of those with less than noble
intentions. That and, due to the somewhat complicated nature of
SegWit, it may take time to get skeptical miners and wallet devs on-boar
d.
While we're talking about capacity increases, I'd like to reiterate
that I do think there should be some sort of short-term bump (Jeff's
BIP 102 or his "BIP 202" variant, Dr. Back's 2/4/8 proposal ("BIP
248"), etc.), hopefully chosen by this summer so that everybody can
start to prepare. I believe the KISS theory will work best. I talked
to a couple of miners at Scaling Bitcoin. It was obvious they
generally prefer simple solutions. (For that matter, if I put my
miner's cap on, I prefer simple solutions too!) The research presented
at Scaling Bitcoin regarding block size formulas was quite interesting
and worthy of discussion. The research was also, IMO, nowhere near
ready for consensus. Work and discussions on that front should
certainly continue and push for a more permanent (final?) block size
solution. I just think that, barring some extraordinary solution that
hasn't been widely discussed yet, a permanent solution isn't feasible
right now. A temporary bump isn't ideal. It's just the only thing I've
seen that strikes me as having any real shot at consensus.
- --
- ---
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
iQIcBAEBCgAGBQJWd44sAAoJEEOBHRomYjkklUkP/AqnD4+oiNNNYRGDY3m0bQSG
noUoRmWG/h86AW+2LuNYtn72UVefWJscUcmXWeOOem1KX49KdtCRWz3UZcrmfPUF
h/ilOpYpjCN69nFBhpJPp+0Jqr/PjQpoZkUQ2G1BznGIcIo3jwh7H7dQeI6PMtLB
qTbfdYEqPawb2kIhrCKVVQqsf7dLjg0Hlzvnq+xqyggZ1+k89kXSMEHJaybras7q
DFj1lOhzktzAtxquzAMcctkZM3JvFMnKUwOP6zC+ke9YlmvU0Yhu74F+30/EClLc
XGL5GMvUtvJcC0VRxDlh4pIW3m+eWjLWxvPQGe58eLE2u2Ja2MNjcuVtJdRgouLI
VSPBrUKoGOGfNfsqJH9U9jsvRuQMvT6JFS3jjxiapgi+ip1O7+Pkbq6tO55Mz7Gd
WMG71HdrLzZtjOzRmOFL5q3CkTpZp75tsXOYxn7jVcJlYJUh/jrnVMvSbPAT/VAY
yJIPtWRj+jtMKAR9m4Lx+9N4F56OC3g0M749v31luoYZkKMl7ohgkONgpKhrDRBU
uVmWH0pUIvaScsJxrUtgZdqn2AUqRowq6nM0YNDKo4go5/LyAkYYi1mICb0O0JJG
mt+3fabix6biBPHZDAvKxKX5CAPDapno2adTBx7vY36evGdhI9sWA1jw91He8Zmw
8hwnRV7R8bPdkoIfnc8e
=jJzD
-----END PGP SIGNATURE-----

2023-06-07 17: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:39:30

- reply

📅 Original date posted:2015-09-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
ACK
- --
- ---
Douglas Roark
Senior Developer
Armory Technologies, Inc.
doug at bitcoinarmory.com
PGP key ID: 92ADC0D7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJV6bnBAAoJEGybVGGSrcDXoDAQAJyfypOpGjTQZFR4BAbJzOJ0
vbHv2QjBcf8/FJ7BxLyZYyIzwBBfYyacm69fETKgo2JyzfhFb3KsF7M0lsggBKRT
R5DFr6GRDXTC1p7L7II3U6oGRQ3yHbxvMyep/6CyJYGaEfdnlTinxYsb4WlFIiPh
ZMr9CH+hLHUb4s3Re5/Wl6RNz83ZNeJSAO5o2Iv/2+GCF3Iyh8UfADzDrnMOuWKE
6URhNVvCHvsxYgS/00QN8MW2Dn3txCrUEag10hJ59wlkWRDA26wHosB3m5w/arbO
3OzAkthrkImTYTCusX+Mcitvldc8J88YQD4kNOJvc472j0TTaksl/ubAvDUx1hon
aHdQqb/6A+kxhsvHox0BmUmoqDiAGsVPVJinCDVG8QRUDMVbVIhRgPLK5p9ND/Ab
B0Nm5zZgtyPnGUrY6Ci22xHmeJKcGVmYMudYEkwOOMK8x0AcnDifMu4NjWxxFwIN
Q1CSLuF7FGuAEenO9v/oZklLWrTZ4ewA4pM5uaYtTQHc3AD+Jg3/ZcmHQxDlSQMJ
EiaB5rvLXwvlLthDOtr3gEG+8f08KWl0eJijrhd6UQCvEsMje19LAXxuU49u2A3C
l1T2XzxPquGC1FfrWCwY+/pGsOaH7eNnCBBnBZGBuXWt3pFL2C0OVWPa3J9ZYj26
PYHDKl1eYP4trWGGY/T2
=G5PZ
-----END PGP SIGNATURE-----

2023-06-07 15: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 15:34:16

- reply

📅 Original date posted:2015-05-08
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello. I've seen Greg make a couple of posts online
(https://bitcointalk.org/index.php?topic=1033396.msg11155302#msg11155302
is one such example) where he has mentioned that Pieter has a new
proposal for allowing multiple softforks to be deployed at the same
time. As discussed in the thread I linked, the idea seems simple
enough. Still, I'm curious if the actual proposal has been posted
anywhere. I spent a few minutes searching the usual suspects (this
mailing list, Reddit, Bitcointalk, IRC logs, BIPs) and can't find
anything.
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
iQIcBAEBCgAGBQJVTQ4eAAoJEGybVGGSrcDX8eMQAOQiDA7an+qZBqDfVIwEzY2C
SxOVxswwxAyTtZNM/Nm+8MTq77hF8+3j/C3bUbDW6wCu4QxBYA/uiCGTf44dj6WX
7aiXg1o9C4LfPcuUngcMI0H5ixOUxnbqUdmpNdoIvy4did2dVs9fAmOPEoSVUm72
6dMLGrtlPN0jcLX6pJd12Dy3laKxd0AP72wi6SivH6i8v8rLb940EuBS3hIkuZG0
vnR5MXMIEd0rkWesr8hn6oTs/k8t4zgts7cgIrA7rU3wJq0qaHBa8uASUxwHKDjD
KmDwaigvOGN6XqitqokCUlqjoxvwpimCjb3Uv5Pkxn8+dwue9F/IggRXUSuifJRn
UEZT2F8fwhiluldz3sRaNtLOpCoKfPC+YYv7kvGySgqagtNJFHoFhbeQM0S3yjRn
Ceh1xK9sOjrxw/my0jwpjJkqlhvQtVG15OsNWDzZ+eWa56kghnSgLkFO+T4G6IxB
EUOcAYjJkLbg5ssjgyhvDOvGqft+2e4MNlB01e1ZQr4whQH4TdRkd66A4WDNB+0g
LBqVhAc2C8L3g046mhZmC33SuOSxxm8shlxZvYLHU2HrnUFg9NkkXi1Ub7agMSck
TTkLbMx17AvOXkKH0v1L20kWoWAp9LfRGdD+qnY8svJkaUuVtgDurpcwEk40WwEZ
caYBw+8bdLpKZwqbA1DL
=ayhE
-----END PGP SIGNATURE-----

2023-06-07 15:28:53

- reply

📅 Original date posted:2015-01-21
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2015/1/21 15:37, Gavin Andresen wrote:
> You mention the "DER standard" : should link to
> http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
>
>
(or whatever is best reference for DER).
The link you gave is to the 2002 revision.
http://www.itu.int/rec/T-REC-X.690-200811-I/en has the latest revision
(Nov. 2008) and, AFAIK, is the most visible link to people searching
for X.690.
That said, X.690 is the definitive DER document (if not exactly the
easiest read). A link to it wouldn't hurt.
> "this would simplify avoiding OpenSSL in consensus implementations"
> --> "this would make it easier for non-OpenSSL implementations"
>
> "causing opcode failure" : I know what you mean by "opcode
> failure", but it might be good to be more explicit.
>
> "since v0.8.0, and nearly no transactions" --> "and very few
> transactions..."
>
> "reducing this avenue for malleability is useful on itself as well"
> : awkward English. How about just "This proposal has the added
> benefit of reducing transaction malleability (see BIP62)."
These all 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
iQIcBAEBCgAGBQJUwBF8AAoJEGybVGGSrcDXBxcP/j9dKIeXkOvDFgSzON2hmjxT
nzpPcxovGt+ds1KqHMtuMm8+Mmc/Z8kOhKWzgQKYlxq8eQayQ4X/DUr97IY248NX
udVM6vEp/azPkXLOQnO6POpv8Il6twyuYGvFAHLiYe9k9qMfdSKZetx5xFKVBsuj
DhRY2TnWC7/OXNUrT7H5TPHDaGHyXeJ47XSOVjGQ/qxdczIzvmt11amZ/Vn2+uXh
Rvz+0CzbpXYaqYB04ZnIv5lxknmjWGbxPdht/SoOly8INehQacWnwUNZJpilKb6x
qEpbDGNxW2zHEFgfNHmtr9PCBN8KyiVnTt+VZpNNl7PJCxZiK6uiwyNxsmOBhBtm
Hrsvxb9GqEO/6PKesEo+Hi+6hhzzQRC6Xrf85SaFMzw9UjKuuRhstxx7XhudKFkN
lBJcxd40G7kWk0Gv+YQmhFUyXUBqloEFGrFlzWniFKaJGzZs5D0JPd83DsPI4RuT
0M63YabL8qplYN8vnyUXabFpzglvQdAFqZS2GsO6zwAeWrqxsojpcEpikj4T+izR
W1TzaRDdm5pEaMMxvb6wFIgO32uAjN1a8GrRj+uk5cxuiOuk/C4Ii18FYhqEtDNd
Gv80rPxWEOxbCoSqH6igPnySw3ePFLBzgC4eSLBTnqfKYltd8fTeS9wGy47+L1YO
qb5K/xlqt+REOdbTGLHi
=MNXG
-----END PGP SIGNATURE-----

2023-06-07 15: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-----

2023-06-07 15: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-----