On Monday, March 03, 2014 3:34:27 AM Kevin wrote:
> Hello. I am a developer and I wish to contribute to bitcoin. Where is
> the best place to start?
Unit tests. This will be valuable to the projects and also help you learn how
things work.
--
On Sunday, March 02, 2014 11:02:14 PM Tom Geller wrote:
> Peter writes:
> > MtGox does host the bitcoin wiki, so yes, the funds probably do go to a
> > wallet held by MtGox in some fashion.
>
> The foolishness of sending a payment to a Mt. Gox-held wallet -- which is
> required to edit the wiki --
On Mar 2, 2014, at 21:34, Kevin wrote:
> Hello. I am a developer and I wish to contribute to bitcoin. Where is
> the best place to start?
>
> --
> Kevin
Reading and learning the reference client’s source code, or doing the same for
any number of non-reference-client Bitcoin projects.
Wi
Hello. I am a developer and I wish to contribute to bitcoin. Where is
the best place to start?
--
Kevin
--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-
Peter Todd wrote:
>> I proof-read rc1 and simply submitted my changes via pull-req:
>>
>> https://github.com/bitcoin/bitcoin/pull/3642
Drak responded:
> Actually, this is unnecessary since github allows editing of files directly
> on the site and the it will submit as a pull request. You ca
On 2 March 2014 20:40, Peter Todd wrote:
> I proof-read rc1 and simply submitted my changes via pull-req:
>
> https://github.com/bitcoin/bitcoin/pull/3642
>
> I'd say to encourage that method. If someone doesn't know how to use
> git, yet still wants to proof-read, just send us a text-file wi
The domain bitcoin.org resolves to that IP address. Could it be some
update check together with a circular redirect? That could at least
explain the large number of connection attempts.
--
Christian Decker
On Sun, Mar 2, 2014 at 9:56 PM, Wladimir wrote:
>
> On Sun, Mar 2, 2014 at 7:34 PM, James
Didn't mean that bitcoind was connecting over port 443. I didn't even get a
chance to compile. I was literally just finished downloading the tar.gz
file when my server was terminated.
Still trying to convince them I wasn't attacking anyone so they can
re-enable the server.
Thanks,
--
James Hartig
On Sun, Mar 2, 2014 at 7:34 PM, James Hartig wrote:
> Heads up... downloaded the linux tar.gz to my OVH box and got my server
> terminated. Screenshot from the email:
> http://cl.ly/image/3q0C2a3Y0T0V
>
> They claimed I was attacking 88.198.199.140 over port 443.
>
Sounds very unlikely that bitc
On Sun, Mar 02, 2014 at 03:10:09PM -0500, Tom Geller wrote:
> Hey, folks. Sorry if this is documented somewhere -- if so, just point me at
> it. I couldn't find it, though.
>
> I'm a (non-developer) writer with experience in open-source communities, and
> I'd like to contribute with writing/edit
Hey, folks. Sorry if this is documented somewhere -- if so, just point me at
it. I couldn't find it, though.
I'm a (non-developer) writer with experience in open-source communities, and
I'd like to contribute with writing/editing/marketing. What's the procedure? Is
there someone in charge of th
Again, the two best ways are here:
https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
https://bitcointalk.org/index.php?topic=321228
But this is off-topic, Peter wasn't talking about cross-chain trade.
On 3/2/14, Troy Benjegerdes wrote:
> I'm asking for how to DEVELOP THE CO
Heads up... downloaded the linux tar.gz to my OVH box and got my server
terminated. Screenshot from the email:
http://cl.ly/image/3q0C2a3Y0T0V
They claimed I was attacking 88.198.199.140 over port 443.
Thanks,
--
James Hartig
Software Engineer @ Grooveshark.com
http://twitter.com/jameshartig
On Fri, Feb 28, 2014 at 10:26:39PM -0800, Jeremy Spilman wrote:
> We currently have subtle positive feedback of a signed payment request in
> the form of the green background. Unsigned requests simply show up without
> the green background, as well as requests which provide a certificate but
I'm asking for how to DEVELOP THE CODE so I can trade between two block
chains, and then I'm going to start trading cats and dogs and bits.
Somewhere in trying to figure out the design spec we got caught up in
existential
concern about 'globally knowable and accurate price history', and I'm tell
On Sun, Mar 2, 2014 at 4:20 PM, Andreas Schildbach wrote:
> I somehow think that it is too early for this heavy kind of extension,
> given that the first version of BIP70 isn't even deployed widely let
> alone *used*.
>
Definitely agree - like I said, I publish this only because I keep getting
as
I somehow think that it is too early for this heavy kind of extension,
given that the first version of BIP70 isn't even deployed widely let
alone *used*.
By reading your proposal I get the idea that the current spec doesn't
allow two (or three) different PKIs at once -- we would want this for
migr
Please download and help test 0.9.0rc2; binaries are available from:
https://bitcoin.org/bin/0.9.0/test/
If no serious bugs are found in this release candidate, it will be the
final 0.9.0 release.
Release notes (please help proofread/improve these, too):
---
Thanks Andreas.
For BIP standardisation, I think the VIEW intent seems like an obvious one.
Bluetooth support probably should come later if/when we put encryption/auth
on the RFCOMM link (probably SSL).
--
Flow-based real-
On Sat, Mar 1, 2014 at 9:07 PM, Dev Random wrote:
> I'm wondering about the small business case. A small business or an
> individual might not have the technical expertise to perform the
> delegation signature.
If they take delivery of an SSL cert from the CA themselves, I don't see
why it'd be
>
> Perhaps the UI just isn't expressive enough currently to expose this
> situation in any way, let alone reliably alert the user to the issue,
> because there's no way for the payment processor to get authenticated
> fields other than memo into the UI.
>
I think for now as long as payment proces
I'm just repeating the rationale Gavin gave me for adding this to the spec
last year when he was implementing it. Perhaps it only applied to some
versions of PHP or something like that.
Jeremy, good comments. A pull request to fix those would be good.
One issue I seem looming on the horizon is th
I'm hoping I can convince Saivann to do a bit of graphics work for this at
some point :-)
Something like a green stamp that appears (like a watermark) in the
background, might be good.
On Sat, Mar 1, 2014 at 8:50 AM, Jeremy Spilman wrote:
> On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir wrote:
On Fri, 28 Feb 2014 03:46:49 -0800, Mike Hearn wrote:3) Whilst these payment processors currently verify merchants so the security risk is low, in future a lighter-weight model or competing sites that allow open signups would give a weak security situation: a hacker who compromised your computer
I've written up a document about all the different methods on how the
payment protocol (both the old one and BIP70) is used in Bitcoin Wallet.
It only provides an overview -- I plan to go into details with separate
(BIP?) documents where needed.
https://github.com/schildbach/bitcoin-wallet/wiki/Pa
Not true, PHP does support sha2
http://php.net/manual/en/mhash.constants.php
http://php.net/manual/en/function.hash-algos.php#refsect1-function.hash-algos-examples
On 2 Mar 2014 08:44, "Mike Hearn" wrote:
> SHA-1 support is there for PHP developers. Apparently it can't do SHA-2.
> On 2 Mar 2014
SHA-1 support is there for PHP developers. Apparently it can't do SHA-2.
On 2 Mar 2014 08:53, "Jeremy Spilman" wrote:
> From BIP70:
>
>If pki_type is "x509+sha256", then the Payment message is hashed using
> the
>SHA256 algorithm to produce the message digest that is signed. If
> pki_typ
27 matches
Mail list logo
