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 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 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, 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 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 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 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 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
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 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
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 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 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
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 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
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 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
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
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
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%
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
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 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
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 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
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
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
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
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:
#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*,
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
401 - 455 of 455 matches
Mail list logo
