Douglas Huff [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-06-17 to 2013-07-24
💬 Posted a total of 26 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 17:05:08

- reply

📅 Original date posted:2013-07-23
📝 Original message: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.

2023-06-07 04:18:48

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: Discussion on adding an RSA-like scheme for m-out-of-n signatures to Bitcoin. However, it does not solve the issue of malware on a PC. Proposed solution is to provide tools for offline wallets.
📝 Original message:On Aug 24, 2011 3:29 PM, "Gregory Maxwell" <gmaxwell at gmail.com> wrote:
>
> On Wed, Aug 24, 2011 at 3:05 PM, Christian Decker
> <decker.christian at gmail.com> wrote:
> > we could add an rsa-like scheme which allows m-out-of-n signatures. It
works
> > by distributing shares of the key which are points on a curve having the
> > actual key as 0-value. It does not require special length for the key so
if
> > ecdsa allows something similar there need not be anything changed.
>
> This works fine for ECC. But it requires that the composite key
> signer has simultaneous access to all the key-parts, so it doesn't
> solve the "my PC has malware" problem.
I don't think anything simple enough to actually be used by people in
general does. Same concept as what I proposed earlier before nanotube gave
me the context for Gavin's intent on irc.
Now that I'm understanding the use case I really think the best way to go
about this initially is like you said earlier.
Provide methods to export/import unsigned txns, provide methods to run the
GUI in a way that can track your own addresses with only pubkeys available
to the client, provide methods to sign and import/export/broadcast signed
txns.
With these tools offline wallets become feasible. Combined with wallet
crypto I think this is really the best that can be done to protect users
from themselves in a way that isn't too complicated for them to actually
use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110824/b20c936f/attachment.html>

2023-06-07 04:17:51

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: Gavin Andresen requested open-source, patent-free, and thoroughly-tested code for DSA-key-splitting. A third-party solution was suggested for a more traditional escrow setup.
📝 Original message:On Aug 24, 2011 10:12 AM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
>
> If anybody has some open-source, patent-free, thoroughly-tested code
> that already does DSA-key-splitting, speak up please.
>
If the caveat of a trusted third party is acceptable and, as greg mentioned,
if there was a way to export unsigned transactions and then import/broadcast
after signing this becomes fairly trivial.
Shamir's + 3rd party to combine and sign means no protocol level changes.
Process could work something like this:
Parties agree to endpoint destination address and provide it to third party.
Third party generates key and provides shares to each party in the txn and
the resulting address to both as well.
Third party destroys (preferably, never stores) private key.
Sender sends to address.
Both parties after confirmation of reciept of goods or what have you provide
shares back to third party who uses the privkey to xfer inputs to the
previously agreed upon destination subtracting their fee.
This resembles more traditional escrow setups and relies on the trust of a
third party, which is not ideal, but would be fairly simple to implement
until the other proposals could be better investigated and implemented.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110824/a6faa861/attachment.html>

2023-06-07 04:17:19

- reply

📅 Original date posted:2011-08-22
🗒️ Summary of this message: A discussion on daemonizing Bitcoin on boot and integrating it with standard coding and implementation paradigms on GNU/Linux platforms.
📝 Original message:I don't think you're actually familiar with either of those tools. A run
script is not much different than an init script?
Those who live in tonal caves shouldn't crap on themselves, or something.
On Aug 22, 2011 2:49 PM, "Luke-Jr" <luke at dashjr.org> wrote:
>
> On Monday, August 22, 2011 3:30:04 PM Douglas Huff wrote:
> > On Aug 22, 2011 2:26 PM, "Fred Concklin" <fconcklin at trucoin.com> wrote:
> > > I'm also interested in work to daemonize bitcoin on boot and
furthering
> > > work to bring bitcoin into general coding and implementation paradigms
> > > seen on GNU/Linux platforms.
> >
> > What? It already works fine in this regard using standard tools.
Especially
> > easy with daemontools/runit.
>
> He said standard *coding and implementation paradigms*. This has nothing
to do
> with integration with some non-standard "init replacement" that goes
against
> the whole design of Unix.
>
> What I understand this to mean, is properly abstracting the components
such
> that the node, wallet, and GUI can work together while being distinct
parts.
> In this sense, Fred, you may be interested in working on coming up with a
> standard for a https://en.bitcoin.it/wiki/Wallet_protocol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110822/cdad2324/attachment.html>

2023-06-07 04:08:32

- reply

📅 Original date posted:2011-07-27
🗒️ Summary of this message: Discussion on implementing a separated-from-GitHub bounty system for Bitcoin development, with concerns raised about unpaid bounties and the need for escrow.
📝 Original message:Don't worry Luke will basically say that about anything not related to
a crazy base16 number representation system that no decent modern font
can display.
To contribute:
I think the separated-from-github bounty system would be great. BUT:
The bounties need to go into some form of escrow. There have been way
to many bounties that weren't paid since BTC broke the $1USD boundary.
On Wed, Jul 27, 2011 at 9:53 AM, John Smith <witchspace81 at gmail.com> wrote:
> On Wed, Jul 27, 2011 at 2:42 PM, Joel Joonatan Kaartinen <joel.kaartine
>
>> Although, if GitHub can't support the feature, it could be an argument
>> for setting up a bug tracker unrelated to GitHub.
>
> Well if signing up with github is such a big problem we could make a list of
> bounties on our own site with a trivial web application, and link from there
> to github issues (if neccesary) for a description. It really doesn't matter
> how it's implemented. I think it is useless to discuss technical details or
> GitHub TOS right now, let's discuss the merit of ideas...
>
> JS
>
>
> ------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

2023-06-07 04:06:20

- reply

📅 Original date posted:2011-07-17
🗒️ Summary of this message: Matt Corallo expressed his dislike for forums and called them a "cesspool" in an email to the Bitcoin mailing list.
📝 Original message:On Jul 17, 2011 5:46 AM, "Matt Corallo" <bitcoin-list at bluematt.me> wrote:
> Its not that people dislike the forums or dislike having the forums.
Speak for yourself. I think they're a cesspool.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110717/21caa5db/attachment.html>

2023-06-07 04:06:07

- reply

📅 Original date posted:2011-07-16
🗒️ Summary of this message: Developers discuss the negative perception of Bitcoin forums and consider removing or replacing them to improve the project's image.
📝 Original message:On Jul 16, 2011, at 6:35 PM, Jeff Garzik wrote:
> On Sat, Jul 16, 2011 at 7:20 AM, John Smith <witchspace81 at gmail.com> wrote:
>> I know most of the people actively working on bitcoin (and active on this
>> list) ignore the forums, for good reason. But there's a lot of people
>> (everyone new?) that think the most active members of the forum have a major
>> influence on the project's direction. Which is making us as developers look
>> really bad. As if we're some political faction that wants to bring down
>> world governments and unleash a global anarchistic doomsday scenario.
>>
>> It really needs to be more down-to-earth. Ideally, the forum would simply be
>> a way to communicate with the *actual* users. For example, I use it for
>> soliciting user feedback on UI features.
>
> I agree completely.
>
> While the owner of the forums and bitcoin.org is Missing In Action and
> has not responded to emails in more than a week, we do have access to
> change the main www.bitcoin.org home page, to link to another forum.
>
> Or we could simply de-link the current forum, as a first step.
I say just kill the forum.bitcoin.org DNS entry along with it.
--
Douglas Huff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 881 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110716/bad72c74/attachment.sig>

2023-06-07 04:04:18

- reply

📅 Original date posted:2011-07-10
🗒️ Summary of this message: Bitcoin's long build times are due to the use of boost, lack of module isolation, and implementations in header files, making adding new code difficult.
📝 Original message:On Jul 10, 2011, at 5:37 PM, Michael Offel wrote:
> 4. long build times
>
> It takes longer to build Bitcoin than building some of the million lines of code projects I'm working on. The reasons I did see so far is the use of boost, lack of module isolation and implementations in header files.
I've actually offered (on irc) to fix the latter a few times and been told that a pull removing implementations from the headers would not be merged so have not wasted the effort. (Because it's a rather large one.) Not only does this cause long build times it makes adding new code in the logically "right" places nearly impossible due to the build deps.
I agree with pretty much the entirety of your post and think all of it needs to be discussed further and addressed.
--
Douglas Huff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 881 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110710/8da88a61/attachment.sig>