On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik jgar...@bitpay.com wrote:
It would be nice if the issues and git repo for Bitcoin Core were not
on such a centralized service as github, nice and convenient as it is.
Despite my complaining about github, I don't like the idea of moving
Just as an aside to this lengthy convo, the Cryptonote-based BCN recently
had some interesting updates which made it easier for ordinary computers
(nothing special) to handle it.
I realize that's not Bitcoin, but I thought I'd throw it out there.
Indeed, I am aware of current
Wait, I thought SOCKS4 was supposed to help somehow in terms of prevention
of leaking of information?
Or maybe I am misremembering. Here's what I'm thinking of...
2) More regarding TOR,
I keep seeing these warnings
On Mon, Jul 7, 2014 at 8:34 AM, Odinn Cyberguerrilla
Wait, I thought SOCKS4 was supposed to help somehow in terms of
of leaking of information?
SOCKS4a (unlike SOCKS4) supports doing DNS lookups on the server, but
it is not supported
Hoping that this is the right place for this, I am asking a question as to
what happens with what is in the CoinJoin bounty fund address at:
(a P2SH / multisignature address)
I encouraged people to donate to it in late 2013
I have been noticing for some time the problem which Mike H. identified as
how we are bleeding nodes ~ losing nodes over time.
This link was referenced in the coindesk article of May 9, 2014:
I completed a whitepaper for Bitcoin a proof-of-stake version which uses a
single nomadic verifiable mint agent and distributed replication of a
single blockchain by compensated full nodes to achieve 6-hop, sub-second
transaction acknowledgement times. Plus it pays dividends to holders
I am curious if the Android developer who had been working on two factor
authentication and bitcoin had worked toward an open issue or pull
request? I had been looking around for some sign that this had occurred
but hadn't found it, I am interested to know what is the progress in this
area (in a
You are right there is a bug in there.
But the value is not 25% I think. Tinker some more. :-)
I think i see a bug:
line 273 of key.cpp
if (rec0 || rec=3)
Afaict, 3 is a perfectly valid value, meaning 25% of sig- key recoveries
I wish to state that I fundamentally disagree with this proposal of use
cases for W3C payments workshop. Please read my following explanation and
then do what you will:
At one time I was invited to join the Web Payments conference calls. I
considered it and then declined due to the very CLAs
I see a lot of talk on this topic and get the senst that it is focused on
default display only regarding the mBTC / uBTC questions. However, if the
focus is broader, involving whether or how to express other currencies or
moving further along to what that might even mean (since many
I wanted to just add a very brief note to this discussion, that presently
for multisignature creation and management (new transaction etc) I've been
using this: https://coinb.in/multisig/
There were some initial bumps in the road but they were worked out,
see full thread more or less
One wonders also re. bitmessage, though that may not be relevant to this
On Wed, Mar 05, 2014 at 11:21:52AM -0500, Kevin wrote:
On 3/5/2014 7:49 AM, Mike Hearn wrote:
A new practical technique has been published that can recover
secp256k1 private keys after observing OpenSSL
Nothing is safe.
Take risks. Engage one trouble at a time.
Perform unexpected actions.
Observe the results.
Rinse and repeat.
Ignore the lions. They too shall pass.
Do not sleep under a roof. Carry no money or food. Go alone to places
frightening to the common brand of men. Become a
So, just to be clear, we're adding, say, a memory limited mempool or
something prior to release so this fee drop doesn't open up an obvious
low-risk DDoS exploit right? As we all know, the network bandwidth
DoS attack mitigation strategy relies on transactions we accept to
Am suggesting a (possible) mitigation of [possible flooding, etc], via
some kind of discussion (potentially process BIP, related to bundling and
/ or randomization) not now, but down the road. However, needs more
thought and analysis (you mentioned code audit?) before it could be
here's another question that I have:
I'd like a small bit of clarification about the gettx / getrawtransaction
(decoded) api call. I understand that I can find the address that a
transaction output is directed at / available to for future use sits in
vout array in the
I have a request, which is how do developers address the circumstance in
which someone utilizes your code as part of some effort to deprive (or
steal as the case may be) someone of their bitcoin?
This hasn't happened to me, but I have posed a question about it at
Greatly appreciate seeing this discussion occur. This is something that
potentially could be supported through a bounty - possibly a process BIP?
Possibly related: https://gist.github.com/ABISprotocol/8515891
Yes, recurring payments and subscriptions is a frequently-requested
ABISprotocol hat: on
stuff not getting into blockchain in a day's time,
microdonations not facilitated as much as they could be,
that would be:
Seriously, that would not be so good.
Hope I made you laugh a bit
vendor hat: on BitPay sure would like
implement aspects of the ABIS concept as presented, but it is in very very
I hope you had a good laugh, that was my intent. good morning / afternoon
On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla
Yes. Good idea(s).
Might I propose reusable address.
I think that describes it best to any non-programmer, and even more so
encourages wallets to present options as 'one time use' vs 'reusable'.
It definitely packs a marketing punch which could help drive adoption. The
feature is only
Hello Peter et. al.
As I read more into this stealth discussion I am curious to know what you
think of the background microdonation concept I posted recently.
It is shown in full here
Given the lengthy nature of the concept as
I've been lurking on this convo since it began, but I wanted to say
cheers to you all and yay for decentralization, wherever it leads.
muh latest: http://github.com/ABISprotocol/ABIS
On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote:
It's not just about trust, there is the
Hello, re. the dedicated server for bitcoin.org idea, I have a few thoughts
1) I have commented in a blogpost of August 2013 at
https://odinn.cyberguerrilla.org/ with some thoughts relative to possible
issues with CA related to bitcoin.org - where I mentioned something
relative to the DigiCert
Mail list logo