On Sat, Sep 03, 2011 at 08:13:14PM -0400, Gavin Andresen wrote:
Quick status update on 0.4; I probably won't have time to tackle these
properly before Tuesday:
+ sipa found what looks like a deadlock between the addr-handling and
IRC-join-handling code.
I've compiled bitcoind with Gavin's
On Sun, Sep 4, 2011 at 13:59, Pieter Wuille
pieter.wui...@cs.kuleuven.be wrote:
I've compiled bitcoind with Gavin's DEBUG_LOCKORDER, and fixed two potential
reported deadlock issues (see
https://github.com/sipa/bitcoin/commits/lockfixes).
My mistake: these are not actual potential deadlocks
On Mon, Oct 24, 2011 at 10:29:57AM +0200, Jan Vornberger wrote:
Hi there!
As part of my green address endeavor, I'm currently trying to extend the
'gettransaction' call to include an extra field inputaddresses which
should return a list of the Bitcoin addresses associated with the inputs
of
On Tue, Sep 13, 2011 at 11:06:37AM -0400, Gavin Andresen wrote:
Background:
Timejacking:
http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html
And a recent related exploit launched against the low-difficulty
alternative chains:
On Mon, Nov 07, 2011 at 10:27:57AM -0500, Luke-Jr wrote:
On Monday, November 07, 2011 10:02:43 AM Pieter Wuille wrote:
Maybe a short interval (1 minute? 10 minutes?) instead of a fixed
value could be allowed for the multiple-of-2016 blocks.
Reminder that there is *already* a short interval
Hello all,
I just submitted a pull request (#649) that enables the use of compressed
public keys in Bitcoin. As discovered by roconnor (IRC), this is possible
in such a way that old clients verify and relay them without problems.
They are supported by default by OpenSSL, and all alternative
On Mon, Nov 21, 2011 at 03:34:28AM +0100, Pieter Wuille wrote:
Hello all,
Things that need attention:
* Do all client implementations support it?
To help in testing this: this address corresponds to a compressed
public key:
http://blockexplorer.com/testnet/address
It seems base58 is actually quite terrible for producing nice human-recognizable
addresses, even though base58 is specially intended for human usage. We'll just
have to deal with it, or completely overhaul it and move to a saner encoding.
Luke's proposal is somewhat more drastic than my original
On Sun, Dec 18, 2011 at 01:15:26PM +0100, Jorge Timón wrote:
But anyway, reading some comments I feel I'm missing something about
this proposal. How can you save space by putting the whole public key
instead of just the address (a hash of the public key) with each
output?
Is this what it's
On Thu, Dec 29, 2011 at 08:08:38PM +0100, Pieter Wuille wrote:
On Thu, Dec 29, 2011 at 01:55:03AM -0500, rocon...@theorem.ca wrote:
Gavin asked me to come up with an alternative to OP_EVAL, so here is my
proposal.
OP_CODEHASH Initial Proposal
If we're again brainstorming about
Hello all,
I've just tagged v0.1.0 of my bitcoin-seeder program on github:
https://github.com/sipa/bitcoin-seeder
This is the program powering the DNS seed on seed.bitcoin.sipa.be.
It is a crawler for the bitcoin network, with integrated DNS server.
It's not more than a preview release with
Op 1 feb. 2012 10:48 schreef Andy Parkins andypark...@gmail.com het
volgende:
On 2012 January 31 Tuesday, Luke-Jr wrote:
Both BIP 16 and 17 are backward compatible enough that people can
continue
to use the old clients with each other. An upgrade is only required to
send to (or
You will also find the RPC server in libcoin blistering fast compared to
the Satoshi client. (It was actually what got me to write libcoin in the
first place...). The Satoshi client HTTP server executes all rpc commands
in its own thread, but to do so, it needs to stop the thread of the Node,
On Tue, Feb 28, 2012 at 06:41:31PM -0700, Zooko Wilcox-O'Hearn wrote:
Could you spell out the attack explicitly? Presumably there aren't a
lot of people with the malice energy to perform the attack but not
to figure it out for themselves. I, however, have the niceness
energy to think about it
On Tue, Feb 28, 2012 at 17:48, Pieter Wuille pieter.wui...@gmail.com wrote:
I've written about it in BIP30[2]. There is a patch for the reference
client, which has been tested and verified to make the attack
impossible. The change is backward compatible in the same way BIP16
On Tue, Feb 28, 2012 at 17:48, Pieter Wuille pieter.wui...@gmail.com wrote:
Hello all,
I've written about it in BIP30[2]. There is a patch for the reference
client, which has been tested and verified to make the attack
impossible. The change is backward compatible in the same way BIP16
On Sat, Mar 31, 2012 at 12:54:02PM +0200, Pieter Wuille wrote:
Something else was suggested by Jeff: what if a node accidentally connects to
itself?
As we're moving towards multiple local addresses with IPv6, the chances for
this
become larger. Finally, there are always extra risks involved
On Sat, Mar 31, 2012 at 01:16:56PM +0200, Michael Grønager wrote:
If you are interested, I could push libcoin to bitcoin (e.g. bitcoin/libcoin)
and then you could build bitcoind bitcoin-qt on libcoin.
libcoin solved most of the problems you list below. And if you worry about
the
Hello all,
Mike Hearn has submitted a pull request to add a pong message in reply to a
ping.
This warrants an upgrade of the network protocol version number, which is since
BIP14
independent from the version numbers of the reference client.
Any opinions about a numbering scheme? Currently the
On Thu, Apr 12, 2012 at 11:41:05AM -0400, Gavin Andresen wrote:
On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt sirk...@gmail.com wrote:
I would like to discuss the following bitcoin protocol improvement proposal:
Adding request/reply id in all messages (in the message header,
On Sat, Apr 14, 2012 at 04:20:50PM -0400, Jeff Garzik wrote:
Furthermore, many of these ideas -- like sending TX's directly to the
merchant -- involve far more direct payee-payer communication on the
part of the wallet client than is currently envisioned
Yes, though it's worth
On Sat, May 05, 2012 at 09:31:39AM +0100, Rebroad (sourceforge) wrote:
Hi,
Looking at:
https://github.com/bitcoin/bitcoin/commit/3e52aaf2121d597ab1ed012b65e37f9cb5f2754e#src/main.cpp-P52
It appears that 8 months ago the code was changed to DoS(100) nodes sending
on txs that use
- Forwarded message from Pieter Wuille pieter.wui...@gmail.com -
Date: Sun, 10 Jun 2012 01:10:54 +0200
From: Pieter Wuille pieter.wui...@gmail.com
To: bitcoin-development@lists.sourceforge.net
Subject: getmemorypool
User-Agent: Mutt/1.5.20 (2009-06-14)
Hello everyone,
Luke's
On Mon, Jun 11, 2012 at 08:10:22PM +0200, thoma...@gmx.de wrote:
discussion back here. The executive summary: Pieter and I feel like
BIP 22 is overly complicated, and would like it to be simpler. I'd
especially like to hear what people think will be the will be used by
lots of pool
On Fri, Jun 15, 2012 at 04:58:55PM -0400, grarpamp wrote:
When bitcoind exits cleanly, it does not seem safe for the blockchain
to clean up the following hierarchy with rm -r ?
Use -detachdb if you want to detach the blockchain database files from the
database environment at exit. This was
Hello all,
while OpenSSL's silent support for compressed public keys allowed us to
enable them in a fully backward-compatible way, it seems OpenSSL supports yet
another (and non-standard, and apparently useless) encoding for public keys.
As these are supported by (almost all?) fully validating
Hello everyone,
a few days ago we merged Tor hidden service support in mainline. This means
that it's now possible to run a hidden service bitcoin node, and connect to
other bitcoin hidden services (via a Tor proxy) when running git HEAD. See
doc/Tor.txt for more information. This is expected to
Hello all,
I've implemented a new block/transaction validation system for the
reference client, called ultraprune.
Traditionally, pruning for bitcoin is considered to be the ability to
delete full transactions from storage once all their outputs are spent,
and they are buried deeply enough in
And now to the list...
On Jul 27, 2012 6:21 AM, grarpamp grarp...@gmail.com wrote:
Update: this class of machine just became useless for bitcoin.
When blk0002.dat was created to store more blocks, all forward
progress processing blocks turned into losing ground by 20 or so
a day. Guessing
On Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote:
Consensus was we should do a BIP for all P2P changes, so here it is...
feedback requested.
https://en.bitcoin.it/wiki/BIP_0035
I like the idea of being able to query the memory pool of a node; the
implementation is
On Thu, Sep 13, 2012 at 06:49:49PM +0100, Matthew Mitchell wrote:
A merkle tree root is found by hashing the two children together and those
children are found the same way until you get to the greatest level down the
tree. This means you can validate children as being correct as long as they
Hello all,
as some may be aware, OpenSSL accepts several encodings for the same
public key or the same signature. It even accepts encodings that fail
to conform to the SEC and DER specification by which they are defined.
As it perfectly capable of parsing every standard-compliant encoding,
this
On Wed, Oct 24, 2012 at 06:35:08PM +0200, Mike Hearn wrote:
* what does each hash and key in the output script mean exactly? what
about the output script in its entirety?
It's an informal way to say data elements. If you insert a key then it
matches both single and multi sig outputs
On Fri, Oct 26, 2012 at 04:01:58PM +0200, Mike Hearn wrote:
I don't feel I understand the effort required to do some kind of
partial tree encoding. Having a kind of custom compression whereby
branches are represented as varint indexes into a dictionary, I can
feel how much work that involves
On Tue, Nov 6, 2012 at 7:47 PM, Gavin Andresen gavinandre...@gmail.com wrote:
Thursdays at 18:00 UTC (6PM Europe/1PM east US/10AM west US) seem to
be a good time for the core dev team to meet on the #bitcoin-dev
freenode IRC channel to chat.
Ok, good.
--
Pieter
On Thu, Nov 08, 2012 at 10:19:05AM +0100, Mike Hearn wrote:
Comments:
BIP process: are we happy with how it is working? What can we do to improve
it?
Needing some kind of process to allocate a number is over the top. I
skipped this for the bloom filtering BIP. We should take off the
On Wed, Nov 21, 2012 at 01:38:37PM -0500, Matt Corallo wrote:
On Wed, 2012-11-21 at 16:15 +0100, Pieter Wuille wrote:
On Wed, Oct 24, 2012 at 05:56:07PM +0200, Mike Hearn wrote:
I've written a draft BIP describing the bloom filtering protocol
extension developed by myself and Matt
On Mon, Dec 3, 2012 at 12:19 PM, Michael Gronager grona...@ceptacle.comwrote:
(Also posted on the forum:
https://bitcointalk.org/index.php?topic=128900.0)
The amount of dust in the block chain is getting large and it is growing
all the time. Currently 11% of unspent tx outputs (UTXO) are of
On Mon, Dec 3, 2012 at 1:24 PM, Michael Gronager grona...@ceptacle.comwrote:
If this were a proposal at the time Bitcoin was created, I would
definitely be in favor, but I feel we can't just change such a policy right
now - it's not what people signed up for when they started using the
On Mon, Dec 3, 2012 at 2:49 PM, Amir Taaki zgen...@yahoo.com wrote:
Can this be amended? I think it makes much more sense to allow people to
input labels not numbers at this level.
General category names for different accounts is much more human than
numbers, and you can still use
On Sun, Jan 27, 2013 at 05:27:52AM -0500, Peter Todd wrote:
seed.txt? You mean the dumpfile produced by bitcoin-seeder? That has
uptime info, although only a months worth if I understand it correctly.
It has information about all non-banned IPs that were ever connected to
succesfully. The
Hello everyone,
Í've just seen many reports of 0.7 nodes getting stuck around block 225430,
due to running out of lock entries in the BDB database. 0.8 nodes do not
seem to have a problem.
In any case, if you do not have this block:
2013-03-12 00:00:10 SetBestChain: new
On Wed, Mar 13, 2013 at 07:01:02PM +0100, Michael Gronager wrote:
Please note that it was not 0.8 that had issues, but 0.7(and downwards).
I really think changing features in 0.8 aiming for a fluffy limit to avoid
lock object errors on 0.7 is the wrong way to go, and it will never cover for
On Wed, Mar 13, 2013 at 11:27:13AM -0700, Mark Friedenbach wrote:
I know there's people here who will jump in saying that the bitcoin
protocol is the behavior of the Satoshi client, period. But which Satoshi
client? 0.7 or 0.8?
The protocol is whatever the network enforces - and that is some
(cross-post from bitcointalk.org)
Hello all,
as some may know, Bitcoin uses DER-encoded signatures in its transactions.
However, OpenSSL (which is used to verify them) accepts more than just the
strict DER specification (it allows negative numbers, extra zero padding,
extra bytes at the end, and
On Sun, Apr 07, 2013 at 06:01:13PM +0200, Mike Hearn wrote:
It'd help to know how the signatures are invalid.
The majority (~90%) is negative R or S values (which are just interpreted as
unsigned by OpenSSL, but if the top byte has its highest bit set, it must be
preceeded by a 0x00 accordinging
Hello all,
I think it is time to move forward with pruning nodes, i.e. nodes that
fully validate and relay blocks and transactions, but which do not keep
(all) historic blocks around, and thus cannot be queried for these.
The biggest roadblock is making sure new and old nodes that start up are
On Sun, Apr 28, 2013 at 6:29 PM, Mike Hearn m...@plan99.net wrote:
I'd imagined that nodes would be able to pick their own ranges to keep
rather than have fixed chosen intervals. Everything or two weeks is
rather restrictive - presumably node operators are constrained by physical
disk space,
(generic comment on the discussion that spawned off: ideas about how to
allow additional protocols for block exchange are certainly interesting,
and in the long term we should certainly consider that. For now I'd like to
keep this about the more immediate way forward with making the P2P protocol
On Mon, May 06, 2013 at 10:19:35AM +0200, Mike Hearn wrote:
You are welcome to optimise P2P addr broadcasts or develop better bootstrap
mechanisms.
I think John's actually has a point here. If we're judging the quality of a
protocol change by how compatible it is with DNS seeding, then we're
On Tue, May 07, 2013 at 02:16:41PM +0200, Adam Back wrote:
Hi
Three minor security/other issues:
1. please a way to unlock the wallet without displaying wallet password in
console screen (console unlock wallet, to import priv key); or
I think the general solution here is providing a
On Wed, May 08, 2013 at 09:08:34PM -0400, Jeff Garzik wrote:
On Wed, May 8, 2013 at 9:00 PM, John Dillon
john.dillon...@googlemail.com wrote:
Perhaps Satoshi did this delibrately, knowing that at some point a hard-fork
would be a good idea, so that we all would have a good excuse to do one?
On Sun, May 12, 2013 at 8:35 AM, Jay F j...@outlook.com wrote:
On 5/10/2013 8:39 AM, Gavin Andresen wrote:
Bitcoin-Qt version 0.8.2 release candidate 1 is now available from:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.2/test/
Testnet glitch, something broke...
I
On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus rob...@robbak.com wrote:
So the decision has been made to make 0-conf double spends trivial, so no
one will ever trust 0-confs. If a later transaction appears with a larger
fee, it will be considered to be the valid one, and the first one
On Mon, May 27, 2013 at 03:10:04PM +0200, Michael Gronager wrote:
Commenting on my own mail...
Rereading the BIP, it occurs to me that the private derivation is
actually intentional. So:
(m/i/j/k)*G = (M/i/j/k), but (m/i'/j/k)*G (M/i/j/k) (M/i'/j/k = ERROR)
But: ((m/i')*G)/j/k =
On Mon, Jun 10, 2013 at 10:14 AM, Melvin Carvalho
melvincarva...@gmail.com wrote:
However, Bitcoin's fundamental philosophy was one CPU one vote.
This is perhaps the largest misconception that keeps being repeated.
Bitcoin is not a democracy; it is a zero-trust system. The rules are
set in
On Tue, Jun 11, 2013 at 3:11 PM, Melvin Carvalho
melvincarva...@gmail.com wrote:
There was some confusion on IRC as to whether bitcoin addresses are opaque
or not.
https://en.bitcoin.it/wiki/Address
For the sake of argument let's say that opaque means that you can tell
nothing about the
On Mon, Jun 17, 2013 at 11:48:22PM -0400, Alan Reiner wrote:
_*Goal*_: An alternative address format made possible by BIP 32, which
allows one to specify a Wallet ID and One-time payment code, instead
of the standard one-use Base58-Hash160 addresses. This allows parties
with a persistent
On Thu, Jun 20, 2013 at 09:36:40AM +0200, Mike Hearn wrote:
Sure but why not do that when there's an actual new field to add? Does
anyone have a proposal for a feature that needs a new version field at the
moment? There's no point changing the protocol now unless there's actually
a new field
m...@plan99.net
*To:* Pieter Wuille pieter.wui...@gmail.com
*Cc:* Bitcoin Dev bitcoin-development@lists.sourceforge.net; Tamas
Blummer ta...@bitsofproof.com
*Sent:* Thursday, June 20, 2013 11:17 AM
*Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version
There's no problem
On Wed, Jun 26, 2013 at 01:13:25AM +0200, Jesus Cea wrote:
splash banner shows 0.8.3-BETA.
Just like every release ever, and probably until we reach 1.0.
--
Pieter
--
This SF.net email is sponsored by Windows:
Build
On Sun, Jul 14, 2013 at 07:05:26PM +, John Dillon wrote:
Long-term we should be using P2SH with an inner OP_CHECKSIG for most addresses
as it's a 1 byte savings. Change addresses can have this done first, although
bitcoinj support will help so that satoshidice and similar sites can pay to
On Sun, Jul 14, 2013 at 07:33:06PM +, Luke-Jr wrote:
The issue is that unless there is a cost to mining a *invalid* block
the merge mined coin has little protection from miners who mine invalid
blocks, either maliciously or through negligence. If the coin isn't worth
much, either
On Tue, Jul 16, 2013 at 12:59:56PM +0200, Mike Hearn wrote:
I think that's a great approach. Here is the patch Satoshi sent me back in
2010. All the code has changed since but it can be a source of inspiration.
From Satoshi:
*The simplified payment verification in the paper imagined you
Hello,
I should have brought up this suggestion before, as there seems to be relevant
other work.
I'd like to propose encoding keys data (whatever type) with a birth timestamp
as:
* serialized key@unix timestamp in decimal
The reason for not incorporating this inside the key serialization
On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote:
One additional URL makes this pretty much perfect:
GET /rest/block-with-tx/TX-HASH
Construction of the transaction-hash-to-block database is something the full
client's have to do anyway, so this query is no harder than the
On Tue, Jul 23, 2013 at 11:52 AM, Andy Parkins andypark...@gmail.com wrote:
There is actually no such index being maintained by default, and doing so
is an unnecessary burden IMHO (you need to enable -txindex since 0.8 to
get this). Of course, if enabled, it can be exposed.
Wow. I'm
On Tue, Jul 23, 2013 at 12:00 PM, Andy Parkins andypark...@gmail.com wrote:
The REST API has nothing to do with SPV clients; it's similar to the RPC
interface and won't be exposed to the network as a whole.
Yes; I know that. I'm saying that it would make it easier for SPV (and other
On Tue, Jul 23, 2013 at 12:17 PM, Andreas Schildbach
andr...@schildbach.de wrote:
Sweeping paper wallets is a common feature request. People switch to
centralized services just for getting that.
That means they value convenience more than the trust-freeness of a
decentralized solution. The only
On Tue, Jul 23, 2013 at 12:29 PM, Andreas Schildbach
andr...@schildbach.de wrote:
Yes, I understand that. For this reason, I would vote for adding the
usual HTTP authentication/SSL stuff to the REST API. That way, SPV users
can decide to run their own instance of the API (providing the needed
On Tue, Jul 23, 2013 at 10:01:55PM +0200, Mike Hearn wrote:
The trigger for this is the discovery that Debian bitcoind's got split out
of the consensus some time in April, for reasons that nobody yet figured
out but is presumably related to a patch (eg it uses system leveldb).
Just to make
I see payment URIs rather as a replacement for bitcoin: URI rather
than an extension. It solves everything they did in a much cleaner
way, Given that bitcoin: have gotten some traction, we probably want
to reuse the moniker, but replace the rest entirely. In other words,
if a request is specified,
On Thu, Aug 15, 2013 at 10:09:48AM +0200, Mike Hearn wrote:
Sounds awesome!
Pieter told me at lunch that headers first cut sync time to 45 minutes for
him, which is another amazing improvement from the master of optimisations.
Just to make sure nobody expects a magic bullet: this was on a
On Thu, Aug 15, 2013 at 12:49 PM, Wladimir laa...@gmail.com wrote:
Fully agreed about payment protocol, autotools and Qt5 build.
I'm still not very excited about coin control (and last time I looked at the
code, it has an issue that it introduced statefulness into the wallet model
- a bane
On Mon, Aug 19, 2013 at 10:09 PM, Frank F frank...@gmail.com wrote:
I strongly object to removing the only mechanism that allows anyone to say
that bitcoin is p2p, in the truest sense of the word. Moves like this that
favor only the pool operators and private mining interests are signs that
This is probably too late in the discussion, and I certainly don't
want to derail any standard being formed. But if it is controversial,
I want to offer my own suggestion.
This is a proposal I wrote a year ago, but never spent enough work to
push it as a standard:
Let's first try to agree on what we are solving.
It seems that Thomas wants - in addition to the cryptographic data -
to encode the tree structure, or at least version information about
what features are used in it, inside the seed.
I'm not sure whether we're ready to standardize on something
On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd p...@petertodd.org wrote:
The correct, and rational, approach for a miner is to always mine to
extend the block that the majority of hashing power is trying to extend.
The current relay rules don't give you that information at all, but they
can if we
Correcting myself:
On Thu, Nov 7, 2013 at 4:00 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
I believe that C. Decker's paper used measurements for propagation
delays for blocks 18-19, which happened between may and juli
2012. The latest bitcoind/bitcoin-qt release at the time
On Mon, Dec 16, 2013 at 11:46 AM, Jim jim...@fastmail.co.uk wrote:
For the HD version of MultiBit we are removing the import
of individual private keys entirely and only supporting HD
addresses, primarily for safety reasons.
Will that also mean no longer reusing (change) addresses?
--
Pieter
Hello all,
based on some feedback, I've created a pull request with a rewritten
version of BIP 32, hopefully making it more readable:
* Don't reuse the terminology 'public' vs 'private' for the alternate
derivation scheme which doesn't allow computing child public keys from
parent public keys,
On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene kgree...@gmail.com wrote:
+1 for an error field.
Agree, I think we need a way for client applications to interpret the response.
Should the wallet broadcast the transaction to the bitcoin network when it
receives an ACK, or always assume that the
On Tue, Jan 28, 2014 at 1:53 PM, Gavin Andresen gavinandre...@gmail.com wrote:
On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote:
Yeah, that's the interpretation I think we should go with for now. There
was a reason why this isn't specified and I forgot what it was - some
On Thu, Jan 30, 2014 at 12:15 PM, Chuck chuck+bitcoin...@borboggle.com wrote:
Hi Mike. Thanks for replying.
On 1/30/2014 5:49 PM, Mike Hearn wrote:
Both Bitcoin Core and bitcoinj are about to ship with the protocol
as-is, so any changes from this point on have to be backwards compatible.
On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn m...@plan99.net wrote:
With the way it works in bitcoinj, the tx is only committed to the wallet if
the server accepts the Payment message and ACKs it. So the tx would not be
retried if there's a failure submitting or some kind of internal server
On Thu, Jan 30, 2014 at 4:06 PM, Gavin Andresen gavinandre...@gmail.com wrote:
On Thu, Jan 30, 2014 at 9:51 AM, Jeff Garzik jgar...@bitpay.com wrote:
Is this truly the intent? That the merchant/processor takes full
responsibility for getting the TX confirmed?
The intent is to give the
On Thu, Jan 30, 2014 at 3:51 PM, Jeff Garzik jgar...@bitpay.com wrote:
On Mon, Jan 27, 2014 at 5:17 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene kgree...@gmail.com wrote:
Should the wallet broadcast the transaction to the bitcoin network
Hello all,
it was something I planned to do since a long time, but with the
recent related issues popping up, I finally got around to writing a
BIP about how we can get rid of transaction malleability over time.
The proposed document is here: https://gist.github.com/sipa/8907691
I expect most
Hi all,
I was a bit surprised to see MtGox's announcement. The malleability of
transactions was known for years already (see for example the wiki
article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it,
or mails on this list from 2012 and 2013). I don't consider it a very
big
It's also not necessary for wallet software - it's really just for
human consumption.
A wallet can easily detect inputs being respent in another
transaction. You don't need a static hash for that (which wouldn't
need with all hash types, non-malleability double spends, ...).
On Wed, Feb 12, 2014
On Wed, Feb 12, 2014 at 5:56 PM, Pavol Rusnak st...@gk2.sk wrote:
On 02/10/2014 12:33 AM, Pieter Wuille wrote:
The proposed document is here: https://gist.github.com/sipa/8907691
If we are bumping nVersion, how about dropping DER encoding completely
and using just 64 bytes directly
On Wed, Feb 19, 2014 at 3:11 PM, Michael Gronager grona...@mac.com wrote:
Why introduce a new transaction version for this purpose ? Wouldn't it be
more elegant to simply let:
1. the next bitcoin version prettify all relayed transactions as
deterministic transactions fulfilling the scheme
On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager grona...@mac.com wrote:
I think that we could guarantee fewer incidents by making version 1
transactions unmalleable and then optionally introduce a version 3 that
supported the malleability feature. That way most existing problematic
I hereby request a BIP number.
On Thu, Feb 20, 2014 at 3:58 PM, Gavin Andresen gavinandre...@gmail.com wrote:
Great, I'm hearing rough consensus to proceed with Pieter's plan.
RE: far from confident on malleability routes: I'm reasonably confident
that we can squash malleability for
On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik jgar...@bitpay.com wrote:
I do think
regular transactions should have the ability to include some metadata.
and
2) Endorsement of chain data storage.
Nothing could be further from the truth.
These two statements are in direct contradiction with
On Wed, Mar 5, 2014 at 2:18 PM, Jean-Paul Kogelman
jeanpaulkogel...@me.com wrote:
As far as I know, judging from the implementation, there is hardly any
effort to try to prevent timing attacks.
Is it safe to assume that this is also true for your secp256k1 implementation?
I've done some
Just chiming in...
I'm not opposed to a more generic default key tree, but we need to
standardize this soon I believe. There are already existing code bases
that implement BIP32 wallets (and more are popping up...); just using
a separate one will result in lots of incompibilities.
That said, I'm
On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak st...@gk2.sk wrote:
Cointype in path is for separation purposes, not for identification.
I don't understand what that gains you.
--
Pieter
--
Hi all,
I understand this is a controversial proposal, but bear with me please.
I believe we cannot accept the current subsidy schedule anymore, so I
wrote a small draft BIP with a proposal to turn Bitcoin into a
limited-supply currency. Dogecoin has already shown how easy such
changes are, so I
On Tue, Apr 1, 2014 at 10:00 PM, Peter Todd p...@petertodd.org wrote:
On Tue, Apr 01, 2014 at 09:00:07PM +0200, Pieter Wuille wrote:
The text can be found here: https://gist.github.com/sipa/9920696
What's interesting about this bug is we could also fix the problem - the
economic shock
1 - 100 of 196 matches
Mail list logo