[Bitcoin-development] Trusted identities

2012-04-26 Thread Peter Todd
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

Re: [Bitcoin-development] Trusted identities

2012-04-26 Thread Peter Todd
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

[Bitcoin-development] Stackoverflow with latest git head

2012-05-12 Thread Peter Todd
#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*,

Re: [Bitcoin-development] IPv6 bitcoin support now live

2012-05-27 Thread Peter Todd
On Sat, May 26, 2012 at 03:14:40PM +0200, Pieter Wuille wrote: On Sat, May 12, 2012 at 3:42 AM, Jeff Garzik jgar...@exmulti.com wrote: sipa just pushed out IPv6 support to bitcoin/bitcoin.git, and we have a few IPv6 nodes live on the network already. If you have IPv6, please pull the

Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite nodes

2012-06-17 Thread Peter Todd
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:

Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite nodes

2012-06-18 Thread Peter Todd
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

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-28 Thread Peter Todd
On Mon, Nov 26, 2012 at 05:37:31PM -0500, Gavin Andresen wrote: Why not JSON? - Invoice, Payment and Receipt messages could all be JSON-encoded. And the Javascript Object Signing and Encryption (JOSE) working group at the IETF has a draft specification for signing JSON data.

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-28 Thread Peter Todd
On Wed, Nov 28, 2012 at 11:43:19AM +0100, Mike Hearn wrote: Peter is correct that there are a few degrees of freedom in protobuf serialization, though far fewer than with JSON. FWIW I re-read the specs again and turns out my memory was wrong. (I last looked at this about four months ago)

[Bitcoin-development] Proposal: make the private key for testnet genesis block public

2013-01-14 Thread Peter Todd
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

[Bitcoin-development] Testnet DNS seed

2013-01-23 Thread Peter Todd
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

Re: [Bitcoin-development] Testnet DNS seed

2013-01-27 Thread Peter Todd
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

Re: [Bitcoin-development] Blockchain as root CA for payment protocol

2013-02-08 Thread Peter Todd
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

Re: [Bitcoin-development] Blockchain as root CA for payment protocol

2013-02-11 Thread Peter Todd
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

[Bitcoin-development] RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts

2013-02-12 Thread Peter Todd
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

Re: [Bitcoin-development] RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts

2013-02-12 Thread Peter Todd
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

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

2013-02-13 Thread Peter Todd
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

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

2013-02-13 Thread Peter Todd
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

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

2013-02-18 Thread Peter Todd
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%

[Bitcoin-development] How small blocks make delibrate orphan mining costly

2013-02-23 Thread Peter Todd
In the low-subsidy future fees will be the main source of income for miners. Thus in some circumstances large miners may even have a reason to delibrately try to mine a block that would orphan the current best block. A simple example would be what would happen if a 1000BTC fee tx was created, but

[Bitcoin-development] Fidelity-bonded ledgers

2013-02-25 Thread Peter Todd
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

[Bitcoin-development] Large-blocks and censorship

2013-03-07 Thread Peter Todd
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

Re: [Bitcoin-development] Large-blocks and censorship

2013-03-07 Thread Peter Todd
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

Re: [Bitcoin-development] Large-blocks and censorship

2013-03-07 Thread Peter Todd
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

Re: [Bitcoin-development] Large-blocks and censorship

2013-03-10 Thread Peter Todd
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

[Bitcoin-development] Changing the fee on already sent transactions

2013-03-12 Thread Peter Todd
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

Re: [Bitcoin-development] Warning: many 0.7 nodes break on large number of tx/block; fork risk

2013-03-12 Thread Peter Todd
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.

Re: [Bitcoin-development] Warning: many 0.7 nodes break on large number of tx/block; fork risk

2013-03-12 Thread Peter Todd
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.

Re: [Bitcoin-development] Warning: many 0.7 nodes break on large number of tx/block; fork risk

2013-03-12 Thread Peter Todd
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

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Peter Todd
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

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Peter Todd
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

Re: [Bitcoin-development] Blocksize and off-chain transactions

2013-03-13 Thread Peter Todd
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

Re: [Bitcoin-development] Ok to use 0.8.x?

2013-03-16 Thread Peter Todd
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

Re: [Bitcoin-development] A mining pool at 46%

2013-04-05 Thread Peter Todd
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

Re: [Bitcoin-development] On-going data spam

2013-04-09 Thread Peter Todd
On Mon, Apr 08, 2013 at 09:22:10PM -0400, Jeff Garzik wrote: http://www.reddit.com/r/Bitcoin/comments/1bw9xg/data_in_the_blockchain_wikileaks/ TD petertodd: yeah somebody put a file upload tool into the chain and then tried to upload the entire amibios source code to it. stupid. TD someone

Re: [Bitcoin-development] On-going data spam

2013-04-09 Thread Peter Todd
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,

Re: [Bitcoin-development] On-going data spam

2013-04-09 Thread Peter Todd
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

Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution

2013-04-09 Thread Peter Todd
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

Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution

2013-04-09 Thread Peter Todd
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

Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution

2013-04-10 Thread Peter Todd
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

Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution

2013-04-10 Thread Peter Todd
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

Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution

2013-04-11 Thread Peter Todd
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

[Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

2013-04-13 Thread Peter Todd
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

Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

2013-04-14 Thread Peter Todd
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.

Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

2013-04-14 Thread Peter Todd
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

Re: [Bitcoin-development] [bitcoin] Enable tx replacement on testnet. (#2516)

2013-04-16 Thread Peter Todd
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

Re: [Bitcoin-development] Anti DoS for tx replacement

2013-04-16 Thread Peter Todd
Post tge malicious miners and other bits so we can evaluate the system as a whole. Mike Hearn m...@plan99.net wrote: This was previously discussed on the forums a bunch of times, but in particular here: https://bitcointalk.org/index.php?topic=91732.0 BTW, I don't think all this has to be

Re: [Bitcoin-development] Anti DoS for tx replacement

2013-04-18 Thread Peter Todd
On Thu, Apr 18, 2013 at 06:07:23AM +, John Dillon wrote: Gavin do you actually agree with Mike on this stuff like he implies? Because if you do, I think people should know. Myself I wouldn't want to be contributing to your salary as a foundation member if you don't take Bitcoin security

Re: [Bitcoin-development] Anti DoS for tx replacement

2013-04-18 Thread Peter Todd
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

Re: [Bitcoin-development] Anti DoS for tx replacement

2013-04-18 Thread Peter Todd
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

Re: [Bitcoin-development] Anti DoS for tx replacement

2013-04-18 Thread Peter Todd
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.

Re: [Bitcoin-development] Service bits for pruned nodes

2013-04-28 Thread Peter Todd
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

Re: [Bitcoin-development] Hardware BitCoin wallet as part of Google Summer of Code

2013-04-29 Thread Peter Todd
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

Re: [Bitcoin-development] Service bits for pruned nodes

2013-05-03 Thread Peter Todd
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

Re: [Bitcoin-development] Service bits for pruned nodes

2013-05-03 Thread Peter Todd
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

Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Peter Todd
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

Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Peter Todd
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

Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Peter Todd
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

Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Peter Todd
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

Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Peter Todd
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

Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Peter Todd
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

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-05-06 Thread Peter Todd
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 (

Re: [Bitcoin-development] 32 vs 64-bit timestamp fields

2013-05-08 Thread Peter Todd
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

Re: [Bitcoin-development] 32 vs 64-bit timestamp fields

2013-05-08 Thread Peter Todd
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

Re: [Bitcoin-development] 32 vs 64-bit timestamp fields

2013-05-08 Thread Peter Todd
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

Re: [Bitcoin-development] An initial replace-by-fee implementation is now available

2013-05-09 Thread Peter Todd
On Thu, May 09, 2013 at 01:19:13PM +0200, Adam Back wrote: In this thread discussing this idea https://bitcointalk.org/index.php?topic=179612.0 it is suggested that the approach risks making 0-confirm double-spends easier. The patch makes the concept of a 0-confirm double-spend obsolete

Re: [Bitcoin-development] An initial replace-by-fee implementation is now available

2013-05-09 Thread Peter Todd
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

[Bitcoin-development] Coinbase TxOut Hashcash

2013-05-10 Thread Peter Todd
compatible with existing ASIC mining hardware, by taking advantage of the fact that ASIC's use the SHA256 midstate at a starting point for their PoW calculations.(3) 1) Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes) - 2013-06-06 - Peter Todd p...@petertodd.org

[Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides

2013-05-14 Thread Peter Todd
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

Re: [Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides

2013-05-14 Thread Peter Todd
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 -

Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-15 Thread Peter Todd
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

[Bitcoin-development] 2BTC reward for making probabalistic double-spending via conflicting transactions easy

2013-05-15 Thread Peter Todd
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

Re: [Bitcoin-development] 2BTC reward for making probabalistic double-spending via conflicting transactions easy

2013-05-15 Thread Peter Todd
On Wed, May 15, 2013 at 07:38:27AM -0400, Peter Todd wrote: So I'm offering 2BTC for anyone who comes up with a nice and easy to use command line tool that lets you automagically create one version of the transaction sending the coins to the desired recipient, and another version sending all

Re: [Bitcoin-development] Double Spend Notification

2013-05-21 Thread Peter Todd
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

[Bitcoin-development] Decentralizing mining

2013-05-31 Thread Peter Todd
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

[Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

2013-06-01 Thread Peter Todd
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

Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

2013-06-02 Thread Peter Todd
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

Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

2013-06-02 Thread Peter Todd
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

Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

2013-06-09 Thread Peter Todd
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

Re: [Bitcoin-development] Decentralizing mining

2013-06-10 Thread Peter Todd
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

Re: [Bitcoin-development] Decentralizing mining

2013-06-14 Thread Peter Todd
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

Re: [Bitcoin-development] Decentralizing mining

2013-06-17 Thread Peter Todd
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

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-30 Thread Peter Todd
double-spends easy to accomplish by including Satoshidice outputs) I just got an email from someone saying they had a few Avalons with that patch installed actually; that was probably them. I'm actually surprised by that figure myself given Peter Todd and I haven't made a serious attempt yet

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-12 Thread Peter Todd
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

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-14 Thread Peter Todd
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 with no subsidy halving, to try a new economic idea as well ;) Your ideas about making an alt-coin have anything to do with

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-14 Thread Peter Todd
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

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-14 Thread Peter Todd
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

Re: [Bitcoin-development] Protecting Bitcoin against network-wide DoS attack

2013-07-15 Thread Peter Todd
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

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-15 Thread Peter Todd
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

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-15 Thread Peter Todd
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

Re: [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-17 Thread Peter Todd
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

Re: [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-17 Thread Peter Todd
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.

Re: [Bitcoin-development] Anti DoS for tx replacement

2013-07-18 Thread Peter Todd
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

Re: [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-18 Thread Peter Todd
On Wed, Jul 17, 2013 at 02:29:26PM +0200, Mike Hearn wrote: Partial UTXO sets is a neat idea. Unfortunately my intuition is that many SPV wallets only remain open for 1 minute at a time because the user wants to see they received money, or to send it. It'd be neat to get some telemetry from

Re: [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-18 Thread Peter Todd
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

Re: [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-18 Thread Peter Todd
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

Re: [Bitcoin-development] SPV bitcoind? (was: Introducing BitcoinKit.framework)

2013-07-18 Thread Peter Todd
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

Re: [Bitcoin-development] Distributing low POW headers

2013-07-24 Thread Peter Todd
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

[Bitcoin-development] Two factor wallet with one-time-passwords

2013-07-27 Thread Peter Todd
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,

Re: [Bitcoin-development] Two factor wallet with one-time-passwords

2013-07-27 Thread Peter Todd
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

Re: [Bitcoin-development] Opcode whitelist for P2SH?

2013-07-29 Thread Peter Todd
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

  1   2   3   4   5   >