Scott Howard [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-09-14 to 2014-05-19
💬 Posted a total of 6 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:21:43

- reply

📅 Original date posted:2014-05-19
📝 Original message:On Mon, May 19, 2014 at 3:11 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> On Sun, May 18, 2014 at 1:43 PM, Raúl Martínez <rme at i-rme.es> wrote:
>> - bitcoind and Bitcoin Core should be in Linux repos:
>
> Agreed with conditions:
> 1) The distro MUST let bitcoin devs dictate which dependent libs are
> shipped with / built statically into the bitcoin binaries/libs.
> 2) The distro MUST permit fresh updates even to older stable distros.
> 2) The maintainer(s) MUST be active, and follow bitcoin development,
> release status, etc. on a near-daily basis, be able to respond quickly
> if security issues arise, etc.
>
> Matt C seems to do a good job of this in Ubuntu PPA, I'm told.
Update:
(1) and (3) are doable, however, Debian and Ubuntu policies make (2)
very difficult (with the exception of security patches). Micha Bailey
and I worked to get bitcoin removed from Debian and Ubuntu stable
releases because they would not allow (2). There are other mechanisms
that could accomplish (2) (backports, volatile, and updates
repositories), however they are not enabled by default and require
user intervention.
Debian unstable does allow (2) since there is no release, and there is
a package in Debian unstable. That package is blocked from
transitioning to a stable release. We've also blacklisted it from
Ubuntu so that Ubuntu doesn't just autoimport and release the Debian
unstable package in an Ubuntu stable release.
Micha is also working to have all old versions of bitcoin removed from
previous released Ubuntu versions.
Matt C's PPA is the best way of getting (1-3) above on Ubuntu, and the
Debian unstable package is probably the best way of getting (1-3)
above in Debian. Both require users to add a line to their apt sources
list; the Debian package would also require apt pinning.
Regards,
Scott

2023-06-07 15:05:08

- reply

📅 Original date posted:2013-07-23
📝 Original message:On Tue, Jul 23, 2013 at 9:45 PM, Douglas Huff <dhuff at jrbobdobbs.org> wrote:
> Honestly, until I read the quoted part of your response, I actually wasn't in favor of this whole thing since in general the types of issues being mentioned are, in large part, the types of issues that maintainers deal with all the time.
>
> On Jul 23, 2013, at 3:02 PM, Scott Howard <showard314 at gmail.com> wrote:
>
>> Response: Is there a way to "certify" the Debian libraries? Debian
>> bitcoind/bitcoin-qt runs the compile test during all architectures.
>> MIPS has been failing recently, but no one has looked into it yet.
>> Perhaps it's not worth developers efforts yet, but at some point the
>> technology should reach a point it can be redistributed.
>
>
> The fact that you're even trying to package and/or at some point have packaged and shipped big endian binaries is straight up *NEGLIGENT.*
>
> Stop that. Now. It won't work.
>
> Thanks for showing that this *is* necessary, I guess.
before people get too upset, I'm talking about little-endian MIPS
(debian-mipsel)
http://www.debian.org/ports/mips/

2023-06-07 15:05:08

- reply

📅 Original date posted:2013-07-24
📝 Original message:On Tue, Jul 23, 2013 at 6:26 PM, Luke-Jr <luke at dashjr.org> wrote:
> This means a lot of additional work for the
> maintainers of the library packages, and the security team; for example, the
> security team must understand that they *cannot* deploy a critical security
> bugfix to LevelDB until someone competent has reviewed that it is
> behaviourally (including bug behaviours!) compatible with the versions in use
> everywhere else/previously. I think it is likely all this additional
> work/delays will be considered unacceptable to your library/security teams,
> thus using the bundled/embedded LevelDB is probably the best solution.
The above is a key point, lukejr addressed it well "I think it is
likely all this additional work/delays will be considered unacceptable
to your library/security teams, thus using the bundled/embedded
LevelDB is probably the best solution."
>> MIPS has been failing recently, but no one has looked into it yet.
>> Perhaps it's not worth developers efforts yet, but at some point the
>> technology should reach a point it can be redistributed.
>
> MIPS (and any other big endian architecture) has *always* failed on the
> Satoshi codebase, and will not be supported until someone has time to dedicate
> to fixing the numerous little-endian assumptions in the code. I have an
> incomplete port, but it isn't very high on my priority list to figure out what
> else it's missing.
To be clear, bitcoind/bitcoin-qt is only built on little endian machines
https://buildd.debian.org/status/package.php?p=bitcoin
> Debian could probably get away with packaging Bitcoin-Qt and bitcoind as-is
> with no modifications, and not have any problems. It's only when you begin
> making modifications that it becomes a problem. There are also some concerns
> that it puts a much larger price on compromising Debian's build servers and/or
> repositories (suddenly the attacker can steal a LOT of money).
The only current modification is to use system leveldb instead of the
packaged leveldb. (There is also a patch porting libmemenv.a to
several other architectures, but that is only used in test suites - so
it shouldn't pose a risk to users).
>
> The official binaries are not simply built by upstream developers: using
> Gitian, *anyone* can produce bit-for-bit identical binaries. Official releases
> are only published after 3 or more people have done an independent compile and
> signed the output. It would be excellent if the whole of Debian could work
> toward achieving this level of security eventually, which would make
> distributing Bitcoin node software much safer as well.
Ironically, debian (in general) doesn't trust upstream security
maintenance of third part libraries - that's why they typically get
dropped in favor of use system libraries.
In this case, upstream doesn't trust (rightfully) that some future
debian security team bug fix to a stable library won't be tested
properly against bitcoin, causing problems for users (since bitcoin
might expect buggy library behavior).
I'm not the original packager or maintainer - I just came across the
package in really bad shape and helped bring it to something
reasonable and have done the most recent uploads (since 0.8, I
believe). Since updated libraries could pose a security risk because
bitcoin may expect buggy behavior, I think that is a good argument for
debian to use the included library. However, I'm just a recent helper
- I still want to hear what people who have been doing this for longer
think.
~Scott

2023-06-07 15:05:07

- reply

📅 Original date posted:2013-07-23
📝 Original message:On Tue, Jul 23, 2013 at 4:01 PM, Mike Hearn <mike at plan99.net> wrote:
> Hi,
>
> Some of us have put together an open letter to the Linux packaging
> community, outlining why Bitcoin is different to other programs and asking
> them to not patch or modify the upstream sources.
>
> Please consider signing it if you agree (I think the wording by now is fine,
> so don't edit the contents - use the comment feature if you want to though).
>
> https://docs.google.com/document/d/1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/edit#heading=h.i7tz3gqh65mi
>
> The trigger for this is the discovery that Debian bitcoind's got split out
> of the consensus some time in April, for reasons that nobody yet figured out
> but is presumably related to a patch (eg it uses system leveldb).
Hi Mike,
Debian's bitcoin is maintained on an open and archived mailing list
and git repo:
Debian Bitcoin Packaging Team <pkg-bitcoin-devel at lists.alioth.debian.org>
If there is a problem or question, getting an answer should be really
easy. It would be good to include them in the discussion there (I
CC:ed the list). If the upstream developers have a consensus that
distribution packaging is not in the best interest of the project,
then I personally would defer to their judgement and request removal.
I'm leaving this open for other opinions from the Debian side.
That said, let me summarize the arguments and see if we can figure out
a permanent solution:
1) It appears that the consensus of upstream developers is that any
distributed binary should only be linked against libraries that the
bitcoin developers have tested and audited since any compatibility bug
is a risk to both the user and the network.
Response: Is there a way to "certify" the Debian libraries? Debian
bitcoind/bitcoin-qt runs the compile test during all architectures.
MIPS has been failing recently, but no one has looked into it yet.
Perhaps it's not worth developers efforts yet, but at some point the
technology should reach a point it can be redistributed.
2) Bitcoin is new technology, so any patches have the ability of
harming both the network and user.
Response: I, and I'm sure everyone else working on it, totally agrees.
All patches are public [1], you can see that the patches are only to
the build system (except for one adding a debug message). Is there a
specific patch or bug that is problematic? This seems to be
reiterating (1) above: don't patch the build system to use libraries
that were not audited by the developers.
The two solutions are: (1) no one besides the upstream developers
compiles and distributes binaries, ever, or (2) upstream comes up with
a system where someone besides them can compile working binaries for
distribution. Most likely the best solution is to do (1) until
upstream sets up a system to allow (2).
I'm curious as to other's opinions.
Thanks,
Scott
[1] http://anonscm.debian.org/gitweb/?p=collab-maint/bitcoin.git;a=tree;f=debian/patches;h=ba576f9f3ddad47a2f85dcbfb7a0b3482834f19f;hb=HEAD

2023-06-07 11:44:15

- reply

📅 Original date posted:2013-04-07
📝 Original message:On Sun, Apr 7, 2013 at 10:43 AM, Oliver Egginger <bitcoin at olivere.de> wrote:
> Hello,
>
> I'm using your bitcoin-qt client (version 0.8.1). Normally everything is
> working pretty fine, but sometimes it seems that other nodes produce an
> enormous amount of traffic. I have not had the time to investigate
> thoroughly yet. I only have briefly viewed with tshark.
>
> So far I have just restarted the client in the hope that it no longer
> connects with the 'evil' node. This usually works quite well.
>
> Is anything about DOS-Attacks known to you?
Many new users have started using the reference client which downloads
the whole blockchain from peers. There currently isn't a throttling
mechanism [1] so it's possible to quickly eat up your bandwidth. You
can try QoS on your router or use the -nolisten command line flag. You
will still relay transactions, just not serve the whole blockchain.
[1] https://github.com/bitcoin/bitcoin/issues/273

2023-06-07 10:30:53

- reply

📅 Original date posted:2012-09-13
📝 Original message:This idea is from a Debian user [1].
What do you think of moving the > 2 GB db to $HOME/.cache/bitcoin and
leaving the wallet and other config files in $HOME/.bitcoin? This is
so backups can skip the .cache directory and the proposal follows the
freedesktop.org XDG Base Directory Specification [2]. Personal
info/settings stays in .bitcoin/ and everything that can be rebuilt
goes to .cache/bitcoin/ I know users can do a work around and set it
up themselves with symlinks, but interested in what you guys think.
Cheers,
Scott (Debian Developer but new to bitcoin)
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660286
[2] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html