On Fri, May 09, 2014 at 02:05:24PM +0200, Mike Hearn wrote:
It's always interesting to see the reinvention cycle happen in the
Bitcoin space as ideas get proposed over and over again; I'm sure Amir
Taaki will be pleased to read this as it is a slightly less
sophisticated version of what he origina
On Fri, May 09, 2014 at 05:15:52PM +0200, Mike Hearn wrote:
> >
> > Of course we quickly rejected the idea of depending solely on a
> > communications backchannel to retrieve funds. Any communications medium
> > that isn't the blockchain makes the payment non-atomic
>
>
> Yes, I know you rejected
On Fri, May 09, 2014 at 05:34:07PM +0200, Mike Hearn wrote:
> >
> > Ah, you're still misunderstanding my point: You can get atomicity in the
> > worst-case where the communications medium fails *and* stealth payments
> > that use up no extra space in the blockchain. This gives you the best of
> > b
On Fri, May 09, 2014 at 05:50:33PM +0200, Pieter Wuille wrote:
> I believe stealth addresses and the payment protocol both have their
> use cases, and that they don't overlap.
>
> If you do not want to communicate with the receiver, you typically do
> not want them to know who is paying or for wha
On Fri, May 09, 2014 at 08:38:22PM +0200, Pieter Wuille wrote:
> On Fri, May 9, 2014 at 8:13 PM, Peter Todd wrote:
> > I don't think we're going to find that's practical unfortunately due to
> > change. Every payment I make ties up txouts, so if we try to base th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 May 2014 17:09:07 CEST, Mike Hearn wrote:
>The first rule of patents is *you do not go looking for patents*. US
>law is
>written in a really stupid way, such that if you knowingly infringe,
>damages triple. Because America uses the patent o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 May 2014 20:20:40 CEST, Justus Ranvier wrote:
>You and Gavin could do a lot better by working on a Bitcoin social
>contract - a promise of what features will *never* be added (or taken
>away) from Bitcoin, because despite what you say it's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 May 2014 20:43:15 CEST, Gregory Maxwell wrote:
>There are other defensive approaches which are interesting than hoping
>to use patents as a counter attack: For one— filing a patent gets the
>work entered in the only database that USPTO exam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I've got a PGP smart card reader and card with a securely generated key and pin
entered per signature.
Re: multisig, that's precisely why we want more than just a single maintainer
signing commits.
PGP isn't perfect, but perfect is the enemy of g
FWIW
That said, keep in mind the github discussion(1) that was had: if all
the DNS seeds being down breaks your application, your application is
broken and insecure. The only exception is initial startup, and even
then you should have fallbacks such as hardcoded node lists and manual
peer entry. I
On Sun, May 25, 2014 at 09:12:10PM +0200, Andreas Schildbach wrote:
> Thanks for looking at the issue.
>
> Unfortunately, it still fails for me:
>
> $ nslookup testnet-seed.bitcoin.petertodd.org
> Server: 127.0.1.1
> Address: 127.0.1.1#53
>
> ** server can't find testnet-seed.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27 May 2014 01:12:05 GMT+03:00, Andreas Schildbach
wrote:
>You're very quick to point at others. Especially since they run
>software
>that had the time to mature for about 30 years, and the protocol didn't
>really change since then...
>
>The l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27 May 2014 02:19:39 GMT+03:00, Andreas Schildbach
wrote:
>> Hey, really sorry I don't have the time to fix this issue, been
>> travelling for a few weeks for my consulting job. If you want to
>> step up and volunteer please feel free.
>
>I'm
Decided to take a break yesterday and write some code...
Timelock
Create a secret key that can be decrypted in a known amount of time
using parallel-serial hash chains. The creator can compute the timelock
in parallel, taking advantage of the large amount of cheap parallelism
available
BIP:
https://github.com/petertodd/bips/blob/bip-node-bloom/bip-node-bloom.mediawiki
Pull-req: https://github.com/bitcoin/bitcoin/pull/2900
Pretty simple really: service bit NODE_BLOOM is defined to allow nodes
to advertise to their peers that they support bloom filters. The network
protocol vers
On Fri, Jun 06, 2014 at 10:48:52AM +0200, Adam Back wrote:
> Advertising NODE BLOOM as a service sounds good.
>
> But the critique of bloom filters, I am not so sure prefix filters are
> better. Prefix filters offer questionable privacy tradeoffs in my
> opinion. Same problem as with stealth addr
On Fri, Jun 06, 2014 at 02:03:29AM -0700, Gregory Maxwell wrote:
> On Fri, Jun 6, 2014 at 1:48 AM, Adam Back wrote:
> > Advertising NODE BLOOM as a service sounds good.
> >
> > But the critique of bloom filters, I am not so sure prefix filters are
> > better. Prefix filters offer questionable pri
On Fri, Jun 06, 2014 at 12:45:43PM +0200, Adam Back wrote:
(changed subject line as this discussion has nothing to do with
NODE_BLOOM)
> As I recall prefix brute forcing was a bit twiddle saving, ie searching for
> EDH key that has the users public prefix. That does not improve privacy
> over an
On Fri, Jun 06, 2014 at 09:58:19AM -0700, Gregory Maxwell wrote:
> On Fri, Jun 6, 2014 at 9:46 AM, Peter Todd wrote:
> > transactions against. Where they differ is that bloom filters has O(n)
> > scaling, where n is the size of a block, and prefix filters have O(log n)
> > sc
On Fri, Jun 06, 2014 at 10:10:51AM -0700, Gregory Maxwell wrote:
> On Fri, Jun 6, 2014 at 10:05 AM, Peter Todd wrote:
> > Again, you *don't* have to use brute-force prefix selection. You can
> > just as easily give your peer multiple prefixes, each of which
> > correspon
On Sat, Jun 07, 2014 at 07:22:56PM +0800, Mike Hearn wrote:
> You can send different bloom filters to different peers too, so I'm not
> sure why you're listing subsetting as a unique advantage of prefix filters.
As I explained in the email you're replying to and didn't quote, bloom
filters has O(n
On Sat, Jun 07, 2014 at 03:44:07PM -0400, Alan Reiner wrote:
>
> On 06/07/2014 07:22 AM, Mike Hearn wrote:
> >
> > You can send different bloom filters to different peers too, so I'm
> > not sure why you're listing subsetting as a unique advantage of prefix
> > filters.
> >
> >
>
> Please let me
On Tue, Jun 10, 2014 at 06:38:23PM +0800, Mike Hearn wrote:
> >
> > As I explained in the email you're replying to and didn't quote, bloom
> > filters has O(n) cost per query, so sending different bloom filters to
> > different peers for privacy reasons costs the network significant disk
> > IO res
ably, simple destruction
of coins. (sacrifice to fees encourages mining centralization for
obvious reasons)
1) "[Bitcoin-development] Trusted identities", Apr 26th 2012, Peter Todd,
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg01005.html
Incidentally, my f
For my replace-by-fee implementation(1) I used service bit 26 to let
preferential peering work so that replace-by-fee nodes could easily find
each other. Of course, that's a temporary/experimental usage that can be
dropped after wider adoption, so I included the following comment:
// Reserve 2
On Tue, Jun 17, 2014 at 03:40:36PM -0400, Gavin Andresen wrote:
> Assuming there is rough consensus, I'll make this a pull request (see
> https://github.com/gavinandresen/bitcoin-git/tree/relax_isstandard for code
> changes).
I'm also working on a very similar patch with some additional
protection
On Wed, Jun 18, 2014 at 08:52:22AM -0400, Gavin Andresen wrote:
> RE: most of Peter Todd's comments:
>
> All of that should be separate pull requests. Big Honking Pull Requests
> are harder to review and are more likely to be bike-shedded to death.
Well, just doing one and not the rest isn't nec
On Thu, Jun 19, 2014 at 09:54:31AM -0400, Gavin Andresen wrote:
> RE: soft-forks bumping version numbers:
>
> Yes, we have consensus that is the way we will do it. I should probably
> turn https://gist.github.com/gavinandresen/2355445 into an informational
> BIP.
Sounds like it could turn EvalSc
On Tue, Jul 15, 2014 at 04:00:41AM -0400, Jeff Garzik wrote:
> Proxying another's idea, from CoinSummit.
>
> The request: It would be useful to limit the lifetime of a bitcoin
> address. Intentionally prevent (somehow) bitcoins being sent to a
> pubkey/pkh after the key expires.
>
> You could
On Mon, Jul 21, 2014 at 03:43:42PM +0200, Wladimir wrote:
> We've established a few basic rules for the DNS seeds as used in the
> Bitcoin Core software. See below.
>
> If you run one of the DNS seeds please reply to this and let us know
> whether you agree to these terms. if you think some requir
he median time in
the past. In addition doing the latter causes difficulty to rise.
Also see: "Re: [Bitcoin-development] 32 vs 64-bit timestamp fields" -
Peter Todd - 08 May 2013
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02144.html
> >
On Sun, Jul 27, 2014 at 10:12:11PM -0400, Jeremy wrote:
> Hey,
>
> There is a potential network exploit going on. In the last three days, a
> node (unnamed) came online and is now processing the most traffic out of
> any tor node -- and it is mostly plaintext Bitcoin traffic.
>
> http://torstatus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I've got a bitcoin-only exit running myself and right now there is absolutely
no traffic leaving it. If the traffic coming from that node was legit I'd
expect some to be exiting my node too.
Multiple people have confirmed the node is connected to
On Thu, Jul 31, 2014 at 05:58:23PM -0700, Kaz Wesley wrote:
> I have a proposal for a way to add finite and predictable lifespans to
> transactions in mempools: we d̶e̶s̶t̶r̶o̶y̶ ̶t̶h̶e̶
> ̶r̶e̶s̶u̶r̶r̶e̶c̶t̶i̶o̶n̶ ̶h̶u̶b̶ use nLockTime and a new standardness
> rule. It could be done in stages, wou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
wrote:
>+1 for the new field, overloading fields with new meaning is definitely
>not
>a good idea.
To add a new field the best way to do it is create a new, parallel, tx format
where fields
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 09:31:24 GMT-07:00, Mark Friedenbach wrote:
>I highly doubt that is the best approach.
>
>If this nExpiry field is a consensus rule, then the Merkle tree or the
>appropriate paths through needs to be included with the transaction
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 10:21:56 GMT-07:00, Mark Friedenbach wrote:
>On 08/06/2014 01:02 PM, Tom Harding wrote:
>> With first-eligible-height and last-eligible-height, creator could
>> choose a lifetime shorter than the max, and in addition, lock the
>w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 10:30:11 GMT-07:00, Mark Friedenbach wrote:
>On 08/06/2014 01:20 PM, Peter Todd wrote:
>> The general case doesn't require transmission of any merkle data; it
>> is derived from the tx data.
>
>How can
Real-world experience with stealth address implementations used by
Cryptonote/Monero/etc. have shown that being able to attach a number of
some kind to each stealth-sent txout is valuable. For instance an
exchange with many customers can use such #'s to disambiguate payments
and credit the correct
he profitability of the transaction are
dropped, including the attacker's added txins. Meanwhile txins that
increase the profitability can be added by anyone.
1) "[Bitcoin-development] Replace-by-fee scorched-earth without
child-pays-for-parent",
Apr 28th 2014, Peter Todd,
https://ww
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13 August 2014 11:00:22 GMT-07:00, Richard Moore wrote:
>Hey all,
>
>Sorry to keep bugging you all, as I slowly verify the blockchain one
>transaction after another with my own implementation, but I have found
>another transaction that is obvio
A number of people - most recently Gavin Andresen - have speculated that
cloud hashing operations may in fact be ponzi schemes that don't
actually own the hashing power they claim to own. The claim is that the
customers upfront purchase of hashing power is simply kept and used to
pay off existing c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik wrote:
>Encryption is of little value if you may deduce the same information
>by observing packet sizes and timings.
That is simply incorrect. The resources required to do that kind of monitoring
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 20:21:35 GMT-04:00, Jeff Garzik wrote:
>On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd wrote:
>> That is simply incorrect. The resources required to do that kind of
>monitoring are very high; even the NSA can&#
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 20:49:01 GMT-04:00, Justus Ranvier
wrote:
>On 08/20/2014 12:16 AM, Peter Todd wrote:
>> The easiest way to do this would be to make the Debian/Ubuntu
>> packages depend on Tor, and include a install-time script
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 20:59:14 GMT-04:00, William Yager
wrote:
>What, exactly, do we hope to achieve from having end-to-end encryption?
>
>Even if it worked perfectly, it wouldn't be very useful.
>
>But it won't work perfectly, because we don't have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 21:19:43 GMT-04:00, William Yager
wrote:
>On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd wrote:
>> In any case, my suggestion of enabling hidden service support by
>default
>> adds both encryption a
On Sat, Aug 23, 2014 at 01:17:01AM -0500, Troy Benjegerdes wrote:
> This is why I clone git to mercurial, which is generally designed around the
> assumption that history is immutable. You can't rewrite blockchain history,
> and we should not be re-writing (rebasing) commit history either.
Git com
On Sat, Aug 23, 2014 at 12:44:14PM -0500, Troy Benjegerdes wrote:
What I would really like is a frontend and/or integration to Git/Mercurial that
> uses Bitcoin transactions *as* the signature, which has the nice side effect
> of
> providing timestamps backed by the full faith and credit of a bil
On Sat, Aug 23, 2014 at 07:02:55PM +, Luke Dashjr wrote:
> On Saturday, August 23, 2014 6:44:15 PM Mike Hearn wrote:
> > > Not to mention encrypting basically non-sensitive inter-node traffic is
> > > almost completely worthless in providing anonymity anyway...
> >
> > Recall that P2P connecti
So far I have zero evidence that the common claim that "Satoshi PGP
signed everything" was true; I have no evidence he ever
cryptographically signed any communications at all.
--
'peter'[:-1]@petertodd.org
0ce4f740fb700bb8a9ed859ac96ac9871567a20fca07f76a
signature.asc
Descriptio
On Sat, Sep 13, 2014 at 10:03:20AM -0400, Jeff Garzik wrote:
> That claim is horse manure :) He never signed private emails sent to
> me, nor the forum posts.
That's consistent with what everyone else is saying:
https://twitter.com/petertoddbtc/status/509614729879642113
> He -might- have signed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15 September 2014 17:10:14 BST, Gregory Maxwell wrote:
>If the server could replace the public key, it could replace the
>signature in all the same places.
>
>Please, can this stuff move to another list? It's offtopic.
+1
My original post was
On Sat, Sep 20, 2014 at 08:38:15AM -0700, Peter Grigor wrote:
> From block 0 to block 72499 the Merkle root is the same as the
> coinbase transaction id. Why is that?
It's because of how the merkle tree algorithm works:
uint256 CBlock::BuildMerkleTree() const
{
vMerkleTree.clear()
ut:
>
> - Increase IsStandard() scriptSig length
>
> Is there some place I read more to understand this change?
commit 84fe0ffd685627689bbbcd14cf419938f2a100b2
Author: Peter Todd
Date: Mon Mar 10 16:38:44 2014 -0400
Increase IsStandard() scriptSig length
Removes the limits o
On Sat, Sep 27, 2014 at 07:55:44PM -0700, Tom Harding wrote:
> On 9/25/2014 7:37 PM, Aaron Voisine wrote:
> > Of course you wouldn't want nodes to propagate alerts without
> > independently verifying them
> How would a node independently verify a double-spend alert, other than
> by having access t
On Thu, Jun 19, 2014 at 09:54:31AM -0400, Gavin Andresen wrote:
> RE: soft-forks bumping version numbers:
>
> Yes, we have consensus that is the way we will do it. I should probably
> turn https://gist.github.com/gavinandresen/2355445 into an informational
> BIP.
That gist is mistaken. To see th
On Mon, Sep 29, 2014 at 12:30:11AM -0400, Alan Reiner wrote:
> On 09/28/2014 10:35 PM, Peter Todd wrote:
> > This can be solved by upgrading the address format at
> > the same time to let senders know they must send the funds in a
> > transaction with an increased version
et of unittests for the
opcode semantics can be found at:
https://github.com/petertodd/bitcoin/compare/checklocktimeverify
BIP:
Title: OP_CHECKLOCKTIMEVERIFY
Author: Peter Todd
Status: Draft
Type: Standards Track
Created: 2014-10-01
==Abstract==
This BIP describes a new o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Yeah, there are lots of "upper-level" details to consider; I'm not going to
pretend that BIP is complete yet. My thinking is that the first release should
include my NOPx blacklist pull-req, and leave NOP2/CHECKLOCKTIMEVERIFY in that
blacklist for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr wrote:
>Thoughts on some way to have the stack item be incremented by the
>height at
>which the scriptPubKey was in a block?
Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 14:34:33 GMT-07:00, Gavin Andresen
wrote:
>On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner
>wrote:
>No, the burner would supply the funding transaction plus the redeeming
>script as the proof-of-burn to whoever needed the proof.
N
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 08:01:28 GMT-07:00, Gavin Andresen
wrote:
>Very nice, semantics are clear and use cases are compelling.
Thanks!
>Can we defer discussion of how to roll this out for a little bit, and
>see
>if there is consensus that:
>
>a) ben
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr wrote:
>On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
>> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr
>wrote:
>> >Thoughts on some way to have the stack i
On Fri, Oct 03, 2014 at 07:12:11PM -0400, Jeff Garzik wrote:
> RE " It's not like other software where people can choose to skip an
> upgrade and things still work just like before."
>
> If you're a minority, sure you can. Still a few nutters out there on
> a 0.3.x codebase, including one or two
On Thu, Oct 09, 2014 at 06:28:19AM +, Gregory Maxwell wrote:
> On Thu, Oct 9, 2014 at 6:14 AM, Adam Back wrote:
> > I think you can do everything with the existing script level nlocktime
> > in some kind of turing completeness sense (maybe); but there is a
> > complexity cost that often you ha
On Mon, Oct 13, 2014 at 07:34:16PM -0700, Pieter Wuille wrote:
> Hi all,
>
> while working on a BIP62 implementation I discovered yet another type
> of malleability: the interpretation of booleans.
>
> Any byte array with non-zero bytes in it (ignoring the highest bit of
> the last byte, which is
On Tue, Oct 14, 2014 at 11:54:36AM -0700, Pieter Wuille wrote:
> > I think a decent argument *for* doing this is that if a script author
> > fails to properly 'bool-ize' every boolean-using path that can have
> > non-minimal encodings in normal execution, you can always create a
> > nVersion=1 tran
On Wed, Oct 15, 2014 at 04:54:57PM +0100, Adam Back wrote:
> please not google groups *, I'd vote for sourceforge or other simple
> open list software over google groups.
>
> Adam
>
> * Google lists are somehow a little proprietary or gmail lockin
> focused eg it makes things extra hard to subscr
On Wed, Oct 15, 2014 at 08:00:10PM +0100, Btc Drak wrote:
> > * Google lists are somehow a little proprietary or gmail lockin
> > focused eg it makes things extra hard to subscribe with a non-google
> > address if google has any hint that your address is associated with a
> > gmail account. Quite
On Mon, Oct 27, 2014 at 03:33:45PM -0400, Alex Morcos wrote:
> I've been playing around with the code for estimating fees and found a few
> issues with the existing code. I think this will address several
> observations that the estimates returned by the existing code appear to be
> too high. Fo
On Tue, Nov 04, 2014 at 05:29:46AM -0800, Pieter Wuille wrote:
> one of the rules in BIP62 is the "clean stack" requirement, which
> makes passing more inputs to a script than necessary illegal.
>
> Unfortunately, this rule needs an exception for P2SH scripts: the test
> can only be done after (an
On Tue, Nov 04, 2014 at 12:00:43PM -0800, Pieter Wuille wrote:
> On Tue, Nov 4, 2014 at 11:56 AM, Jeff Garzik wrote:
> > On Tue, Nov 4, 2014 at 8:13 PM, Peter Todd wrote:
> >> On another topic, I'm skeptical of the choice of nVersion==3 - we'll
> >> li
So right now git head will accept the following invalid transaction into
the mempool:
010001140de229e08fda25cbc16ded2618cdacce49fcb18c0b6ccdace00040909adae49000493046022100f7828d81c849c5448ba5ba4ef55df6b4d0ba3ae3f1a59cff3291880c2c8e524f022100d2f5bc9dc2f0674eded31023cb47e61a596e10f8f1dd
On Thu, Nov 06, 2014 at 05:38:20AM -0500, Peter Todd wrote:
> So right now git head will accept the following invalid transaction into
> the m
On Thu, Nov 06, 2014 at 02:47:29AM -0800, Pieter Wuille wrote:
> On Thu, Nov 6, 2014 at 2:38 AM, Peter Todd wrote:
> > However the implementation of the STRICTENC flag simply makes pubkey
> > formats it doesn't recognize act as through the signature was invalid,
> &g
Recently wrote the following for a friend and thought others might learn
from it.
> Nope, never heard that term. By "bug-for-bug" compatibility, do you mean
> that, for each version which has a bug, each bug must behave in the *same*
> buggy way?
Exactly. tl;dr: if you accept a block as valid d
On Thu, Nov 06, 2014 at 10:05:54PM +, Matt Corallo wrote:
> Depends, without BIP62 a /lot/ of the even basic contracts that people
> want to use today (or wanted to use 18 months ago) are unusable, in
> fact, without BIP62, the atomic swaps suggested as important for
> sidechains are not secure
On Thu, Nov 06, 2014 at 11:11:52PM +0100, Jeff Garzik wrote:
> IMO, CHECKLOCKTIMEVERIFY should be included in that list, too.
>
> RE soft fork vs. hard fork: It's about this time at Mike Hearn will
> chime in, on the side of hard forks. Hard forks are in a sense much
> cleaner, and permit solvin
On Thu, Nov 06, 2014 at 04:48:54PM -0600, Justus Ranvier wrote:
> Why not schedule protocol upgrades every two years for the foreseeable
> future?
For the same reason we don't do hard-forking upgrades of basically every
protocol on the planet on a regular basis, even when we don't have
consensus p
On Thu, Nov 06, 2014 at 05:36:55PM -0600, Justus Ranvier wrote:
> This explanation is completely incoherent.
>
> Because Bitcoin has a extra consensus requirements, requirements which
> are really rare in engineering, the necessity of fixing bugs is even
> greater.
>
> There are two general ways
On Fri, Nov 07, 2014 at 09:07:47AM +0100, Tamas Blummer wrote:
> Peter,
>
> forking would work best with a freeze of the consensus code. Do you see any
> chance for that?
To a first approximation the consensus code *is* frozen; if we introduce
any consensus changes into it at this point it's due
On Fri, Nov 07, 2014 at 11:30:22AM +, Clément Elbaz wrote:
> Thinking out loud here : would it make sense to separate the consensus code
> into some kind of "Bitcoin Kernel" (similar to the Linux Kernel) project
> that could be used by anyone ?
That's a pretty old idea, and we're working on it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27 November 2014 18:46:23 GMT-05:00, Gregory Maxwell
wrote:
>The things you're suggesting were all carefully designed out of the
>proposal, perhaps the BIP text needs some more clarification to make
>this more clear.
It does; it is still a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 4 December 2014 20:02:17 GMT+00:00, Jeffrey Paul wrote:
>
>> On 20141204, at 07:42, Luke Dashjr wrote:
>>
>> Is anyone working on a serialisation format to convey P2SH HD chains?
>For
>> example, to give someone who wants to make recurring pay
Introduction
While not a new concept proof-of-publication is receiving a significant
amount of attention right now both as an idea, with regard to the
embedded consensus systems that make use of it, and in regard to the
sidechains model proposed by Blockstream that rejects it. Here we
From the So-Obvious-No-one-Has-Bothered-to-Write-It-Down-Department:
tl;dr: Micropayment channels can be extended to arbitrary numbers of
parties using a nearly completley untrusted hub, greatly decreasing
transaction fees and greatly increasing the maximum number of financial
transactions per sec
On Fri, Dec 12, 2014 at 07:50:48PM +0200, Alex Mizrahi wrote:
> > I think what Gareth was getting at was that with client-side validation
> > there can be no concept of a soft-fork. And how certain are you that the
> > consensus rules will never change?
> >
>
> Yes, it is true that you can't do a
#x27;t be double-spent either if
implemented correctly; see my other reply to this thread today)
> Bitcoin is where it is today because of Satoshi's elegant solution to
> exactly such problems. Which some people now appear to be in a hurry to
> discard :)
FWIW usually Satoshi'
On Fri, Dec 12, 2014 at 01:41:34PM +, odinn wrote:
> Peter... It kind of sounds to me that (as fine of a position paper as
> this is) on _certain_ points, you're falling prey to the "but it's
> inefficient, but it's a scamcoin, but luke-jr told me so" argument...
I prefer to make robust argume
On Mon, Dec 15, 2014 at 11:21:01AM +0100, Tamas Blummer wrote:
> Burn mining side chains might be one of the foundation ideas for that
> ecosystem, enabling permission-less merge mining for
> anyone with interest in a side chain.
>
> I am puzzled by the lack of feedback on the idea.
It's not a n
BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a few
days ago and found a fairly large design change that makes merging it currently
impossible. Pull-req #4890², specifically commit c7829ea7, changed the
EvalScript() function to take an abstract SignatureChecker object, rem
On Tue, Dec 16, 2014 at 11:55:50AM +0200, Alex Mizrahi wrote:
> Usually at this point people say "we assume that miners aren't going to
> collude, otherwise even Bitcoin is not secure".
> Well, this is BS. The fact that a pool can acquire more than 50% of total
> hashpower was successfully demonstr
2014-12-20,
https://bitcointalk.org/index.php?topic=277389.msg2961736
2) Setting the record straight on Proof-of-Publication,
Peter Todd, Dec 12th 2014,
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06570.html
3) Decentralized digital asset exchange with honest pr
On Sun, Dec 21, 2014 at 11:57:51AM +0800, Mark Friedenbach wrote:
> On Sat, Dec 20, 2014 at 10:48 PM, Peter Todd wrote:
>
> > However the converse is not possible: anti-replay cannot be used to
> > implement proof-of-publication. Knowing that no conflicting message
> > e
On Wed, Dec 17, 2014 at 10:55:28PM +1100, Gareth Williams wrote:
> > I covered this in my original post: 1-way-pegs allow the creation of new
> > valuable tokens without those tokens being useful for speculation.
>
> I stand corrected. A permanent 1-way-peg is sufficient to preserve
> scarcity; "n
t-running protection might be the *only* thing they use a
decentralized system for.
1) Decentralized digital asset exchange with honest pricing and market depth,
Peter Todd, Feb 9th 2014,
http://www.mail-archive.com/bitcoin-development%40lists.sour
On Sun, Dec 21, 2014 at 07:49:17AM -0600, paul snow wrote:
> On Dec 20, 2014 8:49 AM, "Peter Todd" wrote:
> >
> > However the converse is not possible: anti-replay cannot be used to
> implement proof-of-publication. Knowing that no conflicting message exists
&g
On Sun, Dec 21, 2014 at 10:01:37AM +, Adam Back wrote:
> On 20 December 2014 at 14:48, Peter Todd wrote:
> > We need the following primitives operating on message m, pubkey p, and a
> > valid signature sig1 for m, p:
> >
> > AntiReplaySign(m, p, sig1) -> sig2
On Sun, Dec 21, 2014 at 03:11:32PM +0800, Mark Friedenbach wrote:
> On Sun, Dec 21, 2014 at 3:01 PM, Peter Todd wrote:
>
> > Right, so Freimarkets is deliberately insecure.
> >
>
> Please define your terms, particularly what your security requirements are
> here. In
1 - 100 of 578 matches
Mail list logo
