I was talking to a lawyer with a background in finance law the other day
and we came to a somewhat worrying conclusion: authors of Bitcoin wallet
software probably have a custodial relationship with their users,
especially if they use auto-update mechanisms. Unfortunately this has
potential legal
On Tue, Jan 20, 2015 at 12:23:14PM -0500, Matt Whitlock wrote:
On Tuesday, 20 January 2015, at 10:46 am, Peter Todd wrote:
I was talking to a lawyer with a background in finance law the other day
and we came to a somewhat worrying conclusion: authors of Bitcoin wallet
software probably have
On Tue, Jan 20, 2015 at 12:47:04PM -0500, Matt Whitlock wrote:
On Tuesday, 20 January 2015, at 6:44 pm, Tamas Blummer wrote:
Knowing the private key and owning the linked coins is not necessarily the
same in front of a court.
At least in german law there is a difference between
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 January 2015 12:09:13 GMT-07:00, Jeff Garzik jgar...@bitpay.com wrote:
Text formats such as XML or JSON are far less deterministic, are more
loosely specified, have wide variance in parsing, are not very
hash-able,
the list goes on.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
That's 100% true: BIP70 passes around serialized protobuf data that it signs
directly for this reason; it could just as easily be a byte array with json in
it. (not that json/XML/etc. doesn't have other flaws)
On 19 January 2015 13:03:32
On Fri, Jan 09, 2015 at 01:40:53PM +0200, Nathan Cook wrote:
Would you mind doing up some actual scriptPubKeys/transactions using
this idea as an example? I think it'd make the review process a lot
easier for everyone if there was something more concrete. (equally,
sorry I haven't had a chance to
On Sat, Jan 10, 2015 at 04:26:23AM +, Gregory Maxwell wrote:
The incompatibility is due to the OpenSSL update changing the
behavior of ECDSA validation to reject any signature which is
not encoded in a very rigid manner. This was a result of
OpenSSL's change for CVE-2014-8275 Certificate
On Sun, Jan 04, 2015 at 05:44:59PM +, Gregory Maxwell wrote:
On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
Can you send me the actual raw transaction (that site doesn't appear
have a way to get it, only some cooked json output; which doesn't
include the
TxOut Hashcash,
Peter Todd, May 10th 2013,
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02159.html
--
'peter'[:-1]@petertodd.org
08bb7f424d81b7a0ea568086f4d320c2867705f88c27bb0a
signature.asc
Description: Digital signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
A big one is the privacy is way too good: every DNS request goes through
multiple levels of caching and indirection, so there's no way to figure out who
made the request to subject them additional targeting.
A connection-oriented protocol gets
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29 December 2014 12:49:45 CET, Thomas Zander tho...@thomaszander.se wrote:
On Monday 29. December 2014 11.30.42 Mike Hearn wrote:
With the current DNS protocol you get an all or nothing choice
Its a seed. Not the protocol itself.
Firstly,
On Sun, Dec 21, 2014 at 07:49:17AM -0600, paul snow wrote:
On Dec 20, 2014 8:49 AM, Peter Todd p...@petertodd.org wrote:
However the converse is not possible: anti-replay cannot be used to
implement proof-of-publication. Knowing that no conflicting message exists
says nothing about who
On Sun, Dec 21, 2014 at 10:01:37AM +, Adam Back wrote:
On 20 December 2014 at 14:48, Peter Todd p...@petertodd.org 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 p...@petertodd.org wrote:
Right, so Freimarkets is deliberately insecure.
Please define your terms, particularly what your security requirements are
here. In the architecture we
On Sun, Dec 21, 2014 at 12:25:36PM +0100, Jorge Timón wrote:
So let's go through an example to see in which ways
non-proof-of-publication orders are insecure.
Alice the seller wants to sell 1 unit of A for 100 units of B.
Bob is willing to pay up to 200 Bs for 1 A.
Let's assume a proof of
On Sun, Dec 21, 2014 at 06:10:47PM +, Adam Back wrote:
Yes you could for example define a new rule that two signatures
(double-spend) authorises something - eg miners to take funds. (And
this would work with existing ECDSA addresses unrestricted R-value
choices).
I wasnt really making
On Sat, Dec 20, 2014 at 09:48:01AM -0500, Peter Todd wrote:
Andrew Miller asked me to publish the following to the mailing list on his
behalf: (https://twitter.com/socrates1024/status/546819355565391872)
One of the main points in this note is that you can use a
proof-of-publication system
.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 pricing and market depth,
Peter Todd, Feb 9th 2014,
http
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; nothing
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.sourceforge.net/msg03892.html
--
'peter'[:-1]@petertodd.org
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 demonstrated
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 new
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,
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
. Which some people now appear to be in a hurry to
discard :)
FWIW usually Satoshi's solution is described as a hack, sometimes as an
elegant hack.
Peter Todd might disagree with the wisdom of that :) He wrote an
excellent email to this list not long ago warning of the dangers of
centralisation
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 arguments;
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 4 December 2014 20:02:17 GMT+00:00, Jeffrey Paul j...@eeqj.com wrote:
On 20141204, at 07:42, Luke Dashjr l...@dashjr.org wrote:
Is anyone working on a serialisation format to convey P2SH HD chains?
For
example, to give someone who wants to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27 November 2014 18:46:23 GMT-05:00, Gregory Maxwell gmaxw...@gmail.com
wrote:
snip 100% accurate commentary from gmaxwell
The things you're suggesting were all carefully designed out of the
proposal, perhaps the BIP text needs some more
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 to
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.
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 mempool
On Thu, Nov 06, 2014 at 02:47:29AM -0800, Pieter Wuille wrote:
On Thu, Nov 6, 2014 at 2:38 AM, Peter Todd p...@petertodd.org wrote:
However the implementation of the STRICTENC flag simply makes pubkey
formats it doesn't recognize act as through the signature was invalid,
rather than failing
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 due
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 solving
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
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 to fix
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 (and not
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. For
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 subscribe
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 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 the
On Thu, Oct 09, 2014 at 06:28:19AM +, Gregory Maxwell wrote:
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back a...@cypherspace.org 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
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
of unittests for the
opcode semantics can be found at:
https://github.com/petertodd/bitcoin/compare/checklocktimeverify
pre
BIP:
Title: OP_CHECKLOCKTIMEVERIFY
Author: Peter Todd p...@petertodd.org
Status: Draft
Type: Standards Track
Created: 2014-10-01
/pre
==Abstract==
This BIP describes
-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 l...@dashjr.org 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 14:34:33 GMT-07:00, Gavin Andresen gavinandre...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner etothe...@gmail.com
wrote:
No, the burner would supply the funding transaction plus the redeeming
script as the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 08:01:28 GMT-07:00, Gavin Andresen gavinandre...@gmail.com
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
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 the
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 number, but obviously needing
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 to an
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();
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15 September 2014 17:10:14 BST, Gregory Maxwell gmaxw...@gmail.com 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
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
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
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
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 connections carry
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik jgar...@bitpay.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 20:21:35 GMT-04:00, Jeff Garzik jgar...@bitpay.com wrote:
On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd p...@petertodd.org wrote:
That is simply incorrect. The resources required to do that kind of
monitoring are very high; even
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 20:49:01 GMT-04:00, Justus Ranvier justusranv...@riseup.net
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 20:59:14 GMT-04:00, William Yager will.ya...@gmail.com
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,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 21:19:43 GMT-04:00, William Yager will.ya...@gmail.com
wrote:
On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd p...@petertodd.org wrote:
In any case, my suggestion of enabling hidden service support by
default
adds both encryption
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13 August 2014 11:00:22 GMT-07:00, Richard Moore m...@ricmoo.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
decker.christ...@gmail.com 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,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 09:31:24 GMT-07:00, Mark Friedenbach m...@monetize.io 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 10:21:56 GMT-07:00, Mark Friedenbach m...@monetize.io 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,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 10:30:11 GMT-07:00, Mark Friedenbach m...@monetize.io 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 that possibly
, Peter Todd,
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05211.html
signature.asc
Description: Digital signature
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your
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, would
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
An application presented with a fake blockchain can use
quite a few heuristics to test the 'validity
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.
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 append
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 resources.
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 know if we've
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
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 address
On Fri, Jun 06, 2014 at 02:03:29AM -0700, Gregory Maxwell wrote:
On Fri, Jun 6, 2014 at 1:48 AM, Adam Back a...@cypherspace.org 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
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 p...@petertodd.org 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)
scaling
On Fri, Jun 06, 2014 at 10:10:51AM -0700, Gregory Maxwell wrote:
On Fri, Jun 6, 2014 at 10:05 AM, Peter Todd p...@petertodd.org 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
corresponds at least one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27 May 2014 02:19:39 GMT+03:00, Andreas Schildbach andr...@schildbach.de
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
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
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.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 May 2014 17:09:07 CEST, Mike Hearn m...@plan99.net 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 May 2014 20:20:40 CEST, Justus Ranvier justusranv...@gmail.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 May 2014 20:43:15 CEST, Gregory Maxwell gmaxw...@gmail.com 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
On Fri, May 09, 2014 at 08:38:22PM +0200, Pieter Wuille wrote:
On Fri, May 9, 2014 at 8:13 PM, Peter Todd p...@petertodd.org 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 the
atomicity
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
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 this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The standard format ended up being exactly:
OP_RETURN 0 to 40-byte PUSHDATA
You've split the data across two PUSHDATA's. The standard should have let the
data be split up like that; pull requests accepted.
On 3 May 2014 13:04:52 GMT-05:00,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Huh? Your examples demonstrate the *opposite* of your point. 'k' and
'M' *are*
the SI prefixes. People *do* use 63k USD, $63k, and $3M.
Excellent point.
Also, I frequently hear statements referring to mili-bitcoins, mBTC, pronounced
as
Someone who wanted to remain anonymous sent me in this idea, which I'll
admit I'm kicking myself for not having thought of earlier. They sent
me this hash so they can claim credit for it later should they choose to
reveal their identity:
In the majority of high-value transactions the fact that funds will be
sent is known prior to when they actually are. For instance, if Alice is
to meet Bob in person to buy a car or sell some Bitcoins, both parties
know the transaction will probably happen in the near future some time
before it
On Sat, Apr 26, 2014 at 08:07:58PM +0200, Mike Hearn wrote:
What stops the buyer just always waiting to get their money back?
The seller won't hand over the goods of course until they have a valid
transaction signed by the buyer sending them the escrowed funds. (and
the nLockTime deadline is
On Fri, Apr 25, 2014 at 07:17:48PM +, Luke-Jr wrote:
I believe you meant to link here instead?
https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki
This looks reasonable from a brief skim over, but does not define any use
cases (it mentions necessary for atomic cross
On Fri, Apr 25, 2014 at 11:06:37PM +0300, Alex Mizrahi wrote:
It is also useful for betting: an oracle will associate a hash with each
possible outcome, and when outcome is know, it will reveal a corresponding
preimage which will unlock the transaction.
This approach has several advantages
On Fri, Apr 25, 2014 at 01:19:48PM -0700, Gregory Maxwell wrote:
On Fri, Apr 25, 2014 at 1:14 PM, Peter Todd p...@petertodd.org wrote:
Actually I did some work looking at this problem a few months ago and
other than somewhat larger transactions it looks like implementing
oracles by having
101 - 200 of 455 matches
Mail list logo
