On Fri, Feb 21, 2014 at 7:50 AM, William Yager 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 in
any way. Are y
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 relations
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 t
On Fri, Feb 21, 2014 at 7:27 AM, Mike Hearn 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 blockchain daemon a
On Thu, Feb 20, 2014 at 10:07 PM, Mike Hearn 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 appeared onc
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" wrote:
> [Meta: "Bitcoin Core" is the newfangled branding of bitcoind /
> Bitcoin-Qt reference implementation, in case you wondering.]
[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 th
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 O
-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 implementat
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 TODO
On Thu, Feb 20, 2014 at 7:11 AM, Pieter Wuille wrote:
> I hereby request a BIP number.
62 assigned.
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pit
I hereby request a BIP number.
On Thu, Feb 20, 2014 at 3:58 PM, Gavin Andresen 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 IsStandard, SIGHASH_ALL tra
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
On Thu, Feb 20, 2014 at 6:29 AM, Gavin Andresen 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 transaction.version=3 might
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:08 AM, Mike Hearn 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 month or so?
-
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" wrote:
> As I see the BIP it is basically stressing that ver 1 transactions are
> malleable.
>
> It then addresses
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
18 matches
Mail list logo
