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
;)
On 5/13/2015 3:48 PM, Christian Decker wrote:
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
On Tue, May 19, 2015 at 11:16 AM Tier Nolan tier.no...@gmail.com 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 avoid it I'd like not to have
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
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
On Wed, May 13, 2015 at 8:40 PM Pieter Wuille pieter.wui...@gmail.com
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 transaction hash does
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
to the private key.
On May 13, 2015 5:50 AM, Christian Decker decker.christ...@gmail.com
wrote:
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
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
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 bitcoin-l...@bluematt.me
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 laa...@gmail.com wrote:
On Fri, Aug 8, 2014 at 12:15 PM, Wladimir laa...@gmail.com wrote:
On Fri, Aug 8, 2014 at 12
+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
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 laa...@gmail.com wrote:
We've established a few basic rules for the DNS seeds as used in the
Bitcoin Core software. See below.
If you run
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 laa...@gmail.com wrote:
On Sun, Mar 2, 2014
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 m
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 grona...@ceptacle.com wrote:
Hi Christian,
Cool
--
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-changing
user basis.
--
Christian Decker
On Sun, Nov 24, 2013 at 5:26 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker
decker.christ...@gmail.com wrote:
Since this came up again during the discussion of the Cornell paper I
thought I'd dig up my measurement
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
On Thu, Oct 24, 2013 at 9
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 gmaxw...@gmail.com wrote:
On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes pe
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 l...@dashjr.org
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
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
, Christian Decker wrote:
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 were to use synchronized time windows and select the
hardest block it gets incredibly complicated
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 m...@justmoon.de wrote:
Nice. I'll check with justmoon when I hopefully meet
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 m...@plan99.net wrote:
BitCoinJ already sets the subver field to its name and version.
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 decker.christ...@gmail.com
*To:* Mike Hearn m...@plan99.net
*Cc:* Amir Taaki zgen...@yahoo.com;
bitcoin-development
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
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 zgen...@yahoo.com wrote:
On Thu, Oct 20, 2011 at 7:02 AM, Alex Waters ampe...@gmail.com 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
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 gavinandre...@gmail.comwrote:
Reposting here from the forums:
Good news: I'm just about to get a Bitcoin-Qt version 0.5 Release
Candidate 1 out,
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 w...@phase.net wrote:
In fact, I think the alert system should relay (note, NOT display)
messages
*regardless of the key used*, so it isn't yet
32 matches
Mail list logo
