As I see the BIP it is basically stressing that ver 1 transactions are
malleable.
It then addresses the need for unmalleable transactions for e.g. spending
unconfirmed outputs in a deterministic way (i.e. no 3rd party can sabotage) -
this transaction type is defined as ver 3.
A lot of clients
We've done forking changes before much faster than a year and that was with
less experience. If we want, we can get this done within months.
On 20 Feb 2014 16:30, Michael Gronager grona...@mac.com wrote:
As I see the BIP it is basically stressing that ver 1 transactions are
malleable.
It then
On Thu, Feb 20, 2014 at 6:08 AM, Mike Hearn m...@plan99.net wrote:
We've done forking changes before much faster than a year and that was with
less experience. If we want, we can get this done within months.
You mean P2SH... which your implementation has only picked up support
for in the last
I think we should get Pieter's proposal done and implemented quickly. I
agree with Mike, it doesn't have to take a long time for the core network
to fully support this.
Getting wallets to start generating transaction.version=3 might take years,
but that is OK.
--
--
Gavin Andresen
On Thu, Feb 20, 2014 at 6:29 AM, Gavin Andresen gavinandre...@gmail.com wrote:
I think we should get Pieter's proposal done and implemented quickly. I
agree with Mike, it doesn't have to take a long time for the core network to
fully support this.
Getting wallets to start generating
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 IsStandard, SIGHASH_ALL transactions. A
proper proof of DSA signature un-malleability (or an lower bound for how
much work
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 Thu, Feb 20, 2014 at 7:11 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
I hereby request a BIP number.
62 assigned.
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to
A quick update on the state of transaction malleability work in
Bitcoind/Bitcoin-Qt (aka Bitcoin Core). This is not about longer-term
malleability issues, just the very short-term work being done (or already
done) to the reference implementation.
First, the problems:
We've had a longstanding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What follows is a proposed BIP for human-friendly base-32
serialization with error correction encoding. A formatted version is
viewable as part of a gist with related code:
https://gist.github.com/maaku/8996338#file-bip-ecc32-mediawiki
An
No, I was thinking of the height in coinbase change. At any rate, p2sh was
supported by the consensus code in bitcoinj for a long time already, since
it was first written.
Support for sending to such addresses in the wallet appeared once an app
that wanted that support also appeared, which seems
[Meta: Bitcoin Core is the newfangled branding of bitcoind /
Bitcoin-Qt reference implementation, in case you wondering.]
Several sites, including BitPay, use bitcoind outside the standard
role of wallet software. bitcoind can be used purely for payment
network access and management. I call
Bear in mind a separate process doesn't buy you anything without a sandbox,
and those are expensive (in terms of complexity).
On 21 Feb 2014 11:40, Jeff Garzik jgar...@bitpay.com wrote:
[Meta: Bitcoin Core is the newfangled branding of bitcoind /
Bitcoin-Qt reference implementation, in case you
On Thu, Feb 20, 2014 at 10:07 PM, Mike Hearn m...@plan99.net wrote:
No, I was thinking of the height in coinbase change. At any rate, p2sh was
supported by the consensus code in bitcoinj for a long time already, since
it was first written.
Support for sending to such addresses in the wallet
On Fri, Feb 21, 2014 at 7:27 AM, Mike Hearn m...@plan99.net wrote:
Bear in mind a separate process doesn't buy you anything without a
sandbox, and those are expensive (in terms of complexity).
Sandboxing in user space is complex, agreed,
The most straightforward way would be to run the
RE doesn't buy you anything Today, when unlocked, plaintext
private keys reside in the same address space as the blockchain engine
(BCE). Process separation increases the difficulty of accessing key
data from the BCE, even presuming a normal, no-chroot, same-uid,
parent-child process
Running the network part of the core as a system service might make sense for
server implementations, but it’s a pain in the rear for most users.
That said, I think segregating the two processes is a great idea. Let’s just
try to avoid some complicated scheme that involves necessarily running
On Fri, Feb 21, 2014 at 7:50 AM, William Yager will.ya...@gmail.com wrote:
Running the network part of the core as a system service might make sense
for server implementations, but it’s a pain in the rear for most users.
Come on, making it a possibility doesn't affect other kinds of use cases
18 matches
Mail list logo
