It recently occured to me that we can use the public nature of the block
chain to create trusted identities, for a specific form of trust.
Lets suppose Alice has some bitcoins held at bitcoin address A. She
wants to establish trust in the identity associated with the ECC
keypair associated with
On Thu, Apr 26, 2012 at 10:11:51AM -0700, Peter Vessenes wrote:
These are interesting thoughts, karma for bitcoins essentially.
I would like CoinLab to publish a 'cost of subverting 1-n transactions with
90% probability' metric soon, and I think it would help everyone to
understand what that
#220 0x75d021a6 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib/libQtGui.so.4
(gdb)
#221 0x75d086fb in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/libQtGui.so.4
(gdb)
#222 0x7582f06c in QCoreApplication::notifyInternal(QObject*,
On Sun, Jun 17, 2012 at 02:39:28PM -0400, Alan Reiner wrote:
All,
With the flurry of discussion about blockchain compression, I
thought it was time to put forward my final, most-advanced idea,
into a single, well-thought-out, *illustrated*, forum post.
Please check it out:
On Mon, Jun 18, 2012 at 12:46:47AM +0200, Alberto Torres wrote:
Hi,
I did describe a very similar thing back in January (also illustrated,
and, if I'm not mistaken, more simple and efficient to recalculate),
and I wanted to do a prototype, but I have been very busy with other
projects since
As the title says.
Basically on testnet we should give people the chance to test how their
code handles attempts to spend the genesis block coinbase, as well as
other tx's made to the genesis block address. After all, potentially
Satoshi is still out there, still has that key, and still may cause
I setup a testnet DNS seed using Pieter Wuille's bitcoin-seeder, with
some simple modifications for testnet. It's at
testnet-seed.bitcoin.petertodd.org I also created
static-testnet-seed.bitcoin.petertodd.org which currently has a single A
record pointing to a testnet node I'm running to bootstrap
On Fri, Jan 25, 2013 at 09:23:28PM -0500, Jeff Garzik wrote:
On Thu, Jan 24, 2013 at 2:01 AM, Peter Todd p...@petertodd.org wrote:
Everything is running on a dedicated Amazon EC2 micro instance. Just
IPv4 is supported right now as EC2 doesn't support IPv6; even tunnels
are broken. I also
On Fri, Feb 08, 2013 at 11:03:54AM +0100, Timo Hanke wrote:
First, we have drafted a quite general specification for bitcoin certificates
(protobuf messages) that allow for a variety of payment protocols (e.g.
static as well as customer-side-generated payment addresses).
This part has surely
On Sat, Feb 09, 2013 at 03:33:25PM +0100, Timo Hanke wrote:
Why don't you use namecoin or another alt-chain for this?
Because namcoin tries to solve a different problem, DNS, whereas I want
to establish an identity for a payment protocol. Your incoming payments
will land on addresses that
In my fidelity bond protocol (1) I'm proposing the use of two possible
new features:
The first is the use of OP_RETURN at the end of a scriptPubKey to
designate that the txout can be immediately pruned as it is obviously
unspendable. My use-case is the publish part of the two-step
On Tue, Feb 12, 2013 at 12:42:37PM -0500, Gavin Andresen wrote:
On Tue, Feb 12, 2013 at 10:11 AM, Peter Todd p...@petertodd.org wrote:
Again, thoughts?
First: I really like the fidelity bond concept, and want to see it happen.
RE: OP_RETURN : I've got a knee-jerk opposition
On Wed, Feb 13, 2013 at 09:44:11PM -0500, Stephen Pair wrote:
One of the beauties of bitcoin is that the miners have a very strong
incentive to distribute as widely and as quickly as possible the blocks
they find...they also have a very strong incentive to hear about the blocks
that others
On Wed, Feb 13, 2013 at 05:02:39PM -0800, Gregory Maxwell wrote:
It's the year 2043— the Y2038 problem is behind us and everyone is
beginning to forget how terrible it turned out to be— By some amazing
chance Bitcoin still exists and is widely used. Off-chain system like
fidelity bonded
On Thu, Feb 14, 2013 at 07:59:04AM -0500, Stephen Pair wrote:
The idea that miners have a strong incentive to distribute blocks as
widely and as quickly as possible is a serious misconception. The
optimal situation for a miner is if they can guarantee their blocks
would reach just over 50%
Lets suppose we take away everything but the transaction/scripting
system from Bitcoin. What is left is basically a way for to prove that a
set of pubkeys authorized the movement of coins from one place to
another. Of course, such a system is flawed as a currency because of the
double spend
So with UTXO merkle-sum-fee-trees and fraud notices(1) we can
effectively audit the blocks produced by miners and provide a way for
SPV nodes to reject invalid blocks without requiring the whole
blockchain data.
Next step: How do we prevent censorship? Can we at all?
Basically while UTXO-style
On Thu, Mar 07, 2013 at 06:00:18AM -0500, Peter Todd wrote:
It's also notably that auditable off-chain transaction systems are
vulnerable. All of the trustworthy ones that don't rely on trusted
hardware require at least some of their on-chain transactions to be
publicly known, specifically so
On Thu, Mar 07, 2013 at 06:42:32PM +0100, Mike Hearn wrote:
To summarize your post - it's another go at arguing for strongly
limited block sizes, this time on the grounds that large blocks make
it easier for $AUTHORITY to censor transactions? Is that right?
Yes.
Now, can we solve this problem
On Thu, Mar 07, 2013 at 02:31:10PM -0700, Daniel Lidstrom wrote:
My views on censorship resistance in the face of scaling:
1) I expect if I'm not careful about preserving my privacy with the way I
use Bitcoin, then I will always run the risk of being censored by miners.
This means connecting
We can allow for transaction replacement for the purpose of adding fees
to existing transactions safely, and while not increasing the risk of
double-spends by taking advantage of the stubbed out replacement code.
Specifically the replacement code allows for the replacement of a
transaction if a
On Tue, Mar 12, 2013 at 10:10:15AM +0100, Mike Hearn wrote:
There are no bounds on the memory pool size. If too many transactions
enter the pool then nodes will start to die with OOM failures.
Therefore it is possible that we have a very limited amount of time
until nodes start dying en-masse.
On Tue, Mar 12, 2013 at 11:10:47AM +0100, Mike Hearn wrote:
However, most nodes are not running in such a loop today. Probably
almost no nodes are.
I suppose you could consider mass node death to be more benign than a
hard fork, but both are pretty damn serious and warrant immediate
action.
On Tue, Mar 12, 2013 at 11:13:09AM +0100, Michael Gronager wrote:
Following that, increase the soft and hard limit to 1 and eg 10MB, but miners
should be the last to upgrade.
We just saw a hard-fork happen because we ran into previously unknown
scaling issues with the current codebase. Why
On Wed, Mar 13, 2013 at 12:56:29PM +, Luke-Jr wrote:
Here's a simple proposal to start discussion from...
BEFORE block 262144:
- Never make a block that, combined with the previous 4 blocks, results in
over 4500 transaction modifications.
- Reject any block that includes more than 4500
On Wed, Mar 13, 2013 at 03:26:14PM +, Luke-Jr wrote:
On Wednesday, March 13, 2013 3:18:36 PM Gregory Maxwell wrote:
On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd p...@petertodd.org wrote:
If we're going to consider doing this, at minimum we need to also
I beg people to not derail
On Wed, Mar 13, 2013 at 01:01:43PM -0400, Gavin Andresen wrote:
The very statement that we're willing to increase the blocksize as our
solution to increased transaction volume rather go down the path of
off-chain transactions is incredibly controversial.
I really don't understand this
Hardware mining rigs do not need updating - they all are designed to connect
directly to a pool and it is the pool that makes all block related decisions.
All the miner, or as I prefer to call them hasher, sees is an 80 byte block
header and possibly with stratum and getblocktemplate enough
On Fri, Apr 05, 2013 at 12:13:23PM +0200, Melvin Carvalho wrote:
Totally see the logic of this, and it makes sense. But I dont think the
only risk is in terms of double spend, but rather
1) vandalize the block chain which may be difficult to unwind?
Vandalize the chain how? By delibrately
On Tue, Apr 09, 2013 at 12:42:12PM +0200, Mike Hearn wrote:
hack by changing the protocol. Nodes can serve up blocks encrypted under a
random key. You only get the key when you finish the download. A blacklist
NAK
Makes bringing up a new node dependent on other nodes having consistent
uptimes,
On Tue, Apr 09, 2013 at 04:53:47PM +0200, Mike Hearn wrote:
there's an obvious backwards compatibility problem there. It should
probably wait until the payment protocol work is done, so the major user of
micropayments-as-messages can migrate off them.
As I pointed out in my initial post on
On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote:
Note how we can already do this: P2SH uses Hash160, which is
RIPE160(SHA256(d)) We still need a new P2SH *address* type, that
provides the full 256 bits, but no-one uses P2SH addresses yet anyway.
This will restrict data stuffing
On Tue, Apr 09, 2013 at 11:03:01PM -0400, Peter Todd wrote:
On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote:
Note how we can already do this: P2SH uses Hash160, which is
RIPE160(SHA256(d)) We still need a new P2SH *address* type, that
provides the full 256 bits, but no-one
On Tue, Apr 09, 2013 at 11:03:01PM -0400, Peter Todd wrote:
On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote:
Note how we can already do this: P2SH uses Hash160, which is
RIPE160(SHA256(d)) We still need a new P2SH *address* type, that
provides the full 256 bits, but no-one
On Wed, Apr 10, 2013 at 12:15:26AM -0700, Gregory Maxwell wrote:
On Tue, Apr 9, 2013 at 11:53 PM, Peter Todd p...@petertodd.org wrote:
Of course, either way you have the odd side-effect that it's now
difficult to pay further funds to a random txout seen on the
blockchain... strange
On Wed, Apr 10, 2013 at 05:58:10PM +0200, Jorge Timón wrote:
On 4/10/13, Peter Todd p...@petertodd.org wrote:
Oh, and while we're at it, long-term (hard-fork) it'd be good to change
the tx hash algorithm to extend the merkle tree into the txouts/txins
itself, which means that to prove
Currently signmessage/verifymessage only supports messages signed by a
single key. We should extend that to messages signed by n-of-m keys, or
from the users point of view, P2SH multisig addresses.
rpc.cpp:signmessage() returns the output of SignCompact(). That in turn
starts with a header byte
On Sun, Apr 14, 2013 at 01:21:21AM -0400, Alan Reiner wrote:
If we're going to extend/expand message signing, can we please add a
proper ASCII-armored format for it? Really, anything that encodes the
signed message next to the signature, so that there's no ambiguities
about what was signed.
On Sun, Apr 14, 2013 at 05:26:37AM +, Luke-Jr wrote:
On Sunday, April 14, 2013 5:09:58 AM Peter Todd wrote:
Currently signmessage/verifymessage only supports messages signed by a
single key. We should extend that to messages signed by n-of-m keys, or
from the users point of view, P2SH
On Mon, Apr 15, 2013 at 04:59:33PM -0700, Pieter Wuille wrote:
How about: keep a counter in the mempool, remembering the sum of the sizes of
all replacements a transaction has had. When deciding whether to accept a
transaction as a replacement, increase this number and then check whether its
On Thu, Apr 18, 2013 at 10:32:24AM +0200, Mike Hearn wrote:
RE: shutting down services dependent on replacement. No, good users of
replacement would still end up taking priority over the constantly churning
DoS replacements. The most you can shut down is one contract. Obviously, if
there's no
On Thu, Apr 18, 2013 at 05:04:44AM -0400, Peter Todd wrote:
An attack still shuts down useful tx replacement though. For instance in
the adjusting payments example an attacker sets up a legit adjusting
payment channel, does a bunch of adjustments, and then launches their
attack. They broadcast
On Thu, Apr 18, 2013 at 11:28:48AM +0200, Mike Hearn wrote:
Let's include bandwidth. Say the contract (multi-sig input + the outputs)
is about 700 bytes. 43,200 transactions is then about 29 megabytes of data.
On a fairly normal 10mbit connection that would take about 23 seconds to
transfer.
On Mon, Apr 29, 2013 at 03:48:18AM +, John Dillon wrote:
We can build this stuff incrementally I'll agree. It won't be the case that
one
in a thousand nodes serve up the part of the chain you need overnight. So many
I am over engineering the solution with BitTorrent.
I think that pretty
On Mon, Apr 29, 2013 at 10:30:47PM +0800, Crypto Stick wrote:
Crypto Stick is an open source USB key for encryption and secure
authentication.
We have been accepted as a mentor organization for Google
Summer of Code (GSOC) 2013. One of our project ideas is to develop a
physical BitCoin wallet
On Fri, May 03, 2013 at 04:06:29PM +0200, Mike Hearn wrote:
That's true, but we can extend the DNS seeding protocol a little bit - you
could query current-chain-height.dnsseed.whatever.com and the DNS server
then only returns nodes it knows matches your requirement.
If you're going to take a
On Fri, May 03, 2013 at 05:02:26PM +0200, Mike Hearn wrote:
If you're going to take a step like that, the current-chain-height
should be rounded off, perhaps to some number of bits, or you'll allow
DNS caching to be defeated.
Don't the seeds already set small times? I'm not sure we want
On Mon, May 06, 2013 at 04:58:56PM +0200, Mike Hearn wrote:
More generally, I think this shows clearly how SPV nodes have weaker
security than constantly operating full nodes, which we knew already, so
why not build a better SPV-specific system instead?
I've noticed on my Android phone how it
On Mon, May 06, 2013 at 12:20:12PM -0400, Jeff Garzik wrote:
Security will be no worse than before - if any one server/seed is honest
you're ok - and hopefully better due to the accountability. Obviously
Indeed, the DNS seeds are just servers run by trusted individuals anyway.
Yup, and
On Mon, May 06, 2013 at 06:47:22PM +0200, Mike Hearn wrote:
Iteration 1) Make it clear in the UI that if the phone is connected to
WiFi, payments from untrusted people should not be accepted. Currently
the Android app merely says the money won't be spendable for a few
minutes. It needs to
On Mon, May 06, 2013 at 10:42:19AM -0700, Gregory Maxwell wrote:
On Mon, May 6, 2013 at 10:19 AM, Peter Todd p...@petertodd.org wrote:
running hash of all messages sent on a connection so far. Add a new
protocol message that asks the node to sign the current accumulated
hash.
We already
On Mon, May 06, 2013 at 11:01:22AM -0700, Gregory Maxwell wrote:
On Mon, May 6, 2013 at 10:53 AM, Peter Todd p...@petertodd.org wrote:
We don't have non-repudiation now, why make that a requirement for the
first version? Adding non-repudiation is something that has to happen at
the Bitcoin
On Mon, May 06, 2013 at 09:50:03PM +0200, Adam Back wrote:
Of course you'd probably need zerocoin to stand much chance of proving an
address private key of an unlinked coin was in the double-spend disclosed
attribute in the first place, and as we know zerocoin is not that efficient.
Sounds
On Tue, Apr 30, 2013 at 10:17:23AM -0700, Jeremy Spilman wrote:
[Aside] I was reading Peter's fidelitybond writeup for his idea on contract
value accounting, and he points to Stephan's post from last September on
payer-encoded metadata (
On Thu, May 09, 2013 at 09:39:10AM +1000, Addy Yeow wrote:
Hi list,
Can someone explain why do we have 32-bit and 64-bit timestamp fields
instead of all being 64-bit?
https://en.bitcoin.it/wiki/Protocol_specification
Who knows?
Satoshi used 32-bits and those fields can't be changed now
On Thu, May 09, 2013 at 01:27:33AM +, John Dillon wrote:
There's also no need: 32 bits is plenty of precision. Hell, even 16 bits
would
do (assuming there's never more than a 65535s (about 18 hours) gap between
two
blocks). Just assume the full 64-bit time is the smallest one that
On Thu, May 09, 2013 at 02:33:11AM +, John Dillon wrote:
On Thu, May 9, 2013 at 1:57 AM, Peter Todd p...@petertodd.org wrote:
Remember that interpreting the timestamp on a block for the purposes of
timestamping is a lot more subtle than it appears at first.
I actually just meant how
On Thu, May 09, 2013 at 02:07:23PM +0200, Adam Back wrote:
I have to say I do not think you want to have it be random as to who gets
paid (by having conflicting double spends floating around with different
payee change addresses all from the same sending address.)
Indeed. That's the point of
report: https://bitcointalk.org/index.php?topic=205349.0
Every talk will be widely witnessed and videotaped so we can get some
reasonably good security by simply putting out PGP fingerprints in our
slides. Yeah, some fancy attacker could change the videos after the
fact, but the talks themselves
On Tue, May 14, 2013 at 09:16:28PM +0200, Melvin Carvalho wrote:
FWIW I take this stuff pretty seriously myself. I generated my key
securely in the first place, I use a hardware smartcard to store my PGP
key, and I keep the master signing key - the key with the ability to
sign other keys -
On Wed, May 15, 2013 at 12:25:09PM +0200, Adam Back wrote:
Protocols aren't set in stone - any attacker that controls enough
hashing power to pose a 51% attack can simply demand that you use a
Bitcoin client modified to provide the attack with the full transactions
from the beginning. Any blocks
Now that I have the replace-by-fee reward, I might as well spread the
wealth a bit.
So for all this discussion about replace-by-fee and the supposed
security of zero-conf transactions, no-one seems to think much about how
in practice very few vendors have a setup to detect if conflicting
On Mon, May 20, 2013 at 08:54:25PM -0700, Gregory Maxwell wrote:
One point that was only recently exposed to me is that replacement
combined with child-pays-for-parent creates a new kind of double spend
_defense_: If someone double spends a payment to an online key of
yours, you can instantly
I just posted the following to bitcointalk.
https://bitcointalk.org/index.php?topic=221164.0
Right now between two to four running the largest pools control Bitcoin
in the short term. That's a lot of hashing power in the hands of very,
very few people. In addition pools have little incentive to
Currently the most compact way (proof-size) to sacrifice Bitcoins that
does not involve making them unspendable is to create a anyone-can-spend
output as the last txout in the coinbase of a block:
scriptPubKey: data OP_TRUE
The proof is then the SHA256 midstate, the txout, and the merkle path to
possible forms will work.
I'd say we tell people to sacrifice to (provably) unspendable for now
and do a soft-fork later if there is real demand for this stuff in the
future.
On Jun 1, 2013, at 3:30 PM, Peter Todd p...@petertodd.org wrote:
Currently the most compact way (proof-size
On Sun, Jun 02, 2013 at 01:35:10PM -0400, Jeff Garzik wrote:
It is a fair criticism that this inches the incentives, a bit, towards
timestamping and other non-currency uses. But those uses (a) cannot
be prevented and (b) have already been automated anyway (e.g. the
python upload/download
On Mon, Jun 10, 2013 at 04:09:26AM +, John Dillon wrote:
My general comments on the idea are that while it's hard to say if a
vote by proof-of-stake is really representative, it's likely the closest
thing we'll ever get to a fair vote. Proof-of-stake is certainely better
than just letting
So here's the parts that need to be done for step #1:
# Protocol Work
Basic idea is the miner makes two connections, their pool, and a local
bitcoind.
They always (usually?) work on the subset of transactions common to both
the pool's getblocktemplate and their local one. When they find a
On Mon, Jun 10, 2013 at 09:23:14PM +, Luke-Jr wrote:
They always (usually?) work on the subset of transactions common to both
the pool's getblocktemplate and their local one. When they find a share
if it doesn't meet difficulty they just hand it to the pool. Currently
that is done by
On Mon, Jun 17, 2013 at 11:16:01AM -0400, Jeff Garzik wrote:
Part of the broader issue that when we send peers INV advertisements we
should be telling them what the fee/kb is so our peers can prioritize
properly. That'd also help for the case where you want to broadcast two
transactions in
On Fri, Jul 05, 2013 at 04:01:40PM +0200, Adam Back wrote:
Do people think that should work? It seems to me it should with minimal,
bitcoin changes. I think the rule for either-or mining should be as simple
as skipping the value / double-spend validation of the blocks that are
zerocoin
On Sun, Jul 14, 2013 at 07:22:10PM +, John Dillon wrote:
Peter: I'm a bit confused by this concept of bi-directional sacrifice
though,
I assume there exists only a sacrifice in one direction right? Wouldn't
selling
a zerocoin be just a matter of giving zerocoin a rule so that the
On Mon, Jul 15, 2013 at 01:51:21AM +, Luke-Jr wrote:
On Monday, July 15, 2013 12:12:23 AM Peter Todd wrote:
On Sun, Jul 14, 2013 at 08:16:41PM +, Luke-Jr wrote:
P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as
well as (rewarded) Prime POW; maybe
On Sun, Jul 14, 2013 at 10:12:00PM +, John Dillon wrote:
For a non-SPV-mode client we can easily do anti-DoS by requiring the peer to
do
useful work. As the incoming connections slots get used up, simply kick off
the incoming peers who have relayed the least fee-paying transactions and
On Sat, Jul 13, 2013 at 11:32:39AM -0700, Peter Vessenes wrote:
One very real issue for alt-currencies that don't peg to Bitcoin is that
market liquidity is a bitch. By almost all standards current global Bitcoin
liquidity is already very, very low. Too low for many transactions that
come
On Mon, Jul 15, 2013 at 03:05:52PM +0200, Jorge Timón wrote:
One way sacrifice (btc to zerocoin) is a non-issue since there's no
modification required for bitcoin and you can't do anything to prevent
it anyway.
The controversial thing is sacrificing something outside bitcoin's
chain and new
On Tue, Jul 16, 2013 at 04:16:23PM +0200, Wendell wrote:
Hello everyone,
In the previous thread, I expressed interest in seeing an SPV bitcoind,
further stating that I would fund such work. Mike Hearn followed up with some
of Satoshi's old code for this, which is now quite broken. The
On Wed, Jul 17, 2013 at 02:37:11PM +0200, Tamas Blummer wrote:
Would not an SPV bitcoind transfer all control on validation rules to miner?
Yes
A majority coalition of miner (pool operator) might even decide to change
block reward
rules if the rest of the network only verifies POW.
On Fri, Apr 19, 2013 at 06:48:11PM -0700, Jeremy Spilman wrote:
0. User and AP negotiate how much to escrow, who pays the fees, and how
far in the future nLockTime will be set (how long user’s funds will be tied
if AP doesn’t close the channel)
1. User creates an unsigned TX1 with 1 or
On Thu, Jul 18, 2013 at 08:13:08AM -0400, Peter Todd wrote:
A more sophisticated approach would be possible if there existed a
version of H() with a computational trap-door - that is if there existed
H'(s, i)=H(i) where H' had significantly faster running time than H(),
but required knowledge
On Wed, Jul 17, 2013 at 03:37:41PM +0200, Wendell wrote:
Peter,
This sounds like a _very_ good idea for a desktop client, and probably
acceptable to users so long as we take available disk space into
consideration, and only ever use a fraction of it.
Will you implement this?
I've got
to write
the specifications and supervise/audit/advise for a few hours a week.
-wendell
grabhive.com | twitter.com/grabhive
On Jul 18, 2013, at 6:22 PM, Peter Todd wrote:
I've got one or two orders of magnitude more good ideas than I have time
to implement, but I will say this one would
On Tue, Jul 23, 2013 at 12:27:03PM +0100, Tier Nolan wrote:
I was thinking about a change to the rules for distinguishing between forks
and maybe a BIP..
Please provide equations and data justifying the 'magic constants' in
this proposal.
Currently we do not relay blocks to peers if they
Gavin Andresen recently suggested a design for a wallet protected by
two-factor authentication via one-time-passwords with the aid of a
third-party service to counter-sign 2-of-2 protected wallets.(1) The
design is useful when the user can't sign transactions on a second
device, such as a phone,
On Sat, Jul 27, 2013 at 07:49:18PM -0400, Peter Todd wrote:
Implementation
==
Savings use P2SH outputs matching the following scriptPubKey form:
HASH160 H(nonce_i) EQUALVERIFY pubkey CHECKSIG
spent with:
sig nonce_i
FWIW with some minor scripting language additions
On Mon, Jul 29, 2013 at 02:00:10AM -0400, Jeff Garzik wrote:
On Mon, Jul 29, 2013 at 1:17 AM, Luke-Jr l...@dashjr.org wrote:
On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote:
What are your thoughts on creating a whitelist for specific opcodes that
would apply to scripts serialized
On Tue, Jul 30, 2013 at 09:36:50PM +0200, Wendell wrote:
Thank you Peter.
Does this advice apply equally to both full and SPV nodes? At this point I'm
merely curious, since we don't have the option to run bitcoinj over Tor right
now anyway.
Yes, although remember that in general SPV nodes
On Wed, Jul 31, 2013 at 06:11:10PM -0400, Peter Todd wrote:
https://s3.amazonaws.com/peter.todd/litecoin-v0.8.3.7-audit-report.tar.bz2
I thought this may be of interest to Bitcoin as well as an example.
By request,
Zip archive:
https://s3.amazonaws.com/peter.todd/litecoin-v0.8.3.7-audit
On Sat, Jul 27, 2013 at 07:49:18PM -0400, Peter Todd wrote:
Funding the wallet
==
As with any multi-party wallet receiving funds must also be handled
carefully to ensure an attacker can't fool the user into giving the
sender the wrong address. This requires the involvement
On Fri, Aug 16, 2013 at 01:32:39PM +0200, Mike Hearn wrote:
and analysing it is really hard (plus it inverts the threat model - if you
trust your computer and not your hardware wallet, why do you have a
hardware wallet?)
Myself I would trust neither the hardware wallet nor my computer...
So
On Fri, Aug 16, 2013 at 02:24:04PM +0200, Mike Hearn wrote:
The only other thing I'd like to see there is the start of a new anti-DoS
framework. I think once the outline is in place other people will be able
to fill it in appropriately. But the current framework has to be left
behind.
Part of
On Fri, Aug 16, 2013 at 04:36:20PM +0200, Mike Hearn wrote:
That change was made in response to user complaints. Heck we get complaints
about battery life and bandwidth impact even with Bloom filtering. We can't
just randomly start using peoples bandwidth for relaying blocks, especially
as I
On Fri, Aug 16, 2013 at 05:11:35PM +0200, Mike Hearn wrote:
On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd p...@petertodd.org wrote:
UPNP seems to work well for the reference client. What's the situation
there on Android?
Not sure - it could be investigated. I think UPNP is an entirely
On Mon, Aug 19, 2013 at 12:00:23AM +0200, Mike Hearn wrote:
The original Bloom filtering spec did not make this feature optional for
the same reason gzip isn't an optional part of the PNG specification. I see
no reason to revisit that. It's definitely not the case that making every
possible
Currently there is no way for a node, SPV or otherwise, to know if a
transaction has been broadcast succesfully to any amount of hashing
power. This makes it difficult to determine if a transaction failed to
either propagate across the network, or failed to pay sufficient fees to
be worthy of
On Wed, Sep 25, 2013 at 01:35:48PM +0200, Melvin Carvalho wrote:
On 25 September 2013 13:15, Mike Hearn m...@plan99.net wrote:
It won't fit. But I don't see the logic. A URI contains instructions for
making a payment. If that instruction is pay to this address or download
this file and do
On Fri, Oct 04, 2013 at 11:42:29AM +0100, Andy Parkins wrote:
On Friday 04 October 2013 12:30:07 Mike Hearn wrote:
Git makes it easy to fork peoples work off and create long series of
commits that achieve some useful goal. That's great for many things.
Unfortunately, code review is not one
On Fri, Oct 04, 2013 at 12:30:07PM +0200, Mike Hearn wrote:
Git makes it easy to fork peoples work off and create long series of
commits that achieve some useful goal. That's great for many things.
Unfortunately, code review is not one of those things.
I'd like to make a small request - when
On Fri, Oct 04, 2013 at 01:58:51PM +0200, Arto Bendiken wrote:
On Fri, Oct 4, 2013 at 1:35 PM, Peter Todd p...@petertodd.org wrote:
The second caveat is more specific to Bitcoin: people tend to rebase
their pull-requests over and over again until they are accepted, but
that also means
1 - 100 of 455 matches
Mail list logo
