Daniel Stadulis [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-06-04 to 2017-09-11
💬 Posted a total of 8 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:05:52

- reply

📅 Original date posted:2017-09-11
📝 Original message:I think it's relevant to treat different bug severity levels with different
response plans.
E.g.
Compromising UTXO custody (In CVE-2010-5141, OP_RETURN vulnerability)
Compromising UTXO state (In CVE-2013-3220, blockchain split due to Berkeley
DB -> LevelDB upgrade, CVE-2010-5139 Overflow bug, unscheduled inflation of
coins)
Compromising Node performance (Various node-specific DoS attacks)
Should have different disclosure policies, IMO
On Mon, Sep 11, 2017 at 4:34 AM, Alex Morcos via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I don't think I know the right answer here, but I will point out two
> things that make this a little more complicated.
>
> 1 - There are lots of altcoin developers and while I'm sure the majority
> would greatly appreciate the disclosure and would behave responsibly with
> the information, I don't know where you draw the line on who you tell and
> who you don't.
>
> 2- Unlike other software, I'm not sure good security for bitcoin is
> defined by constant upgrading. Obviously upgrading has an important
> benefit, but one of the security considerations for Bitcoin is knowing that
> your definition of the money hasn't changed. Much harder to know that if
> you change software.
>
>
>
> On Sun, Sep 10, 2017 at 10:15 PM, Anthony Towns via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-dev
>> wrote:
>> > I believe there continues to be concern over a number of altcoins which
>> > are running old, unpatched forks of Bitcoin Core, making it rather
>> > difficult to disclose issues without putting people at risk (see, eg,
>> > some of the dos issues which are preventing release of the alert key).
>> > I'd encourage the list to have a discussion about what reasonable
>> > approaches could be taken there.
>>
>> That seems like it just says bitcoin core has two classes of users:
>> people who use it directly following mainnet or testnet, and people who
>> make derived works based on it to run altcoins.
>>
>> Having a "responsible disclosure" timeline something like:
>>
>> * day -N: vulnerability reported privately
>> * day -N+1: details shared amongst private trusted bitcoin core group
>> * day 0: patch/workaround/mitigation determined, CVE reserved
>> * day 1: basic information shared with small group of trusted users
>> (eg, altcoin maintainers, exchanges, maybe wallet devs)
>> * day ~7: patches can be included in git repo
>> (without references to vulnerability)
>> * day 90: release candidate with fix available
>> * day 120: official release including fix
>> * day 134: CVE published with details and acknowledgements
>>
>> could make sense. 90 days / 3 months is hopefully a fair strict upper
>> bound for how long it should take to get a fix into a rc; but that's still
>> a lot longer than many responsible disclosure timeframes, like CERT's at
>> 45 days, but also shorter than some bitcoin core minor update cycles...
>> Obviously, those timelines could be varied down if something is more
>> urgent (or just easy).
>>
>> As it is, not publishing vulnerability info just seems like it gives
>> everyone a false sense of security, and encourages ignoring good security
>> practices, either not upgrading bitcoind nodes, or not ensuring altcoin
>> implementations keep up to date...
>>
>> I suppose both "trusted bitcoin core group" and "small group of trusted
>> users" isn't 100% cypherpunk, but it sure seems better than not both not
>> disclosing vulnerability details, and not disclosing vulnerabilities
>> at all... (And maybe it could be made more cypherpunk by, say, having
>> the disclosures to trusted groups have the description/patches get
>> automatically fuzzed to perhaps allow identification of leakers?)
>>
>> Cheers,
>> aj
>>
>> > On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:
>> > > Hi,
>> > >
>> > > Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
>> > > conference, and the subsequent discussion around responsible
>> disclosure
>> > > and industry practice, perhaps now would be a good time to discuss
>> > > "Bitcoin and CVEs" which has gone unanswered for 6 months.
>> > >
>> > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -March/013751.html
>> > >
>> > > To quote:
>> > >
>> > > "Are there are any vulnerabilities in Bitcoin which have been fixed
>> but
>> > > not yet publicly disclosed? Is the following list of Bitcoin CVEs
>> > > up-to-date?
>> > >
>> > > https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
>> > >
>> > > There have been no new CVEs posted for almost three years, except for
>> > > CVE-2015-3641, but there appears to be no information publicly
>> available
>> > > for that issue:
>> > >
>> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641
>> > >
>> > > It would be of great benefit to end users if the community of clients
>> > > and altcoins derived from Bitcoin Core could be patched for any known
>> > > vulnerabilities.
>> > >
>> > > Does anyone keep track of security related bugs and patches, where the
>> > > defect severity is similar to those found on the CVE list above? If
>> > > yes, can that list be shared with other developers?"
>> > >
>> > > Best Regards,
>> > > Simon
>> > > _______________________________________________
>> > > bitcoin-dev mailing list
>> > > bitcoin-dev at lists.linuxfoundation.org
>> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> > >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170911/06bf75a1/attachment.html>

2023-06-07 17:44:04

- reply

📅 Original date posted:2015-11-02
📝 Original message:Google Docs formatted version:
https://docs.google.com/document/d/1t3kGkAUQ-Yui57P29YhDll5WyJuTiGrUhCW8so-E-iQ/edit?usp=sharing
Meeting Title:
#bitcoin-dev Weekly Development Meeting
Meeting Date:
2015-10-29
Meeting Time:
19:00-20:00 UTC
Participants in Attendance:
dstadulis
morcos
sipa
jgarzik
rusty
warren
jeremyrubin
evoskuil
Luke-Jr
dcousens
gmaxwell
jtimon
mcelrath
btcdrak
IRC Chat Logs:
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/29#l1446145135.0
--------------------------------------------------------------------------------
Topics discussed:
1. Upcoming softfork
1.1 Solely CLTV (morcos, petertodd, dcousens)
1.2 Softfork coordination with other clients
2. Chain Limits Agreement Status
2.1 What should be sufficient consensus for merges?
3. Backporting Policy
4. Leveldb Replacement
4.1 Can be considered when code is abstracted, allows for testing,
alternative implementations exist. Testing encouraged, no future moves
planned.
5. Clang format
5.1 History review: Proposal a while ago was to clang-format file set <a b
c ...> Once done, maintain those files' formatting with automation (git
hook checks or whatnot)
5.2 Clang format behavior changes "randomly" from version to version.
6. BIP-68: “Mempool-only sequence number constraint verification”
Implementation PR #6312
6.1 Concern regarding skipping missing inputs
7. BIP-112: Mempool-only CHECKSEQUENCEVERIFY PR #6564
2015-10-29 Meeting Conclusions:
#
Action items
Responsible Parties
ETA/Due Date
1
Morcos to report chain stats
2
Review BIP68 implementation #6312
sipa, rusty
--------------------------------------------------------------------------------
Meetingbot Minutes
Minutes(HTML)
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-29-19.02.html
Minutes(text)
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-29-19.02.txt
IRC Log:
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-29-19.02.log.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151102/c44e94e9/attachment.html>

2023-06-07 17:43:25

- reply

📅 Original date posted:2015-10-15
📝 Original message:It makes economic sense to include a transaction on the Lightning Network,
iff the the fee to include the transaction on the blockchain is more than
than the Time Value of Money of the encumbered funds on the Lightening
Nodes amortized across the number of users pushing funds through a LN node.
Large-value transactions are going to hit the blockchain while smaller,
predictable, closer-to-median transaction-rates transactions will go into
the Lightning Network
Blockchain: Car Purchase, House Purchase, Unexpected Medical Expense
Lightning Network: Utility Bill, Groceries, Rent, Mortgage.
> If transactions happen in a big percent offchain, and they are only
> broadcasted on the mainchain where funds are moved in or out of the
> lightning network, this means there will be less transactions on the
> mainchain
This is optimal because the network has minimized the set of
costs/externalities to the minimum necessary to conduct a series of
transactions
> -> less fees collected by the miners.
“It's tough to make predictions, especially about the future.”
The effect on fees is going to be hard to predict.
1.) One part depends on user behavior around the dynamics of bid-side
demand of fees. I.e. If there is a health ratio of
-users who want 1-block- times but are unwilling/unable to bid up the fee
of their transactions to push out other 1-block-confirmation transactions (AKA
how firm is that fee support presently and under dynamic conditions)
to
-users who take their transactions off the blockchain to LN
2.) New classes of transactions will be possible that aren't possible today.
3.) What market effect will the financial/technical potential of 'instant'
transaction (after a network-joining-intro period) have on Bitcoin's
utility/price/adoption?
It would be elucidating if any blockchain data scientists could study the
effect of the fee market when high-volume exchanges unexpectedly halted
trading.
> What will happen when the block reward will go away?
I believe a more specific question to ask is: What will happen when there
isn't a convincing economic reason for a large majority of hashing power to
be bolstering PoW defense on the main blockchain? Right now we have a
pretty good handle on the amount of hashing power that's pointed at
extending/defending the 'main' chain but don't have as good intel on how
much idle hashing power there is. Idle hashing power becomes more of a
threat in market scenarios where chain-extending PoW is scarce (late-game
Bitcoin).
My humble prediction is that the necessary number of block confirmation
will go up and there were be non negligible mining power idle ready to
defend actors' preferred chain. If this is the scenario that plays out, I
don't think it'll be very concerning; large-value transaction that will be
on the blockchain have more flexible time-settlement tolerance (no one
needs their home-buying escrow to settle in <= 1 day) and lower-value
transaction that users want/need to be confirmed quickly will be confirmed
'instantly' over Lightning Network or another Bitcoin-anchored protocol.
P.S. I see lots of concern with respect to fee reduction directed at LN
while today there are already off-chain databases that remove fee
pressure. Like the LN / off-chain databases or not, they will exists.
Daniel Stadulis
On Wed, Oct 14, 2015 at 8:37 AM, Bryan Bishop via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Oct 14, 2015 at 10:19 AM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > However, the two are also perfect compliments, as LN transactions cannot
> take place at all without periodic on-chain transactions.
>
> Additionally, lightning network hot wallets are not an ideal place to
> store large quantities of BTC and users that don't expect to be
> actively using LN should in general prefer confirmed UTXOs for
> long-term cold storage. So far the guess that I have seen floating
> around is that LN usage will at first be restricted to very tiny
> amounts of BTC in tiny hot wallets, since nobody is particularly
> interested in running large hot wallets.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151014/310ad764/attachment.html>

2023-06-07 17:43:07

- reply

📅 Original date posted:2015-10-09
📝 Original message:More readable Google Doc version with html links here:
https://docs.google.com/document/d/1hCDuOBNpqrZ0NLzvgrs2kDIF3g97sOv-FyneHjQellk/edit?usp=sharing
Meeting Title:
#bitcoin-dev Weekly Development Meeting
Meeting Date:
2015-10-08
Meeting Time:
19:00-20:00 UTC
Participants in Attendance:
dstadulis
wumpus
btcdrak
morcos
petertodd
bsm117532
BlueMatt
gmaxwell
GreenIsMyPepper
phantomcircuit
warren
sipa
IRC Chat Logs:
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/08#l1444329019.0
———------------------------------
Topics to be discussed:
1. Mempool limiting
2. Partial transaction malleability fix: Low-S change (releases 0.10.3, 0.11.1
backport)
3. CHECKLOCKTIMEVERIFY (CLTV) backport reviews
4. CHECKSEQUENCEVERIFY (CSV) reviews
5. Creation of [bitcoin-discuss] mailing list planning
———------------------------------
2015-10-08 Meeting Conclusions:
Ecosystem Warnings & Alerts:
There is a Bitcoin ecosystem threat with the potential to cause millions of
dollars in losses that needs higher visibility. It's not a Bitcoin Core /
Bitcoin network issue but most Javascript-based Bitcoin software is
affected. The issue, documented here
https://github.com/feross/buffer/pull/81, is about common, critical,
Javascript code that is broken and may cause the generation of incorrect
pubkeys (among other issues). If Javascript is part of your implementation,
you should read the referenced pull request.
#
Action items
Responsible Parties
ETA/Due Date
1
Review/test code for Pull Request #6722 "Limit mempool by throwing away the
cheapest txn and setting min relay fee to it".
All
Unspecified
2
Provide ACK’s/support for low limits on PR #6771 "Policy: Lower default
limits for tx chains".
All
Unspecified
4
Urgent code review and ACKs of CLTV backports PR:
#6706 “CLTV IsSuperMajority() soft-fork, rebased for v0.10.2”
#6707 “CLTV IsSuperMajority() soft-fork, rebased for v0.11.0”
All
Unspecified
5
Contact miners about PR #6769 "Test LowS in standardness, removes nuisance
malleability vector" and turning on the long-existing anti-malleability
standardness rules in Bitcoin Core
Bluematt & Gmaxwell
Unspecified
6
Clarification from maaku regarding nSequence for BIP68
Continue review and ACKs of PR
#6312 “BIP-68: Mempool-only sequence number constraint verification”
#6564 “BIP-112: Mempool-only CHECKSEQUENCEVERIFY”
#6566 “BIP-113: Mempool-only median time-past as endpoint for lock-time
calculations”
All
Unspecified
7
Mailing Lists: [bitcoin-discuss] creation, moderators assignment of discuss
and dev list, simple website for mailing list policy.
Warren
Discussion meeting scheduled for: 2015-10-12 19:00-20:00 UTC
Meetingbot Minutes
Minutes(HTML)
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-08-18.59.html
Minutes(text)
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-08-18.59.txt
IRC Log:
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-08-18.59.log.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151009/6a9cdac3/attachment.html>

2023-06-07 17:42:19

- reply

📅 Original date posted:2015-10-02
📝 Original message:Meeting Title:
#bitcoin-dev Weekly Development Meeting
Meeting Date:
2015-10-01
Meeting Time:
19:00-20:00 UTC
Participants in Attendance:
dstadulis
wumpus
morcos
gmaxwell
btcdrak
jonasshnelli
maaku
sdaftuar
sipa
BlueMatt
CodeShark
Luke-Jr
bsm117532
jgarzik
IRC Chat Logs:
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/01#l1443726030.0
----------------------------
Topics Discussed:
1.) Mempool limiting
2.) BIP68 + CHECKSEQUENCEVERIFY
3.) CLTV soft fork deployment
4.) libconsensus merge time window
4.1) Agreement there should be a merge window for move-only changes
4.2)jtimon will document higher-level rationales for moves, so people can
first agree on what should move where
----------------------------
2015-10-01 Meeting Conclusions:
#
Action items
Responsible Parties
Due Date/ETA
1
Mempool limiting:
BlueMatt: to finish 6722 code.
Others:Try attacking 6722, 6557, and 6673 to see edge-case behavior
BlueMatt et al
Undetermined due date
2
morcos email dev list with chain-limit proposal, sdaftuar will review
proposal before list is emailed
morcos & sdaftuar
Undetermined due date
3
CLTV backport PRs #6706 and #6707 (backport 0.10 and 0.11 respectively)
need review ASAP
All
ASAP
4
Need reviews/ACKs of
BIP68 #6312,
BIP112 CSV #6564,
BIP113 #6566
All
By 2015-10-08
5
Document higher-level rationales for libconsensus moves, so people can
first agree on what should move where
jtimon
Undetermined due date
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151002/cb02ea18/attachment.html>

2023-06-07 17:41:19

- reply

📅 Original date posted:2015-09-24
📝 Original message:If you weren't able to attend the first, weekly development meeting, the
following are the minutes:
Meeting Title:
#bitcoin-dev Weekly Development Meeting
Meeting Date:
2015-09-24
Meeting Time:
19:00-20:00 UTC
Participants in Attendance:
luke-jr
CodeShark
sipa
morcos
sdaftuar
dstadulis
jtimon
wumpus
jgarzik
kanzure
gmaxwell
cfields
gavinandresen
IRC Chat Logs:
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/09/24#l1443121200.0
------------------------------
Topics Discussed:
1.
libconsensus and refactoring
2.
All goals for 0.12 release
1.
libsecp256k1 is ready for 0.12?
1.
libsecp256k1 needs a native OSX travis build
1.
cfields has work that moves to the new Travis infrastructure
2.
PROPOSAL: propose libsecp256k1 validation PR as soon as all
currently-in-pipeline API changes are merged
2.
OP_CHECKSEQUENCEVERIFY
3.
mempool limiting
4.
version bits
3.
BIP process
4.
Split off script base classes/execution for use in consensus?
5.
Current/near-term “what are you working on”
1.
versionbits: Codeshark has been working on an implementation
2.
gavinandresen: simple benchmarking framework then plan on optimizing
new block relay/broadcast.
------------------------------
Meeting Conclusions:
Mempool limiting discussion will be delayed until 2015-10-1 meeting
#
Action items
Responsible Parties
ETA
1
Please review 6557 (starting Saturday), 6673 and any other mempool pulls
for concept
Everyone
Next Thurs. meeting (2015-10-01)
2
libsecp256k1 needs a native OSX travis build
3
Propose libsecp256k1 validation PR as soon as all currently-in-pipeline API
changes are merged
4
Review BIP 68, review #6312, #6564
5
versionbits BIP number assignment
gmaxwell
2015-09-25
Google Doc:
https://docs.google.com/document/d/1zsWVaf5H9ECrN1zPutMdD_2ky3fnhQUM411NDrRrc-M/edit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150924/2554b5f9/attachment-0001.html>

2023-06-07 17:37:28

- reply

📅 Original date posted:2015-08-24
📝 Original message:See responses in line.
On Thu, Aug 20, 2015 at 8:28 PM, odinn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> A visualization I would like to see would include:
>
> pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP sipa
> etc) based on what's published in blocks.
>
Pie charts are a poor tool to visualize data.
See:
https://www.stevefenton.co.uk/2009/04/pie-charts-are-bad/
Bar charts are better:
http://blog.visual.ly/how-groups-stack-up-when-to-use-grouped-vs-stacked-column-charts/
Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150824/18e35004/attachment.html>

2023-06-07 15:48:55

- reply

2023-06-07 15:36:34

- reply

📅 Original date posted:2015-06-04
📝 Original message:Off topic and inappropriate
On a meta level, all the anti-Todd comments are originating from
*@airmail.cc accounts.
On Thu, Jun 4, 2015 at 2:54 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> Why is this your business or the business of anyone on this list? Take it
> somewhere else.
>
> On Thu, Jun 4, 2015 at 2:52 PM, Sven Berg <svenberg at airmail.cc> wrote:
>
>> 1) Hours/week have you devoted to each project out of a 40hr work week
>>
>> 2) Upfront and ongoing fees for use of your name
>>
>> 3) Break down total amounts for each project
>>
>> 4) Start dates of contracts for each project
>>
>> 5) End dates (if applicable)
>>
>> 6) Current and past holdings of altcoins/appcoins (including liquidation
>> dates)
>>
>> 7) Describe return on investment to investors related to your activities
>> during employment
>> (other than marketing/price pump)
>>
>> 8) Describe your involvement with Initial Coin Offers (ICO) of
>> applicable
>>
>> 9) Explain rational for pursuit of ICO fund sources rather than
>> community/established
>> businesses (Lighthouse, legit startups, etc.)
>>
>> --
>> Berg Investigations LLC.
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150604/2eeea72f/attachment.html>