that I'm perfectly fine with accepting the rules for
seed.bitcoinstats.com
Regards,
Christian
--
Christian Decker
On Mon, Jul 21, 2014 at 2:43 PM, Wladimir wrote:
> We've established a few basic rules for the DNS seeds as used in the
> Bitcoin Core software. See below.
>
>
+1 for the new field, overloading fields with new meaning is definitely not
a good idea.
Something like nExpireAt with a block height sounds reasonable to me, but
we need to document that the usual caveats with blockchain reorgs apply.
On Wed, Aug 6, 2014 at 4:08 PM, Jeff Garzik wrote:
> ...b
that a parallel network, external to Bitcoin, could take over the
task of advertising external services.
Regards,
Chris
--
Christian Decker
On Fri, Aug 8, 2014 at 11:26 AM, Wladimir wrote:
> On Fri, Aug 8, 2014 at 12:15 PM, Wladimir wrote:
> > On Fri, Aug 8, 2014 at 12:01 PM, Mik
Thanks for bringing this to my attention.
I added a safety check to my crawler and seed.bitcoinstats.com should
not return IPs that also run HTTP or HTTPS, hopefully this'll keep it
off blacklists :-)
--
Christian Decker
On Sat, Dec 20, 2014 at 9:57 AM, Matt Corallo wrote:
> There was
The propagation speed gain from having smaller blocks is linear in the size
reduction, down to a small size, after which the delay of the first byte
prevails [1], however the blockchain fork rate increases superlinearly,
giving an overall worse tradeoff. A high blockchain fork rate is a symptom
of
Hi All,
I'd like to propose a BIP to normalize transaction IDs in order to address
transaction malleability and facilitate higher level protocols.
The normalized transaction ID is an alias used in parallel to the current
(legacy) transaction IDs to address outputs in transactions. It is
calculate
Glad you like it, I was afraid that I missed something obvious :-)
The points the two of you raised are valid and I will address them as soon
as possible. I certainly will implement this proposal so that it becomes
more concrete, but my C++ is a bit rusty and it'll take some time, so I
wanted to g
spending transaction, but the fix is trivial and can be done without
> access to the private key.
> On May 13, 2015 5:50 AM, "Christian Decker"
> wrote:
>
>> Hi All,
>>
>> I'd like to propose a BIP to normalize transaction IDs in order to
>> add
On Wed, May 13, 2015 at 8:40 PM Pieter Wuille
wrote:
> On Wed, May 13, 2015 at 11:04 AM, Christian Decker <
> decker.christ...@gmail.com> wrote:
>
>> If the inputs to my transaction have been long confirmed I can be
>> reasonably safe in assuming that the trans
Ok, I think I got the OP_CHECKAWESOMESIG proposal, transactions keep
referencing using hashes of complete transactions (including signatures),
while the OP_CHECKAWESOMESIG looks up the previous transaction (which we
already need to do anyway in order to insert the prevOut pubkeyScript),
normalizes
urn out to be possible. I don't thing we loose
anything by attempting this, except maybe reduce the urgency to apply some
perfect future thing.
Regards,
Christian
On Thu, May 14, 2015 at 1:01 PM, Christian Decker <
decker.christ...@gmail.com> wrote:
> Ok, I think I got the OP_
erstand how exactly will this prevent
> > normal malleability as we know it, second level malleability and replays
> > as well as how will we do the transition into mapping the txes in the
> > blockchain to normalized txids. Looking forward to read more on this
> > topic. Thank
On Tue, May 19, 2015 at 11:16 AM Tier Nolan wrote:
> On Tue, May 19, 2015 at 9:28 AM, Christian Decker <
> decker.christ...@gmail.com> wrote:
>
>> Thanks Stephen, I hadn't thought about BIP 34 and we need to address this
>> in both proposals. If we can a
Agreed, there is no need to misuse the version field as well. There is more
than enough variability you could roll in the merkle tree including and
excluding transactions, and the scriptSig of the coinbase transaction,
which also influences the merkle root.
I have a fundamental dislike of retroact
,
which could be detected if the response time deviates too much from what
has been previously measured (compare it against getdata for the block they
advertise). It's not perfect but it allows an estimate of whether it is a
chainless miner.
Regards,
Chris
--
Christian Decker
On Fri, May 25,
Being an international team I'm pretty sure we can find someone who is in a
more permissive country.
Would someone knowledgeable point us to the specific laws, so that we can
look it up in our respective jurisdiction?
Regards,
Chris
On Mon, Oct 15, 2012 at 12:02 AM, Luke-Jr wrote:
> On Sunday,
ers,
Chris
P.S.: For a complete list of transactions see http://pastebin.com/wctJU3Ln
--
Christian Decker
On Tue, Mar 12, 2013 at 7:39 PM, Gregory Maxwell wrote:
> On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell wrote:
>> On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes wrote:
>&g
e client version. I would love to see
the protocol specification becoming official part of the bitcoin
github repository, which would ideally be maintained alongside the
satoshi client to keep it up to date.
Regards,
Christian Decker
[1] https://bitcointalk.org/index.php?topic=231
--
Christian Decker
Chris
--
Christian Decker
--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-cha
rovide them on a per user basis.
--
Christian Decker
On Sun, Nov 24, 2013 at 5:26 PM, Gregory Maxwell wrote:
> On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker
> wrote:
>> Since this came up again during the discussion of the Cornell paper I
>> thought I'd dig
idea to attempt to correlate propagation speed and number of
inputs/outputs, might be interesting to see whether processing at the
nodes has an influence.
Regards,
Chris
--
Christian Decker
On Mon, Nov 25, 2013 at 9:51 AM, Michael Gronager wrote:
> Hi Christian,
>
> Cool - thanks fo
Damn, that happens if I do the overview as an afterthought. Fixed :-)
Real time (last 24 hours, last week, last month) are in the pipeline,
just need to find the time to implement access to the collector from
the webpage.
--
Christian Decker
On Wed, Nov 27, 2013 at 8:35 PM, Mike Hearn wrote
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,
Sorry for keeping this short but I'm in holiday and reading/writing on my
phone is a pain.
On Aug 24, 2011 4:12 PM, "Gavin Andresen" wrote:
>
> It seems to me the fastest path to very secure, very-hard-to-lose
> bitcoin wallets is multi-signature transactions.
>
> To organize this discussion: fir
4, 2011 at 3:05 PM, Christian Decker
> 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
Hi Steve,
before attempting to hack BitcoinJ to use NIO you might want to take a look
at BitDroid (https://github.com/cdecker/BitDroid-Network), which is my
attempt to build an easily extensible network client (no crypto stuff so
far) on top of NIO and a simple publish-subscribe architecture. I bu
Resending to mailing list as I replied directly...
On Thu, Sep 8, 2011 at 11:03 PM, Christian Decker <
decker.christ...@gmail.com> wrote:
>
>
> Will wrote:
>
> >> In fact, I think the alert system should relay (note, NOT display)
> >messages
> >> *re
Am I the only one to think putting pools at a disadvantage is actually
desirable?
Back when pools started to appear we all had huge reservations about putting
so much control into the hands of a few pool operators, but nowadays it
seems that having pool operators control a vast majority of the
comp
I'd be happy with a sort of BitTorrent like snubbing, and dropping in
extreme cases.
Sharing blacklist decisions would be dangerous. We could even extend the
protocol to include some sort of choking/unchoking in order to warn peers
that we might drop him if he continues to misbehave.
In general I
Damn, german is already contributed :-)
Well I can still do the italian one and check german then.
On Sat, Oct 8, 2011 at 11:13 PM, Gavin Andresen wrote:
> Reposting here from the forums:
>
> Good news: I'm just about to get a Bitcoin-Qt version 0.5 Release
> Candidate 1 out, with a much-improved
On Thu, Oct 20, 2011 at 7:02 AM, Alex Waters wrote:
>
>> • I propose that BIPs be wiki pages, with a social convention that the
>> Author gets final word if any editing wars break out.
>
>
> ACK
>
Does it have to be wiki pages if we're going through an editorial process
anyway, and there will be
Actually no, the same string may have to be translated in different ways
depending on the context they appear in. That sometimes happens for italian,
and I'm sure it happens in other cases too. Not sure whether this is the
cause for duplicate strings for now, but it might.
Regards,
Chris
On Sat,
Yup, +1 for Git.
On Thu, Oct 27, 2011 at 6:15 PM, Daniel F wrote:
> +1 on git. not necessarily as replacement, but at least as backup.
> could possibly use markdown and github pages, which automagically
> pushes git commits out to the website (uses markdown syntax, iirc)
>
> On Thu, Oct 27, 2011
I don't really get what you want to achieve with this. The protocol will be
slow down evolution (hopefully) soon, while the clients will continue
releasing at a similar rhythm. It took long enough to decouple the protocol
version from being bumped each client release, now doing the inverse
coupling
Just for reference: https://github.com/bitcoin/bitcoin/pull/63
The issue resulted in my most useless pull request fixing two variables :-)
I second the use of sub_version_num as a Client and Version identifier.
Regards,
Chris
On Wed, Nov 2, 2011 at 11:33 PM, Amir Taaki wrote:
> Point taken.
>
The mainline client (independently from the GUI) has been referenced to as
"Satoshi" client. I personally like the name as a homage, but I guess it
all comes down to the decision of the maintainers.
Regards,
Chris
On Thu, Nov 3, 2011 at 12:07 AM, Luke-Jr wrote:
> On Wednesday, November 02, 2011
On BitDroid I stopped updating the protocol version at 31700 and set the
string to be both Version and Client, just like BitcoinJ :-)
On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn wrote:
> BitCoinJ already sets the subver field to its name and version.
>
>
>
> --
dBuild:0.8/
>
> Thoughts:
>
> - Do we need a freely defined comments field?
>
> /BitcoinJ:0.2[iPad; U; CPU OS 3_2_1]/AndroidBuild:0.8/
> /Satoshi:314700/bitcoin-qt:0.4[Ubuntu Oneiric]/
>
> --
> *From:* Christian Decker
> *To:* Mike Hearn
Same here of course, but I'll keep the String short and fixed. I still
don't think there should be any reason for others to know my OS in order to
communicate with me :-)
On Mon, Nov 14, 2011 at 9:48 AM, Stefan Thomas wrote:
> Nice. I'll check with justmoon when I hopefully meet him at the
> co
First of all I do agree that a method for adjusting the difficulty in a
huge power drop is needed (I don't see it so much in power rises).
The current block generation with a fixed difficulty was chosen because it
it clear when to adjust and to what target difficulty it has to be
adjusted. If we w
.
The difficulty of invalidating a chain is dramatically reduced with your
time window approach, by not requiring a given difficulty, and relying on
synchronized time windows.
Regards,
Chris
On Wed, Nov 23, 2011 at 2:13 PM, Andy Parkins wrote:
> On 2011 November 23 Wednesday, Christian Dec
I think the scope of this BIP is not so well defined right now. We need a
way for merchants to translate a human readable, and more importantly
human-writeable, address into a bitcoin address. I agree with Mike that a
fixed address is not the way to go, because addresses should be used once
for a s
> But we don't have to
> define how the server will get that address.
> Some possibilities:
>
> -A static address: less anonymity, but some people may not care. Say a
> donation address.
> -The servers stores the recipient private keys and generates a new one
> for each payment.
> -The server store
A while back I had proposed a similar idea to the DHT, although my main
goal was to reduce the need for broadcasts.
My idea was to structure the network in a hypercube and use prefixes to
address different parts of the network, and use those prefixes also to find
the location where an item (transa
s
On Sat, Dec 17, 2011 at 8:28 PM, Gregory Maxwell wrote:
> On Sat, Dec 17, 2011 at 8:37 AM, Christian Decker
> wrote:
> > My idea was to structure the network in a hypercube and use prefixes to
> > address different parts of the network, and use those prefixes also to
> fi
At first the idea of using negative announces seems attractive, but
remember that a malicious node might trigger verification for every
transaction, which may lead to a DoS.
Regards,
Chris
On Thu, Dec 22, 2011 at 1:14 PM, Joel Joonatan Kaartinen <
joel.kaarti...@gmail.com> wrote:
> On Thu, 2011-
It can speed up the initial chain download. A newly created wallet will
have only new key-pairs, hence no incoming transactions (unless we have a
key collision, which is unlikely). So there is no need for a bootstrapping
node to download the chain with transactions. The chain itself can be
verified
47 matches
Mail list logo
