Re: [Bitcoin-development] ECDH in the payment protocol

[Peter Todd]

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 originally proposed to me for the
design of what became stealth addresses.

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, and thus creates
opportunities for it to fail. Fortunately we already have the necessary
ephemeral keys in standard Bitcoin transactions in pay-to-pubkey-hash
and pay-to-script-hash spending scriptSigs so you don't need to
compromise on reliability in exchange for transaction size as you're
mistakingly assuming. You should re-read my original stealth address
discussion with Gregory Maxwell on IRC if this is unclear.

In any case it's a mistake to argue that some times of data in the
blockchain are "bloat" by virtue of whether or not they happen to be
executed in a script. Multisig addresses use an extra ~107 bytes of data
per signature per txout spend to make it less likely for the user to
lose their funds under certain conditions; op-return-using stealth
addresses use an extra ~50 bytes of data per txout spend to make the
user less likely to lose their funds and make their transactions more
private under certain conditions.(1) Ultimately the resource being used
is the same, making it silly to try to dictate the right trade-offs by
brushing certain solutions as anti-social "bloat" and others not based
on top-down edict; let the free market for fees do its job.


1) Note that the recent advancements in ECDH multi-party signing are
   limited in the cases they can cover; there still is a strong need for
   discrete key multisig, e.g. for Greenaddress.it

-- 
'peter'[:-1]@petertodd.org
3581a7e5d0e10205803803466240668215d178b216837386


signature.asc
Description: Digital signature
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] ECDH in the payment protocol

[Peter Todd]

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 design, which is why I'm now proposing it
> instead. I think you made the wrong design call, but at any rate, it's
> something reasonable people can disagree on.
> 
> Payment messages are sent directly to the merchant, who takes
> responsibility for broadcast. Once you delivered transactions to the
> merchant successfully, from your perspective the payment is made. A good
> store and forward network doesn't allow messages to go missing - email is
> an example of that (ignoring spam filters that explicitly want messages to
> go missing). It either gets delivered or it doesn't. So I'm not worried
> about atomicity.

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
both worlds.

I haven't yet specified that mode of operation in the current draft
stealth address standard, however I do plan on adding it. Notably the
standard is designed to allow exactly that feature to be added in a
backwards compatible way - senders who don't implement that feature, or
choose not to use it, simply fall back to op-return.

-- 
'peter'[:-1]@petertodd.org
4d25218420094fda0891fe1d734e1a8df581bd6de7f2d0cd


signature.asc
Description: Digital signature
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] ECDH in the payment protocol

[Peter Todd]

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
> > both worlds.
> 
> 
> Sounds great! How does a lightweight client identify such transactions
> without any markers?

The exact same way you're proposing: via the payment protocol.

If something goes wrong and a payment gets lost, that's where you
implement a last-ditch "scan for stealth payments" button or similar
that either just asks a semi-trusted server to scan the blockchain for
you, or accepts the bandwidth hit and does so itself. (note that the
scan pubkey used to find payments is unable to spend those payments)

-- 
'peter'[:-1]@petertodd.org
74d6fdc4442dae1b7273f77f2deec988daf63d3e1ec6eeea


signature.asc
Description: Digital signature
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] ECDH in the payment protocol

[Peter Todd]

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 what (otherwise you're
> already talking to them in some way, right?). That's perfect for
> things like anonymous donations.
> 
> In pretty much every other case, communicating directly with the
> receiver has benefits. Negotiation of the transaction details,
> messages associated with the transaction, refund information, no need
> to scan the blockchain for incoming transaction... and the ability to
> cancel if either party doesn't agree.
> 
> Instead of adding stealth functionality to the payment protocol as a
> last resort, I'd rather see the payment protocol improve its
> atomicity. Either you want the data channel sender->receiver, or you
> don't. If it isn't available and you want it, things should fail. If
> you don't want it, you shouldn't try to use it in the first place.

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 of payments on whether or not the payee decides to broadcast
the transaction the payor is stuck with txouts that they can't use until
the payee makes up their mind. That leads to lots and lots of nasty edge
cases.

OTOH if we base the atomicity of payment on whether or not a specific
txout exists everything those edge cases don't exist. Yes, that might
force us to expose transaction fees to the user, but after all it's the
user who has control over those fees.

A separate issue is IsStandard() rules, and a near-term project for me
is to write a much relaxed version of them based on soft-fork safe
whitelisting/blacklisting of opcodes, version numbers, mutability etc.
We can definitely get to the point where those rules will change very
little.

-- 
'peter'[:-1]@petertodd.org
6d5945d2dddece39487c36673e56a292b619b1929ff3b40f


signature.asc
Description: Digital signature
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] ECDH in the payment protocol

[Peter Todd]

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 the
> > atomicity of payments on whether or not the payee decides to broadcast
> > the transaction the payor is stuck with txouts that they can't use until
> > the payee makes up their mind. That leads to lots and lots of nasty edge
> > cases.
> 
> I haven't talked much about it except for on IRC, but my idea was this:
> * PaymentACK messages become signed (with the same key as the payment
> request, or using some delegation mechanism, so that the same key
> doesn't need to remain online).
> * Instead of a full Bitcoin transaction, a Payment message contains a
> scriptSig-less Bitcoin transaction + a limit on its byte size (and
> perhaps a limit on its sigop count).
> * The sender sends such a Payment to the receiver before actually
> signing the transaction (or at least, before revealing the signed
> form).
> * The receiver only ACKs if the transaction satisfies the request, is
> within time limits, isn't unlikely to confirm.
> * If the sender likes the ACK (the refund and memo fields are intact,
> the transaction isn't changed, the signature key is valid, ...), he
> either sends the full transaction (with receiver taking responsibility
> for broadcasting) or broadcasts it himself.
> 
> Together, this means that a paymentACK + a confirmed matching Bitcoin
> transaction can count as proof of payment. Both parties have a chance
> to disagree with the transaction, and are certain all communicated
> data (apart from transaction signatures) in both directions happened
> correctly before committing. It would completely remove the chance
> that the Bitcoin transaction gets broadcast without the receiver
> liking it (for legitimate or illegitimate reasons), or without the
> backchannel functioning correctly.
> 
> It's also compatible with doing multiple payments in one Bitcoin
> transaction - you can ask for ACKs from multiple parties before
> signing the transaction.
> 
> Of course, the sender can still withhold the signed transaction (in
> which case nothing happened, but we probably need a second timeout),
> or the receiver can always claim to have never received the
> transaction. The sender can broadcast the transaction himself in order
> to prevent that, after obtaining an ACK.

Yeah, with the receiver specifically signing off on the tx I think
that's fine. OTOH you still gotta ask if this process is really worth
it; do you really need this level of signing off for payments that are
only going to be considered fully valid after a confirmation? That's
always going to be the case for a large proportion of Bitcoin
transactions, and sticking to that model makes upgrades easier and
reduces the reasons why receivers would want to reimplement a bunch of
Bitcoin-related logic.

-- 
'peter'[:-1]@petertodd.org
7cf5744be694eea2f20501e6db9d3362428aabd63dda4151


signature.asc
Description: Digital signature
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] patents...

[Peter Todd]

-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 office as a revenue
>source,
>basically everything you can possibly imagine is covered by some
>ridiculous
>patent so if you go looking you will always find applicable patents on
>every idea and then you end up potentially much worse off.
>
>Most companies (Google certainly included) have therefore banned their
>staff from reading patents, thus ensuring that the whole point of them,
>the
>sharing of knowledge, doesn't actually function! And it's much better I
>think if we follow the same policy. So *please do not ever mention that
>suchandsuch is patented on this list*! When it comes to patent law,
>ignorance is bliss. Patents are written in a heavily obfuscated manner
>such
>that actually trying to learn from them is hard work anyway.

Meh. The world is much bigger than the USA. Secondly that rule makes it 
difficult to educate people about why patents are as bad as they are.

Feel free to continue censoring your own discussion within closed corporate 
environments. But to say keeping patent discussion off mailing lists is 
appropriate or wise when the tech news is full of such discussion is silly.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJTekz8MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhX0TB/wNZoi5sWj6n3fM7O7T
emVbrVpuBwOvUEJAFYGmXgb2KXGdheVRhXfcwteQybLG+M+Ra/HAqLq+1YrPmopE
QeldiSc31KAkVLYXQMIfD6QO1PBlvKP7qPLqBEpCc9ocd8XLppTPQ2K8o5soV8VF
z6Jt/Hh74xhkhhb/kEzsQ8YKkg+m26WY9Yggu0Qxtb0OTjL86IhEKpH9ijr08jvV
TKs+PHwou5rt0dT3vqLd8ogb7xihTPx/7tciaXHCOfvxGsEgtqdTsjdHlCJ6cR9a
DrZcrIQnX+s1+YbHs3P4kyBfzNHBwwVuwaf5W5pU6vFp276jhsgT/65J7PqoRmxK
AkXg
=dk4R
-END PGP SIGNATURE-


--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Paper Currency

[Peter Todd]

-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 not acceptable
>to propose anything at all.
>
>Maybe start with things like how the Bitcoin protocol will never be
>changed to allow for confiscation of funds, regardless of who might
>demand such a feature.

Might be worth looking into the recent RFC 7258: Pervasive Monitoring Is an 
Attack for some guidance on how to write such a social contract.

Re: Gavin, note the language in the foundation bylaws:

Section 2.2 The Corporation shall promote and protect both the decentralized, 
distributed and private nature of the Bitcoin distributed-digital currency and 
transaction system as well as individual choice, participation and financial 
privacy when using such systems.

You might want to do a pull-req to add fungibility and rejection of blacklists 
to that list; note Adam Back's comments on how fungibility and privacy are 
inherently linked.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJTek/ZMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhYPIB/9/mhDOei8uMGHmzK41
YdL2ezs4LMPLyCRbo9Eu7MDJAMBaMH4VUbomR0tJVPRS191ifa2F/xGYnbDvk/PG
rLX86uPPMBxZqnVMgZLeKJkUHm3Zlkm1Ti58bMR8VVQuPazBBpkYtsvk+0+8j9su
ke7Xq+OqUGOC03bM4bxtKyBCy1FrCJuFgZEywKhOjr6boANLctDRBZerPqQ4AcjP
tHSAAImcesMhjc/N9LJ4MeygszzblYpdsQeiw8jvvyZI7vCSHuKb+hur+kCszYjD
ygfY9QmoNye2yc0GLZd+kXSMwY6gLIvaAFhv2ElMTMiJ7btHtJJfyEaA9Ub4zEEY
JKeO
=DSjZ
-END PGP SIGNATURE-


--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] patents...

[Peter Todd]

-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 examiners are
>_guaranteed_ to consult when doing a prior art search, so it may have
>a fighting chance of precluding someone else patenting the same
>material later (they may also search the internet and use other
>resources, but they're guaranteed to consult the existing patents and
>applications).

Interesting. Is that to say a viable strategy would be to apply for patents and 
let the application lapse?
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJTelGCMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhQPlCACjJgJEyMYMtF+/dJJh
TgWfVuE7E7QmwgWoQMBo7/5LgO1W5PQt9d3jfQ7gkrdCqTWs4HtA3lcgjdeEQ6ZW
QvMFG5/xITVi85v2zlE9CteQZXLBTSI+J7VlkjqnJeftQkklvGjiDtNfaDDsTacV
ZNem06V4fmBxNgzqmit2Roilp+NMQb2iM9Ofkr5FbI0cT/kzD/IJd2+Crqsu/uDU
8r2YQY0bbEf2wqxVdq5TSf1rFqqnWKHB3lD1GGRJ8n5BciBmysZL43jct8YABSgi
BHFpJP2ii7gz076mRiBb+KwCo+1xKUYNpsJk1m7HND7PjqkXps+JHiNaWdr9vAxx
raFO
=L1oX
-END PGP SIGNATURE-


--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] PSA: Please sign your git commits

[Peter Todd]

-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 good.


On 22 May 2014 21:06:10 GMT+03:00, Jeff Garzik  wrote:
>Related:  Current multi-sig wallet technology being rolled out now,
>with 2FA and other fancy doodads, is now arguably more secure than my
>PGP keyring.  My PGP keyring is, to draw an analogy, a non-multisig
>wallet (set of keys), with all the associated theft/data
>destruction/backup risks.
>
>The more improvements I see in bitcoin wallets, the more antiquated my
>PGP keyring appears.  Zero concept of multisig.  The PGP keyring
>compromise process is rarely exercised.  2FA is lacking.  At least
>offline signing works well. Mostly.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJTfpWNMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfVGB/448B6UvhN7bmFQxmLS
9+wlhWGYioJKUPspz2Wtk0p8v1y1XlDt0UxC+5ODin4a/Zk0+0x4G4MWyaUP1TnA
Wq9FquY3MwTXDrwWzmeQR4QcRbC+EMMk6kXswzT4d/2clUwB1pLl2MYGnS9DjUK2
of0kzZEbaQvxSKcFmvuqhz0QqGy84pkHAFBHfopS1j4WqIZpelUMzBGRYP8D1IQd
H/M2YxdQ7T8peiNigqWSyllchKqGoLG+KEr3mvTYRLkxoYw5XTcFyc5AmuTRfzEC
yhRc7CJwTZjHYahgZRPGJQM0qeopdIVAifCu9NoPgdkyuQL+X8XSidrU5Kbv/YeZ
Scv/
=GdA4
-END PGP SIGNATURE-


--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again

[Peter Todd]

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. If for some reason you really do need instant startup, run
your own centralized high-availability/low-latency nodes; either way
you're depending on a centralized resource.

1) https://github.com/bitcoin/bitcoin/pull/4203

-- 
'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again

[Peter Todd]

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.bitcoin.petertodd.org: SERVFAIL
> 
> Like I said, can you look at the logfiles how the requests arrive?

There are no logfiles for DNS requests.

I just checked on EC2 and my cellphone internet connection here in Tel
Aviv; both work fine. My best guess is that your DNS resolver locally or
at your ISP is unable to deal with the fact that the second DNS seed
serving the domain testnet-seed.bitcoin.petertodd.org happens to be down
right now. Note that some ISP's appear to both run buggy DNS servers,
and redirect traffic meant to go to Google's 8.8.8 and 8.8.4.4 DNS
servers to their own servers.

I'd suggest that someone setup an alternate HTTP(S) based DNS seed for
protocol redundency.

> What particular thing did you fix? It would be good to know for future
> outages.

Dunno exactly. It appeared to be running fine when I logged into the
machine, but for whatever reason DNS requests just weren't getting
resolved. Restarted and it was ok again.

-- 
'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
--
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again

[Peter Todd]

-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 last time it didn't work, the bug -- non RFC-conformance -- was on
>the bitcoin seeders side. ISPs do weird things with DNS, but usually
>they stay within the RFC.
>
>Anyway, without logs we don't have a chance to debug this issue. Any
>chance you could add simple logging to the seeder?
>
>DNS via HTTP? Never heard of that, at least it sounds weird as well.

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.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJTg8K6MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhUWgCADCNe4CjWondwDCovkv
+Cq7Yl3gLixvsTt5L9nllYc63/wt3GYliSIkR9baJ1QdPhckEjsvJV51XtdXPmJ5
EwTEbkJe6gflVwprvXB+w7eJtwMgZy5UoaWIYIZAIGsGKtJA8sngU1t638ywm68a
UEAcq/xACU47l2wPK/WU3uPY8ctGutCtXW2XDlDlCZOugqSc/8yaA76S5ogBicXw
xXvf95uMPVPCqit6B8FHCG/DH7akKGcnv6lIBTfx25KjgpyMwaroPt6EkPuz96MK
YbkQin0T0iW+X5WvXblO1mgq4fDrLE6J5x8sULFx/QKC9lgGB+cOQNKdyhxKOzF9
jtX7
=SUP4
-END PGP SIGNATURE-


--
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again

[Peter Todd]

-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 already volunteering. At least I don't get paid for my efforts in
>debugging the seed infrastructure.

I meant running a seed yourself. Note that I've only received funds to cover 
expenses and a trivial amount on top to cover some time - about one and a half 
hours at my usual rates.

Gavin: Speaking of, given it looks like my work will be frequently keeping me 
out of country and unable to provide any more than a "best effort" attempt at 
running a seed, I'd like to give back the grant funds for doing so. Email me 
privately with an address to send them too. I have no plans to take it down, 
however the expectations users have for it aren't something I can provide.

>Can you verify if your copy of the seeder contains the commit
>8dcc006e6256cb746c2b025daf3df41baa26353e ?
>
>It fixed a bug that has exactly the symptoms we currently see.
>
>I wonder if the restart of your server actually changed/fixed
>anything. If you got a SERVFAIL this may be because you were traveling
>through parts of the world that can't reach your server. Did you
>actually try at home, before the restart?

I checked via the same proxy both times; I believe the endpoint is located in 
Europe.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJTiFKwMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhQFCB/4jypD+xzKVp6fqRUxu
v22Rc6PeCbeaPYKmdNu0LbY1G5spB8C8ooaZX6z0Ib/CYobzDPJ+rJNB+c1Fna4N
1IdH7ZsrX0GFaEn7Grnp7D2rtOXGZV+1XGFAateIA/caQ9+rJfqkHLuvOI0Fh+Ua
/m857rxUNtA1kObLFS7gfhi2gwXGO6KQ3muS3462hXVVc9j7DhOWQQwJba5PL+Je
Eob4WtnF2gVFlCEWevxvflF7j4lW9I/S81yZQDnNW9ATF2mfZVqo26sB0yL6Tm4l
KgdKx7+w3khv6QfW9Ilx0Ov3Ml2ZMRhBimpbnENbW4jfklsuRQcM0yx6vXS/lIMz
LO5s
=Up3N
-END PGP SIGNATURE-


--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Timelock: time-release encryption incentivised by Bitcoins

[Peter Todd]

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 today, while others are forced to compute it serially,
constrained by the lack of scalar performance growth.

The chains are constructed such that Bitcoin addresses can be derived
from them and bounties placed, incentivizing third-parties to crack the
timelocks. This gives us a valuable chance to incentivize others to push
the envelope of scalar performance - important knowledge if we are going
to have any hope of knowing how soon our timelocked secrets will
actually be revealed! The Bitcoin secret keys and addresses are
constructed from the chains as follows:

iv ->  -> privkey -> pubkey -> secret -> hashed_secret

secret= SHA256(pubkey)
hashed_secret = RIPEMD160(secret)

Unlocking a given chain starting from the initialization vector gives
the person doing the work the private key, giving them an exclusive
opportunity to collect the bounty. Collecting that bounty forces them to
reveal the pubkey, from which the secret is derived. The hashed_secret
is then just a standard Bitcoin address, letting everyone see how large
the bounty is for unlocking the timelock.

Only a single algorithm - SHA256 - is supported by design: timelock
encryption works best if we're all on an even playing field.

Sourcecode: https://github.com/petertodd/timelock

Credit goes to Amir Taaki for helping develop the idea.


To make things interesting I've made a ~256 hour timelock with 32
chains, 8 hours per chain. The addresses associated are as follows:

1ERvMr5J8FETF7zj4QM98u8ZANaL1o9XGZ
18h7LwKpd9c6u8zJka3vMCASa8BfbiZFd4
1DBJDp57QmbigLEbUsFeqJT3mkArGzH3gv
1C1d6Tj7mZADurfj5yJ64p5BeRstquk7pu
1FsH58jnq5Kc6D7hb7vmUhjh8fwnijiWss
1PDwPYStrrkKpGtV2zX71XCDYL3E2g3KM7
1BF6oYLeTG7WxNWJjC8p4SHz62q7vgZhXX
1DxFiHr9ehVvi8JR2Cc5pcD4DEURUeFFda
1NKg3buX5BzhYgSY6Yvws9kMqZ6F1xnneD
1Kptov9sgDqQcavz1rVsuQvfi8PcQcL4rc
1P9k1HEfe3Z8LaiFejqsuDLjWXPZk1coDL
1Mw25mU89Wp2b9zyMCSnjAVQ7x4AVWx3sf
1B8gdbd1StpVnV99Few1ae1XXfKH6iry1D
13bisx8T42CzmFA2oAm1evEytcijrHJ2iR
1DyR6aNSbrJCzwqdeo9UN5obGR9L73Y2sa
1Fx7j3gU3q7bQdoni2zZhGQx7BnLt8xNeK
19q541m17opVcAxwisem7ak7YPuSpdS3Uj
1DYWzBpLBDd7fpta2JYLf7QZ7nAYiZiamR
13sZYBMdyzffwvCkzhGTu49pCGGR5C5B9v
1DFSjViJLTNhNj5wvsqRwoqPyR9UTAzLgW
13Zi9eawpkzZwRC8RgHJausQmUS4ECBzho
1BCQ5GVkAEzNYZ5WroAwXSspgpYfhQrojd
1K1gbE7qGLwbJDEoRyrCGxCsgJ4mHcFKwP
14Z4EawE1Kd3HRut43vWjgYUWYR3ZV5i2p
1NZTFVXVzKXvPMsFKZfkhZCBcbzqm7cGCj
1GFBBahQC5DzpLuJc6X1yVvvSKP2kCpUGf
184PkQFdzhPR3TjoCxddsNK7sr3DVVhJ45
14SLK5fXWdajoQZ2AX5WmAGbvRtLpdTgMq
1LagrzYykb8w4NveKrw2SDcpKMezwxX72Z
16XdtV2U3ksdhKkByRpiq3VN61aB62Ndgh
1Mu1SaUBu7aV4DHzEc4hxcgGzaYWdvuaAh
1EJWWxwZckP9eLS2VzgbUwqzxFDZKZcF9b

I've funded them with 10mBTC each, 320mBTC total. The full timelock
definition is as follows:

{
"chains": [
{
"algorithm": "sha256", 
"encrypted_iv": null, 
"hashed_secret": "1ERvMr5J8FETF7zj4QM98u8ZANaL1o9XGZ", 
"i": 0, 
"iv": 
"353b124909ec8774325d3f2f6b0a01c839e79e3ce687ee6e893310368afdf336", 
"midstate": null, 
"n": 864, 
"seckey": null, 
"secret": null
}, 
{
"algorithm": "sha256", 
"encrypted_iv": 
"495c6092c9004dc23c2deefb1db1deba88f8895a319f5d9f7ce8a53b2a9ecfe9", 
"hashed_secret": "18h7LwKpd9c6u8zJka3vMCASa8BfbiZFd4", 
"i": 0, 
"iv": null, 
"midstate": null, 
"n": 864, 
"seckey": null, 
"secret": null
}, 
{
"algorithm": "sha256", 
"encrypted_iv": 
"8cbdf731374a71f22d59251890997ea001c2efa6e9c0bf808700c3d432ccf269", 
"hashed_secret": "1DBJDp57QmbigLEbUsFeqJT3mkArGzH3gv", 
"i": 0, 
"iv": null, 
"midstate": null, 
"n": 864, 
"seckey": null, 
"secret": null
}, 
{
"algorithm": "sha256", 
"encrypted_iv": 
"bc4d75fa5ec8f28e121cd73806ce058e82036577130cffb3bd596f2aa59b2a7f", 
"hashed_secret": "1C1d6Tj7mZADurfj5yJ64p5BeRstquk7pu", 
"i": 0, 
"iv": null, 
"midstate": null, 
"n": 864, 
"seckey": null, 
"secret": null
}, 
{
"algorithm": "sha256", 
"encrypted_iv": 
"80c622521c7aed318dac2b3c7d929e4e504d3c60650009b1abc0bae18fff979b", 
"hashed_secret": "1FsH58jnq5Kc6D7hb7vmUhjh8fwnijiWss", 
"i": 0, 
"iv": null, 
"midstate": null, 
"n": 864, 
"seckey": null, 
"secret": null
}, 
{
"algorithm": "sha256", 
   

[Bitcoin-development] NODE_BLOOM service bit

[Peter Todd]

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 version number is also bumped. Recommended behavior for nodes
that do not support bloom is to simply disconnect peers who send a
filter* message anyway to let them quickly find another peer.

Rational: Bloom filters are not always supported or appropriate. For
instance no node implementation other than Bitcoin Core supports them,
e.g btcd and obelisk. (which ironically implement this BIP already,
modulo the version number bump) In the long term bloom filters will be
obsoleted eventually as they have poor scaling properties - problematic
with blocksize increases - and are incompatible with UTXO/TXO
commitments, which will use prefix-based filtering instead. (already
being implemented in electrum and obelisk)

In the short term bloom filters have high IO loads, which have lead to
DoS attacks, and are not an optimal use of resources for nodes which are
IO constrained rather than bandwidth constrained. (common in VPS setups
which could better help the network by serving full blocks)

Adding NODE_BLOOM as a service bit now will save us some hassle later
down the road, reflects what actual implementations do anyway, has been
already deployed on Litecoin, Dogecoin, and a zillion other alts with no
issues, (including SPV client support) and is a trivial patch.


Gregory Maxwell: Please assign a BIP #

-- 
'peter'[:-1]@petertodd.org
49066dab2483c9e069656239f5782da204bd4995bd92c19f


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] NODE_BLOOM service bit

[Peter Todd]

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 proposed use of
> prefixes.

That's assuming you're doing the proposed prefix brute forcing - if you
don't do that they have privacy equal or better than bloom filters, but
with better scalability. In particular that better scalability lets you
efficiently query multiple servers for blockchain data, only giving up
info on a subset of the addresses in your wallet to each server. This
can be a significant improvement to bloom filters if your attacker is
running logging nodes to try to, say, deanonymize CoinJoin transactions.

> All for scalability, efficiency and decentralization but not ideally at the
> expense of nuking privacy.  The effects on privacy are cumulative, and
> affect everyone not just the user.  Same pattern of local decision, global
> effect as with reused addresses.

Indeed. But again, remember that the existing systems suck too;
prefix-brute forcing is a engineering tradeoff implementable with
existing and well understood technology.

Now if you want to come up with something better and write code, please
do! I'm sure the math exists; what doesn't exist is robust and well
tested code in multiple languages. Stealth addresses at least have been
designed so that future blockchain filter upgrades can be added in a
backwards compatible way.

-- 
'peter'[:-1]@petertodd.org
3a68ee16d702ca5dd5547fb4aead910a004747cb06241dd6


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] NODE_BLOOM service bit

[Peter Todd]

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 privacy tradeoffs in my opinion.
> > Same problem as with stealth address proposed use of prefixes.
> >
> > All for scalability, efficiency and decentralization but not ideally at the
> > expense of nuking privacy.  The effects on privacy are cumulative, and
> > affect everyone not just the user.  Same pattern of local decision, global
> > effect as with reused addresses.
> 
> The performance Bytecoin/Monero/Fantom/etc. systems that use ECDH
> addresses for all transactions seem to be suggesting that the prefixes
> aren't really needed.
> 
> At least with current system rules doing the ECDH for each transaction
> seems pretty reasonable.

Yup. Obelisk's indexing is sufficiently fast that they hadn't even
bothered making Dark Wallet store transaction information between
sessions until recently. Prefix brute-forcing isn't yet implemented,
although prefix filters is being implemented for lookups in general. (at
the very least it gives the server operators some valuable plausible
deniability)

-- 
'peter'[:-1]@petertodd.org
3a68ee16d702ca5dd5547fb4aead910a004747cb06241dd6


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bloom bait

[Peter Todd]

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 explicit prefix, it saves a byte or so at the expense of average 128
> EDH exchanges to send and provides also some probably relatively ineffective
> plausible deniability by enabling the transaction to be indistinguishable
> from some other (not very common) types of transaction.

I think you should re-read my original proposal; there's a whole host of
misunderstandings above, for instance I have no idea where you got the
idea that it has anything to do with "saving a byte" came from, or where
the number 128 came from.

> >don't do that they have privacy equal or better than bloom filters, but
> >with better scalability.
> 
> either its full node only where prefixes are not used, which is less
> scalable than bloom; or prefixes are used explicitly or implicitly
> (brute-force) and either way privacy is weakened by the extra correlation
> hook provided by elimination from the network graph of payments with
> mismatched prefixes.

Again, you have a misunderstanding. Both bloom filters and prefix
filters are just ways of giving a peer a probabalistic filter to match
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 with slightly(1) higher k. Again, if you *don't* use brute forcing
in conjunction with prefixes they have no different transactional graph
privacy than bloom filters, but the better scalability lets you do
things like split your queries across multiple peers that give you
better protection against hostile nodes.  Additionally prefix filters
are compatible with future miner committed indexes to make the data
authenticated.

1) see Amir's experience implementing prefix lookup in Obelisk

> We need to consider the two types of privacy involved.  Privacy from the
> full node an SPV client is relying on to find its payments, vs privacy from
> analysis of the public transaction graph.

Agreed

> The latter is more damaging.

Maybe! If adversaries are operating a significant fraction of the peers
you are connecting to the current design of bloom filters + HD wallets
results in situations where those adversaries have better transactional
graph information than the alternative.

> Better to design for privacy against future analysis of
> public info, than
> privacy by argument to select non-hostile nodes.  Tor has changed recently
> to account for the fact that chosing fresh random nodes is actually
> worse. ie you have a probability of identity/address identification
> per route/node,
> and repeatedly selecting routes/nodes just cumulatively increases the chance
> you'll be identified.  Better to pick a random node, identify it and stick
> to it and hope you chose well.

That's basically what Electrum and Obelisk already do - by default you
connect to a relatively small set of blockchain data servers operated by
well known people and use the same server repeatedly.

Applying that to the P2P network however is tricky as there is a huge
amount of churn in the nodes:

#bitcoin-dev/14/06/14-06-06.log:11:18 < hearn> bitcoinj can't use
[service bits] as it relies on DNS seeds and that is unlikely to change
any time soon due to the general churn rate in the network making it
hard to bootstrap quickly using just remembered sets of IPs.

> Maybe other simpler, but yes there was the proof of concept that the math
> exists in the form of the weil pairing.
> 
> https://bitcointalk.org/index.php?topic=431756.new

I know, where can I find running code? Remember that a bug can easily
lose thousands of dollars worth of Bitcoins.

-- 
'peter'[:-1]@petertodd.org
1d2af1653c415b7801ce4c9b18ac7e87bef597e652b203e6


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bloom bait

[Peter Todd]

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)
> > scaling with slightly(1) higher k. Again, if you *don't* use brute forcing
> > in conjunction with prefixes they have no different transactional graph
> > privacy than bloom filters,
> 
> Huh? How are you thinking that something that gets put in transactions
> and burned forever into the blockchain that lets you (statically) link
> txout ownership is "no different" from something which is shared
> directly with a couple peers, potentially peers you trust and which
> are run by yourself or your organization?

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 address in your wallet with some false positive
rate. I explained all this in detail in my original blockchain data
privacy writeup months ago.

-- 
'peter'[:-1]@petertodd.org
29d945c3832c7f4afabce11e6cb1c27b6f5e8c0f2bbb356c


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bloom bait

[Peter Todd]

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
> > corresponds at least one address in your wallet with some false positive
> > rate. I explained all this in detail in my original blockchain data
> > privacy writeup months ago.
> 
> I'm not trying to pick nits about all the options,  I just found it
> surprising that you were saying that data published in a super public
> manner is no different than something used between nodes.

Because I was designing a system under the assumption that you were
highly likely to connect to an attacker at some point, and the trade-off
available with the available math was to either give very detailed info
to that attacker, or give away some probabalistic info to everyone.

> > I explained all this in detail in my original blockchain data privacy 
> > writeup months ago.
> 
> Communication is a two way street, Adam and I (and others) are
> earnestly trying— that we're not following your arguments may be a
> suggestion that they need to be communicated somewhat differently.

Quite likely - I think most of this disagreement stems from the fact
that we have different starting assumptions. In particular my assumption
that you are likely to end up connecting to an attacker logging data,
and my desire to have a standard that can be implemented with existing
cryptographic primatives. Remember that I'm spending a lot of time
working with wallet authors; they have approximately zero interest in
standards that require crypto any more fancy than HD wallets do.

> I'm still failing to see the usefulness of having any prefix filtering
> for DH-private outputs. It really complicates the security story— in
> particular you don't know _now_ what activities will turn your prior
> information leaks into compromising ones retrospectivelly, and doesn't
> seem at very necessary for scanning performance.

Scanning performance is different from bandwidth performance. Prefix
brute-forcing was designed to address the latter concern for cases where
you are bandwidth limited and don't have a trusted peer to do the
scanning for you.

-- 
'peter'[:-1]@petertodd.org
1c5e0fca7bd6d96211a37543c1d0cc2f594c15423ee3cdd8


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bloom bait

[Peter Todd]

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) cost per query, so sending different bloom filters to
different peers for privacy reasons costs the network significant disk
IO resources. If I were to actually implement it it'd look like a DoS
attack on the network.

Essentially with bloom filters you have to make a tradeoff between
scalability and privacy; with prefix filters you don't have to make that
ugly tradeoff. Notably that tradeoff gets worse if we ever increase the
Bitcoin blocksize.

-- 
'peter'[:-1]@petertodd.org
3afb1fdf0867fc063775e69f9ae79870bb8727f25b49e88f


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bloom bait

[Peter Todd]

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 gone down this path before, but it would
> seem that the more different bloom filters you create, the more
> information you give away.  It would be most useful to create a single
> bloom filter that captures every address you ever intend to use (say a
> look ahead of 1000 addresses), and then only ever communicate that. 
> Once people see multiple filters that you produce, they can start
> looking at the intersection of them to reduce the identity space.  I
> would expect that after enough bloom variants, they could figure out a
> perfect subset of blockchain addresses in your wallet.  (I suppose you
> could intentionally select an extra 20% addresses to include in every
> bloom filter, but it's a hack).
> 
> Similarly, if you keep updating your bloom filter to include more
> addresses, the difference in what passes through the previous one and
> the new one gives away information about new addresses you created.

You're completely correct. You can use the same nTweak value for each
filter and then slice up the filters bitwise, but then you end up
linking every query you make to your identity unless you just used a
fixed nTweak that everyone else uses.  (e.g. zero) If you do that, you
still have the problem that you're greatly increasing the load on the
network.

In any case, all this shows is that in the future bloom filters will
very likely go away eventually, and to make that upgrade path smooth it
only makes sense to define a way for nodes to let others know whether or
not bloom is supported. A NODE_BLOOM service bit is a very reasonable
and simple way to do exactly that, and is defacto what implementations
that don't support bloom filters do anyway.

Note BTW that re: DNS seeds, once the NODE_BLOOM BIP is accepted and the
NODE_BLOOM patch merged into bitcoind, I'll write a patch for sipa's
seeder to make it only return seeds with bloom filter support.

-- 
'peter'[:-1]@petertodd.org
3afb1fdf0867fc063775e69f9ae79870bb8727f25b49e88f


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bloom bait

[Peter Todd]

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. If I were to actually implement it it'd look like a DoS
> > attack on the network.
> >
> 
> DoS attack? Nice try.

Suppose I wrote an single address lookup tool for Android that connected
to multiple peers and used bloom filters to find the history of a
specific address. Of course, I don't want to use too much bandwidth
being on mobile, so I'll use as specific a bloom filter as possible. I
might even connect to multiple peers to speed up the lookup.

Is this any different from my bloom filter IO attack code? Nope. Hence,
splitting up bloom filter requests for better privacy will certainly
look like a DoS attack and will certainly greatly increase the load on
the network.


> Now consider a prefix filtering implementation. You need to calculate a
> sorted list of all the data elements and tx hashes in the block, that maps
> to the location in the block where the tx data can be found. These
> per-block indexes take up extra disk space and, realistically, would likely
> be implemented using LevelDB as that's a tool which is designed for
> creating and using these kinds of tables, so then you're both loading the
> block data itself (blocks are sized about right currently to always fit in
> the default kernel readahead window) AND also seeking through the indexes,
> and building them too. A smart implementation might try and pack the index
> next to each block so it's possible to load both at once with a single
> seek, but that would probably be more work, as it'd force building of the
> index to be synchronous with saving the block to disk thus slowing down
> block relay. In contrast a LevelDB based index would do the bulk of the
> index-building work on a separate core.

That's exactly the kinds of optimizations obelisk is implementing to
make its prefix lookup database fast. Also those optimizations are
situation dependent, for instance "packing the index next to each block"
is irrelevant if you put archival blockchain data on a slow HD, and
indexes on a fast SSD, something some obelisk servers do.

More to the point, your showing quite clearly there isn't just one
optimal way to do it. Applying a bloom filter, or a prefix filter, or
some as yet unknown filter, to blockchain data is a service and that
service has different tradeoffs compared to just serving up archival
block history. There is zero reason not to make that service something
you advertise with NODE_BLOOM - after all, you already have the code in
bitcoinj to do the exact same thing by checking the advertised protocol
version.


On Tue, Jun 10, 2014 at 09:02:00AM -0400, Jeff Garzik wrote:
> Most of this description of disk activity is true, but it omits one
> key point:  Total cached data (working set).  It is a binary, first
> order question:  are you hitting pagecache, or the disk?  When nodes
> act as archival data sources, the pagecache pressure is immense.  When
> nodes just primarily serve recent blocks, that data is being served
> out of pagecache. As I directly observed running public nodes, the
> disks were running constantly, impacting all clients, even clients
> downloading only recent blocks.
> 
> Luckily, headers are served out of RAM, so that part of the sync is always 
> fast.
> 
> NODE_BLOOM -- and block download in general -- will tend to be slower
> than it could be, due to the working set almost always being larger
> than available pagecache.  Fix that problem, NODE_BLOOM will always
> operate out of pagecache, and disk activity will not be an issue.
> 
> Once you start hitting the disk, you've already lost.

Yup. I discussed this with Matt Corallo at the financial crypto
conference a few months back and he made the same point. Unfortunately
we'll need an upgrade to let nodes advertise ranges of blocks to begin
to fix that issue, and even then it still shows quite clearly how it's
not optimal if we force everyone to share blockchain data in the same
way.

-- 
'peter'[:-1]@petertodd.org
23c7fc084ed84b891cc2fa90e4a34708d6b2370d3ec1c85d


signature.asc
Description: Digital signature
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees

[Peter Todd]

On Mon, Jun 16, 2014 at 01:37:52PM -0700, Daniel Rice wrote:
> True, that would work, but still how are you going to bootstrap the trust?
> TREZOR is well known, but in a future where there could be 100 different
> companies trying to release a similar product to TREZOR it seems like one
> company could corner the market by being the only one that is an accepted
> instant provider at most vendors. It seems to encourage monopoly unless
> there is a standard way to bootstrap trust in your signature.

You can always use fidelity bonds, or as I called it at the time(1),
"Trusted identities":

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 A, for instance for the purpose of having other
users trust her not to attempt to double spend. Since the trust she
seeks is financial in nature, she can do this by valuing the identity
associated with A, by delibrately throwing away resources. A simple way
to do this would of course be to transfer coins to a null address,
provably incurring a cost to her.

A more socially responsible way would be for her to create a series of
transactions that happen to have large, and equal, transaction fees.
Bitcoin makes the assumption that no one entity controls more than 50%
of the network, so if she makes n of these transactions consecutively,
each spending m BTC to transaction fees, there is a high probability
that she has given up at least n/2 * m BTC of value. This of course is
all public knowledge, recorded in the block chain. It also increases the
transaction fees for miners, which will be very important for the
network in the future.

Now Bob can easily examine the block chain, and upon verifying Alice's
trust purchase, can decide to accept a zero-confirmation transaction at
face value. If Alice breaks that promise, he simply publishes her signed
transaction proving that Alice is a fraudster, and future Bob's will
distrust Alice's trusted identity, thus destroying the value needed to
create it.

In effect, we now have a distributed green address system.

Note that the second paragraph is seriously obsolete - better to either
use announce-commit sacrifices, or much preferably, 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 first post to this mailing list!

-- 
'peter'[:-1]@petertodd.org
58ca7ee3a40438ea5a96e499910638352468c6d69abdb226


signature.asc
Description: Digital signature
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Proposal: allocate 8 service bits for experimental use

[Peter Todd]

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 24-31 for temporary experiments
NODE_REPLACE_BY_FEE = (1 << 26)

Service bits are never a guaranteed thing anyway, so occasional
collisions can and should be tolerated by applications using these
experimental service bits.


Alternately Wladimir J. van der Laan brought up elsewhere(2) the
possibility for a wider notion of an extension namespace. I'm personally
not convinced of the short-term need - we've got 64 service bits yet
NODE_BLOOM is the first fully fleshed out proposal to use one - but it's
worth thinking about for the long term.

1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1
2) https://github.com/bitcoin/bitcoin/pull/4351#issuecomment-46272958

-- 
'peter'[:-1]@petertodd.org
58ca7ee3a40438ea5a96e499910638352468c6d69abdb226


signature.asc
Description: Digital signature
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: relax the IsStandard rules for P2SH transactions

[Peter Todd]

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
protections to ensure forwards compatibility during soft-fork upgrades
and provide protections against transaction malleability.

> Now that we are finally starting to see the use of multi-signature and
> other more complicated transaction forms in applications I think it is time
> to open up the "IsStandard" transaction rules on the main Bitcoin network.

Agreed.

> There are two main risks to doing this:
> 
> 1. The risk that one of the seldom-used opcodes has a not-yet-discovered
> chain-forking bug. I believe that risk to be very low; we have never seen
> such a bug on the test network (where all transaction forms are allowed)
> and have never found a bug after writing extensive unit tests.

Agreed.

The script execution code is probably in the 99.9th percentile of open
source code in terms of code review.

> 2. The risk of opening up a denial-of-service attack (either bloat the
> blockchain or use an excessive amount of CPU time) via a very
> expensive-to-store-or-verify transaction. This proposal does not entirely
> eliminate IsStandard checks to mitigate the potential for DoS attacks.

3. The risk that non-upgraded miners produce invalid blocks after a
   soft-fork due to them mining transactions that are now invalid.

4. Transaction malleability.

> Proposal
> 
> Allow any Script containing 15 or fewer signature operations as a
> pay-to-script-hash (P2SH) Script to be relayed and mined by the reference
> implementation.
> 
> This should be a simple change to the AreInputsStandard() method in the
> reference implementation.

In addition to these changes the soft-fork-safe patch I'm working on
would do the following:

a) Define an opcode whitelist of soft-fork-safe opcodes.

This whitelist includes every opcode but the invalid opcodes, and most
importantly, the OP_NOPx opcodes that may be redefined in a future
soft-fork with new behavior. This rule, along with rejecting transations
with unknown nVersion's, ensures that a miner still running an old
version of Bitcoin Core will only mine transactions that the new version
of Bitcoin Core considers valid.

b) Consider scripts that leave extra items on the stack after execution
   to be non-standard.

As per Pieter Wuille's BIP62 "Dealing with malleability" extra scriptSig
pushes are a malleability source. If adding extra pushes causes a
transaction to be invalid, scriptPubKeys will in most cases be
automatically non-malleable. This change I've already submitted as a
separate pull-req: https://github.com/bitcoin/bitcoin/pull/4311


I'd be happy to add the above to your existing patch and submit the
pull-req for you.

-- 
'peter'[:-1]@petertodd.org
407e409a626b01bfb275cb88768ca74f3ea9bd87b2e7e1d9


signature.asc
Description: Digital signature
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: relax the IsStandard rules for P2SH transactions

[Peter Todd]

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 necessarily a good idea. The
malleability protection definitely seems like a good idea, and has had
quite a bit of review.

> RE: not relaying/mining transactions with OP_NOPs so miners don't mine
> up-version transactions that are invalid under future-new-rules: I'm not
> convinced it is worth adding more code (more potential for bugs) to protect
> against something that isn't going to happen because up-version
> transactions are non-standard (due to version check) in any case.

Do we have consensus that future soft-forks to add new opcodes will
always be done in conjunction with a transaction nVersion bump? If so,
then that's ok, if not, then we should have a whitelist.

The code to restrict the opcodes to the softfork-safe subset is trivial,
a GetOp() loop and a switch statement. It can always be removed later.

Something that comes to mind is if we do always bump nVersion then
OP_NOPx always will have a parallel "do-nothing" behavior, which means
EvalScript() will always have to have code enabling that backwards
compatible behavior.

-- 
'peter'[:-1]@petertodd.org
04e51d8d00eedb31ec1505d245f48960896b79f0e7193c2a


signature.asc
Description: Digital signature
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: relax the IsStandard rules for P2SH transactions

[Peter Todd]

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 EvalScript() into a mess over time, but that's
a long way away. Anyway a BIP will be useful.

> RE: malleability:
> 
> Orthogonal (but related) issue to IsStandard.
> 
> Detecting Scripts that leave extra items on the stack will be done in a
> different part of the code than the code addressed by this pull reques. No
> need to execute the Script twice to figure out if it leaves extra stuff,
> and the idea behind IsStandard is to get to a quick yes/no before running a
> potentially expensive Script execution.

Yeah, that's what I implemented in https://github.com/bitcoin/bitcoin/pull/4311

-- 
'peter'[:-1]@petertodd.org
4f73d48c972aa30493526191aa009f95e4a71dcfbdca08b2


signature.asc
Description: Digital signature
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin address TTL & key expiration?

[Peter Todd]

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 "don't ["permit"|confirm] after X [time|block]"  to
> the address I suppose.  The metadata would not be digitally signed,
> but it would be hash-sealed.  As "address" is a client-side notion,
> wallet clients would be the ones enforcing such a rule.

Note that "digitally signed" has no value here without some kind of
PKI/WoT/something else to know what key is doing the signing. I believe
Jeff is really referring to the checksum by "hash-sealed" here, which is
as good as is worth getting.

> Bitcoin protocol of course knows about keys, and key expiration is a
> well known and useful concept in public key cryptography.  The best
> insertion point in the protocol for key expiration is an open
> question, if it's even a good idea at that level at all.  Some flag
> "no more TxOuts exactly like this [after X block?]"?
> 
> I readily admit I don't have good answers, but it does seem valuable IMO to
> * Prevent users from accidentally sending to an "expired" TxOut/pkh.
> This happens in the field.
> * Discourage address reuse
> * Enable sites that generate lots of keys to rotate ancient keys off
> their core systems.  (HD wallets mitigate this)

A few months ago I looked into what low-level details it'd take to add
Bitcoin addresses to OpenPGP keys a few months ago; one of the
requirements we came up with was to make sure the standard OpenPGP
expiration machinery would still work. Basically in that model the
Bitcoin address - most likely a stealth address for privacy - is added
to the key as signed data. All signatures in OpenPGP have optional
expiration times, and additionally they can be revoked after the fact if
needed as well.

Of course, such ideas aren't limited to OpenPGP - all payment protocols
should consider adopting them.


As for protocol level hacks, keep in mind that anything that makes a
transaction invalid because of the presence of a specific scriptPubKey
in a txout has the potential to make a whole chain of transactions
become invalid during a reorg. Adding such protection in the form of
IsStandard() policy would be ok, but as a protocol rule it'd be pretty
dangerous. IMO much better to just solve the problem at the UI level.

-- 
'peter'[:-1]@petertodd.org
32d9d8942fe9461cce9db22a6cd86eacb5c18b415ebb649d


signature.asc
Description: Digital signature
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Policy for DNS seeds

[Peter Todd]

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 requirements are
> unreasonable let us know too. If we haven't heard from you by
> 2014-08-04 we will remove your DNS seed from the list of defaults.
> 
> Expectations for DNSSeed operators
> 
> 
> Bitcoin Core attempts to minimize the level of trust in DNS seeds,
> but DNS seeds still pose a small amount of risk for the network.
> Other implementations of Bitcoin software may also use the same
> seeds and may be more exposed. In light of this exposure this
> document establishes some basic expectations for the expectations
> for the operation of dnsseeds.

Might be worthwhile to also write an "Expectations for DNSSeed users"
outlining what security properties the seeds actually have, and what
kind of attacks are possible. Many users would be better served with
seeds that offer authenticated and encrypted connections to the seeds
for instance. (esp. if they're using authed/encrypted connections to
nodes, e.g. Tor hidden services)


> 1. The DNSseed results must consist exclusively of fairly selected and
> functioning Bitcoin nodes from the public network to the best of the
> operators understanding and capability.

Along the lines of my above point, for Bitcoin Core users of the
DNSSeeds what constitutes a "functioning" Bitcoin node is much more
broad than what other users might need.


> 2. For the avoidance of doubt, the results may be randomized but must not
> single-out any group of hosts to receive different results unless due to an
> urgent technical necessity and disclosed.

Note that singling out a group of hosts to receive different results
with DNS is especially difficult as you'll be usually singling out
different ISP's rather than hosts themselves. That said if we ever start
operating HTTPS or similar seeds this expectation will become even more
relevant for them.


> If these expectations cannot be satisfied the operator should
> discontinue providing services and contact the active Bitcoin
> Core development team as well as posting on bitcoin-development.
> 
> Behavior outside of these expectations may be reasonable in some
> situations but should be discussed in public in advance.

I'll let others refine the exact wording. but I broadly agree with these
rules.

For the testnet DNS seeds - IE my one - my thoughts are the rules should
be identical. Most of the above is related to privacy rather than
security, which apply equally well on testnet. While there have been
suggestions to use the testnet seeds for testing vulnerabilities, the
public discussion clause should suffice to allow those exceptions. I
also suspect that vulnerabilities are likely to be dismissed by a large
part of the community if demonstrated with DNSSeed operator
co-operation.

-- 
'peter'[:-1]@petertodd.org
3dcfcd420fbf9e5b6bdab43ac772960351475dec125382ef


signature.asc
Description: Digital signature
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Time

[Peter Todd]

On Fri, Jul 25, 2014 at 12:30:11PM +0200, Mike Hearn wrote:
> >
> > Ok... 'time' on the blockchain could be 'gamed' ... but with great
> > difficulty.
> 
> 
> Unfortunately not: miners have in the past routinely gamed the timestamp in
> order to use it as an extra nonce and squeeze some more gigahashes out of
> their hardware/pool.

That's correct, but irrelevant for this application. The "gaming"
possible is only a few bits; gaming more bits than that either makes
blocks invalid due to being >2hr in the future, or < the 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

> > An application presented with a fake blockchain can use
> > quite a few heuristics to test the 'validity' of the block chain.
> >
> 
> The app cannot tell if it was given a truncated chain. You could keep such
> an app stuck in the past forever. This is often a problem.

Only if the app is trying to use the blockchain non-interactively. The
right way to use the blockchain for determining the current time is to
create a nonce, timestamp it, wait for a confirmation, and get the
merkle path to the block header. This proves the attacker has spent at
least whatever resources it took to create a block considered valid by
your application. (you'll probably want to have a fairly high
min-difficulty)

> > Reliable 'time' has been impossible up until now - because you need to
> > trust the time source, and that can always be faked.  Using the
> > blockchain as an approximate time source gives you a world wide
> > consensus without direct trust of any player.
> >
> 
> Much though I hate to be a party pooper, you could currently get
> Bitcoin-level trusted time by just polling at least two or three
> independent servers e.g. google.com, baidu.cn, yandex.ru(they all serve
> time via HTTPS headers).
>
> If we crack the mining decentralisation problem then this argument becomes
> a lot stronger, but for now ..

See https://github.com/ioerror/tlsdate

Reminds me: anyone know if tlsdate is able to produce timestamp proofs
verifiable by third-parties? If it could in conjunction with the
blockchain as a random beacon you could at least show dishonesty by
showing that google.com/etc. signed a HTTPS header with a time prior to
when some block was created. Right now unlike the blockchain these
independent servers can easily get away with timestamp fraud,
particularly if they manage to target your specific application. (use
Tor!)

Equally, the blockchain has the advantage that it's easy to show that
invalid blocks are being created for the purpose of creating fake
timestamps; it'd be reasonable for the P2P network to relay any block
header seen with a difficulty > some anti-DoS threshold. Gavin already
did something similar with relaying invalid blocks in pull-req #3580.
It had the flaw of making network splits worse, but in conjunction with
a separate "invalid-block" inv type I think the issue goes away.

-- 
'peter'[:-1]@petertodd.org
201d505432d708aa2edb656f6fe34d686b37d4747e5ff389


signature.asc
Description: Digital signature
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

[Peter Todd]

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.blutmagie.de/router_detail.php?FP=0d6d2caafbb32ba85ee5162395f610ae42930124
> 
> Alex Stamos (cc'ed) and I have been discussing on twitter what this could
> mean, wanted to raise it to the attention of this group for discussion.
> 
> What we know so far:
> 
> - Only port 8333 is open
> - The node has been up for 3 days, and is doing a lot of bandwidth, mostly
> plaintext Bitcoin traffic
> - This is probably pretty expensive to run? Alex suggests that the most
> expensive server at the company hosting is 299€/mo with 50TB of traffic

Boring explanation: some mining pool wants to get a lower orphan rate by
connecting to the whole network simultaneously and has cleverly setup
their node as a Tor exit node to get some plausible deniability.

Of course, reducing orphan rates is indistinguishable from a sybil
attack; in general setting up such a node can be plausible deniability
cover for any type of attack. One possibility would be to sybil attack
the network to do logging; another would be DoS attacks. For the latter
we're pretty vulnerable to the Bloom IO attack(1). The former attack is
possible too, though I'd expect an attacker to want to do it in a less
obvious way and run more than one node. Also running one big Tor node is
less than ideal as it won't accept incoming connections, which lets you
attack SPV clients. Finally note how you can plausibly conduct the
attack directly from the node itself without bothering to actually use
the Tor network.

Anyway, just goes to show that we need to implement better incoming
connection limiting. gmaxwell has a good scheme with interactive
proof-of-memory - where's your latest writeup?

1) https://github.com/petertodd/bloom-io-attack

-- 
'peter'[:-1]@petertodd.org
201d505432d708aa2edb656f6fe34d686b37d4747e5ff389


signature.asc
Description: Digital signature
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

[Peter Todd]

-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 an abnormally large % 
of the Bitcoin network. Looks like a Sybil attack to me, trying to hide behind 
a Tor exit node for plausible deniability.


On 28 July 2014 06:16:16 GMT-04:00, Mike Hearn  wrote:
>> As I pointed out above, — it isn't really.  Without the exit flag, I
>> believe no tor node will select it to exit 8333 unless manually
>> configured. (someone following tor more closely than I could correct
>> if I'm wrong here)
>>
>
>The "exit" flag doesn't mean what you would expect it to mean. The
>reason
>such a node won't get much traffic is that Tor speculatively builds
>circuits at startup on the assumption they'll be used for web browsing.
>Thus if you don't exit web traffic you won't get much in the way of
>traffic
>at least not until bitcoinj based wallets start shipping Tor mode.
>
>There's a perfectly reasonable explanation for why someone would run
>such a
>node. In fact I run a Tor exit that only allows port 8333 too: it's a
>way
>to contribute exit bandwidth without much risk of getting raided by the
>cops.
>
>Occam's razor and all 
>
>
>
>
>--
>Infragistics Professional
>Build stunning WinForms apps today!
>Reboot your WinForms applications with our WinForms controls.
>Build a bridge from your legacy apps to the future.
>http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>
>
>
>___
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT1jPPMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcFSB/9Sr+2an63QQe7TpGMA
zH5AG1bjcl4Tf/VGVBYK8K2kXsdtfEWNS+nJ9eCglPE1A7/Cc2LL3pksoJwdnt82
VyuH8FlWUXwnBeZvK/rYUvBz2FQupHYg5+ee+HZ6nYjKTDYrHuSUX+GlqMO2GPII
D3FhQRIfluuTQTpYoN0ui0DXQ4QDqZgwxFXWiblctA2m986bKFrqrJ5ohZXTDCnE
mTq//ZABykPPtEcou5G1kLjH9l5YMU4XeMyz6uzADXt0ZTHBDN3lOZ8sFPpJEi0z
VGh4QlT6fRQIiYsq0AzMyUvopSwsCyQy6yeMt/bCOdanmAIcGm+l8og3mlX2Ml5g
nQsg
=/w5n
-END PGP SIGNATURE-


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Peter Todd]

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 not necessarily require even a
> soft fork, and does not cause problems with reorgs like the proposal
> in #3509:

Anything that changes the semantics of nLockTime will do harm to
existing and future applications that make use of nLockTime for things
like refund transactions.

In any case, why do transactions need finite lifespans in mempools? If
you want to double-spend them with higher fees, then implement
replace-by-fee. In any case, lifetimes will never be deterministic as
not everyone runs the same software.

> Transactions would stop being relayed and drop out of mempools a fixed
> number of blocks from their creation; once that window had passed, the
> sender's wallet could begin to expect the transaction would not be
> confirmed. In case a reorg displaces a transaction until after its
> expiry height, a miner can still put it back in the blockchain; the
> expiry height is just a relay rule. Also, a user who needed to get
> their original "expired" transaction confirmed could still do so by
> submitting it directly to a miner with suitable policies.

...in which case someone will circumvent this IsStandard() rule by
submitting "expired" transactions directly to miners with suitable
policies.



signature.asc
Description: Digital signature
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Peter Todd]

-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 are committed by merkle radix tree in an extensible and provable 
way. You'd then commit to that tree with a mandatory OP_RETURN output in the 
last txout, or with a new merkle root.

Changing the tx format itself in a hard-fork is needlessly disruptive, and in 
this case, wastes opportunities for improvement.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT4kzQMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhamzCAC+zRaXRodP63+ke3K+
Viapiepvk4uIOlqxqtMB2O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6
//qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c
4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba
1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP
RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2
sJKN
=oPSo
-END PGP SIGNATURE-


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Peter Todd]

-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 as
>part of the network and on-disk data structures, so that proper
>validation can be done. This would be both more disruptive and less
>efficient than simply adding an nExpiry field to the transaction
>format,
>as we do in Freimarkets.

The general case doesn't require transmission of any merkle data; it is derived 
from the tx data. Equally changing a data format is certainly: note how 
Freimarkets has no third-party library support because you've made it 
incompatible with the standard Bitcoin data structures. Merkle radix tree 
formatting OTOH is just a cryptographically committed extension of the 
tag-value concept seen in protobuf, among others.

re: efficiency, we need fundamental improvements in efficiency, not little 
micro-optimisations everywhere done at high cost to maintainability.

re: validation, note how the merkle radix tree meets that need by allowing the 
absence of data to be proven.

>If the field is pre-consensus (a mempool gentleman's agreement), then
>it
>has no business in the transaction structure at all and should be
>packaged in some sort of envelope container.

It's also rather useless without consensus. Expiry is only useful if it is a 
guarantee, if not you might as well just implement tx replacement directly.

-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT4mPZMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcbKCACz/Qh3wm7ud9iwbvm3
Hzib36/fixk2++z6xlxh8G8afUaAe7ADCoz/TLK7RNIhUnr2hlsPO+Id2XvVBSm1
gXavj4iDxq8TpWsC8zPs5vyyY/dVwQ0RbidQFSpncmdW6EYVpIQp9nP3sSnBv1M8
c7BVidg708tc44uYiM9jeTzh6amP5yD0+G9FYYmy36BAQj8+4iD1ZCkiye1y5WUL
9MSN8LOxRFEwWQJmySXmJ1I9V81l1NSRQcQtfLVCzEIWLJXrZ0xwOq0SryEObg73
72NZKc2u8la3CPDoCG773ENbGHl+mGJW9M5ypV0s2RdkdZMgaFNnl/SBrWAcPd43
FkLr
=OMOy
-END PGP SIGNATURE-


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Peter Todd]

-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
>whole
>> thing until some point in the future.
>
>Note that this would be a massive, *massive* change that would
>completely break bitcoin output frangibility. Merchants would have to
>start demanding input history back to a certain depth in order to
>ensure
>they are not exposing themselves to undue reorg-expiry risk.

Bitcoin is already "broken" in that regard due to malleability, and more 
fundamentally, the existence of anyone-can-spend outputs, known private keys, 
SIGHASH_ANYONECANPAY, etc.

In any case, reorg-doublespend risk is no different than reorg-expiry risk.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT4mcdMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhSdiB/9no/fXR50Zej4l6Hyt
gDvM9GWosGxZydQfplrUYzS9nLWTJgkjNYkrJk1OXPlkiNoHhlpCK6TuEL3DXBo8
txDBhp/xls7aFHELpPhP5iKrEj0J6fyMp9wKRVtUu0J+RhHY22v+iEQf//dGUX4v
hQPwATubmnyeVd71TAKyW6zCPjoEh0IG19tRVvw/v7/qNTXHdSZTkSVzQa4GP2gr
2xVqXTeOycPKqIU+GaNI4aRAL2DUm1kW3jG/+h3BwnJNd5q+0ELpC6xDmkA6hkNz
N6BFCtoghhKNH+FNsZKAzE9w8dYngZQbaA9vVdaR6SXzz9KuG526EymOF7e55IBJ
FMu+
=ii2+
-END PGP SIGNATURE-


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Peter Todd]

-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 that possibly be the case? The information is hidden behind the
>Merkle root in the transaction. The validator needs to know whether
>there is an expiry and what it is. What's it supposed to do, guess?

The general case is all committed information is included in the transaction; 
the merkle tree is a compatibility path, as well as an optimisation for lite 
clients and applications.

You should read more about soft-forks; see the BIP. Remember that Bitcoin 
protocol development and deployment is not a centrally controlled activity.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT4mgPMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhSYlCAC1ncAGQt53HKS+8/rq
OG0RGrqE2l2/qCM/ybd9M8TkwxaI3NB5bqfIus8dB5MnyiTBFS3ooN54kNNOHtSX
2rEzPJphtOj46tk3nqe1QO3cbFJPjBCtxZff51DWZckhCiO2Iy1Br3fK3v55iscp
1jxyZnpfgUG/Ivfx+h6vkisucBXgXJ82d5vzvMIMxixh4v2+4/SAcSY6HCLIpxmV
Z3l0NcGllnmWe5B6eftpWYUAREuoCNk/671jHmwu0cqk2u/Egrp776zxkEO1xivH
d0EWjJmlDLmQ2hEhkpBq46ji/2m4EWPLqTW/EXf3RzwU8uCEldbxEe2tyZ0d6oBt
NnTE
=AhV7
-END PGP SIGNATURE-


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Payment ID #'s for Stealth Addresses

[Peter Todd]

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 customer's account. Similarly an informal
person-to-person transaction can attach a number short enough to be
communicated verbally or on paper. Finally multiple payments with the
same ID # can be merged together in wallet UI's, allowing
merge-avoidance to be conveniently used with stealth addresses.

To avoid accidental collision such payment #'s should be at least
64-bits; to avoid privacy loss the encoded size should be the same for
all users. Thus we pick 64-bits or 8-bytes. In addition for the purposes
of CoinJoin and multiple outputs it would be desirable for all
stealth-using outputs the option of sharing a single 33-byte ephemeral
pubkey. Thus our OP_RETURN output becomes:

OP_RETURN   { ... }

Of course, this can't be accomodated within the existing 40-byte, one
OP_RETURN per tx, IsStandard() rules, something which is already causing
issues w/ Dark Wallet when users try to send to multiple stealth
addresses at once, and when multiple stealth sends are CoinJoin'd
together.

1) "Merge avoidance", Dec 11th 2013, Mike Hearn,
https://medium.com/@octskyward/merge-avoidance-7f95a386692f



signature.asc
Description: Digital signature
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] SIGHASH_ANYONECANPAY extra inputs DoS attack

[Peter Todd]

tl;dr: Transactions with SIGHASH_ANYONECANPAY-using inputs can be DoS
attacked by attackers adding extra inputs to them that make the fee/byte
paid unfavorable to miners, while still being high enough to be relayed.
While just a nuisance DoS attack, this is a serious obstacle towards
using ANYONECANPAY.


Background: What uses ANYONECANPAY?
---

1) Crowdfunds/assurance contracts: e.g. Hearn's upcoming Lighthouse, as
well as Armory's implementation.

2) Fee bumping: receiver or sender can add inputs w/ ANYONECANPAY to get
a tx confirmed without the (expensive) overhead of a second CPFP tx.

3) Privacy: inputs are more deniable in some cases, e.g. dust used for
fees, which anyone could have added.

4) Replace-by-fee scorched earth: best implementations(1) depend on fee
bumping.


Partial defense: replace-by-fee
---

The attacker's modified transaction will usually, but not always, be
replaced by the intended one as the latter will have higher fees.
However replace-by-fee implementations must charge adequately for
network bandwidth consumed, so there will be edge-cases where the
replacement does not happen.


Transaction fee/byte optimization
-

Each input that does not use SIGHASH_ALL can be evaluated in terms of
whether or not it increases the fees/byte paid by the transaction. Thus
we can optimize a transaction to pay the highest fees/byte by doing the
following:

def optimize_tx(tx):
tx2 = CTransaction(vin=[], vout=tx.vout, nLockTime=tx.nLockTime)

for txin in :
if :
continue

if :
prev_fee_per_byte = tx2.fees / len(tx2.serialized())
tx2.vin.append(txin)
if tx2.fees / len(tx2.serialized()) < prev_fee_per_byte:
# adding txin decreased fees/byte
tx2.vin.pop()
return tx2

else:
tx2.vin.append(txin)

return tx

Essentially txin's that reduce the 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://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 WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Another weird transaction question...

[Peter Todd]

-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 obviously correct (as it is verified by the
>legit client) that has me seeking clarification.
>
>This multisig output script:
>
>https://blockchain.info/tx-index/12809044/0  (txid:
>274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857)
>
>contains a public key:
>
>00f2b7816db49d55d24df7bdffdbc1e203b424e8cd39f5651ab938e5e4a193569e
>
>Are invalid public keys permitted and silently ignored? Or does the
>0x00 prefix have some interesting meaning?

Have you looked at the Bitcoin Core script test cases yet? You might be 
surprised at what is allowed. Equally, read the source code! In particular 
follow the block acceptance logic line by line from start to finish.

In any case, the Bitcoin protocol doesn't care whether or not a public key is 
valid.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT66oXMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcgKCACT18WjN11SCuX5qyeq
D5zOtGBsAtPMWr8CJuds4gLIkRtxDxPy9cuIMzwLylaC0yvFSIrG6rAIcqqRpkEH
hcJj2IXyTRVr/mxg3qDzphYuwWQAgUzBgbhPsHtl8SvnbzJgEdXCsErGs3eW6JTR
I5OXeMVT8ZKQVJUKCNGdzlH4673Gh6fIzwW1cPLATt486ByCk5YRXC14IGasxnlg
6IWm4r/I6gOAB7FiPCHm60Q2DJOsX+VEFe3U28Zxlx06i0Ij9JYoKbTDu8e12bSB
YFUBwGCbwWr/Xcygg0nWyrEMVk5dcxk/30asF/dEczHRZo9DNUdKt4IAESd+GGC2
P9g4
=e0do
-END PGP SIGNATURE-


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Cloud mining should be using merkle sum trees to prove they aren't doing fractional reserve mining

[Peter Todd]

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 customer profits rather than actually being used to
purchase mining equipment.

We can use merkle sum trees to detect this fraud cryptographically:

1) Put the MH/s paid for by each account into a merkle sum tree, each
with a customer supplied unique identifier. (like their email address)
This allows the customer to verify that the hashing power they paid for
has been included in the total hashing power claimed.

2) Mark blocks found by the operation publicly so they can be associated
with the specific cloud mining operation; putting the merkle sum tree
root hash into the coinbase or an OP_RETURN output would be ideal. This
allows anyone to verify that the hashing power claimed corresponds to
the # of blocks actually found.

-- 
'peter'[:-1]@petertodd.org
201d505432d708aa2edb656f6fe34d686b37d4747e5ff389


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Peter Todd]

-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 
are very high; even the NSA can't pull it off consistently for non-targetted 
operations due to limitations on upstream bandwidth and other resources. 
(remember that many of their taps are non-cooperative ones, obtained by 
breaking into routers at ISP's) This I've confirmed with direct conversation 
with Jacob Applebaum and other Tor devs. Every additional bit of encrypted 
information flowing over the internet increases the work they need to so to 
deanonymize you. This is not unlike how CoinJoin, while not providing 
guaranteed anonymity, makes the job of attackers significantly more difficult 
by creating large amounts of statistical noise. In addition the Bitcoin P2P 
protocol has natural anti-traffic analysis properties due to its asynchronous 
nature.

Re: MITM attacks, again, the resources required to conduct them on a large 
scale instead of passive attacks just don't exist. For instance the NSA has to 
be relatively selective in using them for fear of being detected; being able to 
detect attacks is a huge improvement over the status quo anyway.

Having said that using Tor by default in Bitcoin Core is an even easier way of 
enabling encryption and authentication, and would help protect all Tor users 
from surveillance. The easiest way to do this would be to make the 
Debian/Ubuntu packages depend on Tor, and include a install-time script to 
setup the hidden service. I've verified with the Tor devs that they would 
welcome the additional load on the Tor network that Bitcoin would add.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT8+jcMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhU2WB/9XE6BFxTkbjIfVn46U
uH7HCV/FSgCeSConO7LbFR2m6hN5eZ4oKcLzIi65SqRUol2eCGWVoJDsl3vuTmwF
c4gOqdieJQ6SOdHAzcolf+b3p+VwIXXUMMsO2vI6UGZvV6gFJXnZ17GASdSo9+f8
x4VxgLSunZD0xRMiMntaqPMFu1MyplomimQadW5MDt3QTa2BrOsDMwNS10NSQIAL
8ywHSKh8UddVL8ZeinE/Bhf3T1OnDVBIUCVHhhEYnKLqCnwmyY3NXH4lzXpPvo+e
LhzF7HzB5tE22vIQNb/3RimoN5FV7p4FEvgsGwT/kjjUAxgg6/LpNY5WQG6FL8nJ
/8F3
=t4/7
-END PGP SIGNATURE-


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Peter Todd]

-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't pull it off consistently
>for
>
>Hardly.  For example, when a new block arrives on the network, a
>single observer at a single location may obtain a binary "likely|not
>bitcoin protocol" decision from a spike in usage correlated with
>sudden, global network activity after a period of inactivity.  I'll
>not detail all such metrics.

Emphasis on "likely", at best. Forcing you adversary to rely on uncertain 
statistics is a huge improvement over the status quo. Secondly your example is 
of a new block; the more general concern is determining where a given 
transaction originated. In the best of circumstances determining the origin of 
a few hundred bytes of days interspersed in dozens of kB/s of buffered data 
streams is very difficult and expensive even without padding and/or random 
delay features.

Again, I've spoken to people like Jacob Applebaum about this who have a solid 
understanding of what the NSA is actually capable of, and they've confirmed the 
above. Don't let perfect be the enemy of good.

Of course, that's not to say we shouldn't cost-benefit analysis the 
implementation; not using straight OpenSSL for this is a wise decision. Hence 
the suggestion of using the existing and tested Tor support to encrypt by 
default.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT8+62MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhZe/CADI+XvuCzK6N0/UUieD
WzrGexWQsqNxX2hYQpzAiYT3Y5k4CCJ3yvett0udYKS3Piqd/ihvj9RfjWe5nO+d
snPGNwFU7jSRJ+hwPdnlHfFW99LCkKOzBX0hgC+qg11SyLKcsBwE3qaiFM47G1hy
r4f1qX3Te2Kt0bUxP65d1M0Js1M0x+qLxXs6e9Gy3scFSpDjeoamgliJ6jBeeX9U
8H0mambip5CZ+diGbaMeCCRJd19XH7Nz0QgcznYScmz/3krQhtIdEJKts7bs87vh
vZyH7M4wVCiIDmDNxAIO2slo3+eopEvbOPgqjT7L72jrQgp3zVUtbJDzpSAgcB+M
vLhB
=AuCe
-END PGP SIGNATURE-


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Peter Todd]

-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 to setup
>> the hidden service. I've verified with the Tor devs that they would
>> welcome the additional load on the Tor network that Bitcoin would
>> add.
>
>The easiest way for the people who operates nodes would be to compile
>Tor into Bitcoin Core as a library so that it "just works" when turned
>on.

That library doesn't exist yet to my knowledge, and more importantly, would 
increase the attack surface of Bitcoin Core. (much like using OpenSSL for 
straight SSL support would)

Also, my proposal of adding Tor support to the Debian packages can be 
implemented in a relatively short install time script; no code changes required.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT8/KRMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhauiB/9iEvsRYQGt9lFmrtbW
SBjDt91/v7r3NcI/19aKDNGMaKl61rpzDr1zM3kIBdY3xzFoaYt+LA6O/tZVvaVC
B9zPlZsh+0ZmbU+Ejxd816DvJVDv8aO6Nt+sLuVkkN/TsBa/WCBhvwJ7ixS65/dY
WpFV7awzW+E08RETsV826scP+30lsnY5qcADoHWfuaW7HZQArpCsA+b+Amng8Vf6
mFb5GrxKlvG06w+esLSXMCISS3eMduvfzymfxBxGlgxRAqiYZRbWY3msdRRfWl3e
lISrnqZoB3G529WVGOn4o5DrzDdSJFcb8k2A/Na2J+pIxAD4Cv9vwYM2KCffbeUB
PH6x
=Mw3I
-END PGP SIGNATURE-


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Peter Todd]

-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 any method of
>authentication.

Don't let perfect be the enemy of good.

> The bitcoin network is trivially MITMable. It's
>designed to
>work even in the face of that, but any encryption we implement will
>just
>get blown away by anyone who cares enough to stand in the middle of two
>nodes.
>
>As far as I can see, we get a microscopic obfuscatory advantage over a
>very
>weak passive attacker, at the cost of hugely increased software
>complexity
>(and possibly increased CPU time).

You realize that by your own definition even the NSA is mostly a "weak passive 
attacker" They do *not* have the ability to attack more than a small, targeted, 
subset of connection for both technical and political reasons. For starters, 
MITM attacks are easily detected - "Bitcoin network attacked by unknown agents! 
Has your ISP been compromised?" would make for great headlines and would soon 
see the problem fixed both technically and politically.

In any case, my suggestion of enabling hidden service support by default adds 
both encryption and reasonably good authentication.

-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT8/ZaMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhV5UCAC0wVMyKtCedZuUKXrw
Mg6qvbkDzGyzn7fgASTnMh8hF+p+p5MoOz3K0FGTdLph+ulptz9ITatGmmi+av+u
0Fc8xXYgxiYcIwtMVumNrHR16bjG7NoShnqMujuUZ7a+xigeHxV2/tG0VRb9Km8W
GFYNdY4mOFubFu7qfqymmxGsIgP42rPsN6c41B75wqqaGzSX7BRmlxNsYVSUO3Fi
fwNU7y7hLC9BN+WQCmVK+Rk57XpXcoydfvsz9a/SLhiQKssEdcDbUq4gLtnDHs92
JBsUqzG/wDgcQFiLuAm/A/ZvDAERwPr6jtunt3CCDt+UdLwlGAj5RTnuHgY72PNS
Ma2O
=2qdX
-END PGP SIGNATURE-


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Peter Todd]

-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 and reasonably good authentication.
>
>
>Enabling hidden service support by default would introduce an insanely
>huge
>attack surface.

Hence my suggestion of separating that surface by using the standalone Tor 
binary, which runs under a different user to the Bitcoin Core binary.

>And you're conflating two different things; using Tor is valuable to
>Bitcoin because it would provide some anonymity. The encryption aspect
>is
>pretty much useless for us.

First of all, without encryption we're leaking significant amounts of 
information to any passive attacker trying to trace the origin of Bitcoin 
transactions, a significant privacy risk.

Secondly the upcoming v0.10's fee estimation implementation is quite vulnerable 
to Sybil attacks. Authentication and encryption are needed to make it secure 
from ISP-level targeting to ensure that your view of the network is 
representative. Tor support used in parallel with native connection is ideal 
here, as neither the Tor network nor your ISP alone can Sybil attack you. It's 
notable that Bitcoinj has already implemented Tor support for these same 
reasons.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT8/mSMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhRZjCAC4PSpQ68qgtFMR77xf
zXZLr/iMKX6yyJwXRj+vGi+0Ng/sv9NlYjYnDeflom37WlpGo/sCOFcVWImhnS2d
kUFoUH92iXwRuEt/SN/LrHghkLWOxtVu9wa49eS/piGZFF3JWllk82MgdBZ6vjNw
B6WuInEIurK+h8rUbAi2HjFkxVN0K0SsrFt/P0tHj10ABcMealBRoJh2Jx7fLNdS
uTKddqeLyThEpLGNti3k+lhwQ2dA5RUBq6q3GUS/hWvTHRnU+viGMJSYv62LXRN5
t87BXRY/R9UBpnudf3TIlPtOuIWcv2LhlXVjvbDDQqwJkvB3Qf4ejE3RZ28S5IUr
OBQH
=Gy7X
-END PGP SIGNATURE-


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Reconsidering github

[Peter Todd]

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 commits serve two purposes: recording public history and
communication.  While for the purpose of recording history immutable
commits make sense, for the purpose of communicating to other developers
what changes should be added to that history you *do* want the mutable
commits that git's rebase functionality supports. Much like how
university math classes essentially never teach calculus in the order it
was developed, it is rare indeed for the way you happened to develop
some functionality to be the best sequence of changes for other
developers to understand why and what is being changed.

Anyway, just because mercurial is designed around the assumption that
commit history is immutable doesn't mean it actually is; an attacker can
fake a series of mercurial commits just as easily as they can git
commits. The only thing that protects against history rewriting is
signed commits and timestamps.


> The problem with github is it's too tempting to look at the *web page*, which 
> is NOT pgp-signed, and hit the 'approve' button when you might have someone
> in the middle approving an unsigned changeset because you're in a hurry to
> get the latest new critical OpenSSL 0day security patch build released.
> 
> We need multiple redundant 'master' repositories run by different people in
> different jurisdictions that get updated on different schedules, and have all
> of these people pay attention to operational security, and not just outsource
> it all to github because it's convenient.

The easiest and most useful way to achieve that would be to have a
formal program of code review, perhaps on a per-release basis, that
reviewed the diffs between the previous release and the new one. Master
repos in this scenario are simply copies of the "master master" repo
that someone has manually verified and signed-off on, with of course a
PGP signature.

If you feel like volunteering to maintain one of these repos, you may
find my Litecoin v0.8.3.7 audit report to be a useful template:

https://bitcointalk.org/index.php?topic=265582.0

-- 
'peter'[:-1]@petertodd.org
284b07a00c97e4770dda4dee8b45994440226435ee05ab66


signature.asc
Description: Digital signature
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Reconsidering github

[Peter Todd]

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 billion dollar
> blockchain. So what is the best way for me to stick both a git *and* a
> mercurial identity hash into a bitcoin transaction?  (which leads to point 2
> below)

A "bitcoin transaction" can't by itself serve as a signature, as there
isn't any way to link the transaction to what you actually care about -
a human being - without additional infrastructure. You may find it
helpful to reflect back upon your 2nd and 3rd year courses on
post-modernism and semiotics: Is a keypair in a public key cryptography
system what is being signified, or is it merely a (posssibly false)
signifier?

If you just want to timestamp a git commit you can timestamp it in the
Bitcoin blockchain. I have the code to do so in my python-bitcoinlib:

examples/timestamp.py 

To check timestamps the following should work, although I haven't tried:

bitcoind searchrawtransactions 

You do need the searchrawtransactions patch. I've personally timestamped
most of the git tags for releases this way.

> > If you feel like volunteering to maintain one of these repos, you may
> > find my Litecoin v0.8.3.7 audit report to be a useful template:
> > 
> > https://bitcointalk.org/index.php?topic=265582.0
> 
> I'm not interested in volunteer, I'm interested in getting paid, and the
> best way I believe I can accomplish that is use *my* bitcoin address in a
> signature-transaction of the code I've reviewed.
> 
> What is the advantage of PGP? Far more people have ECDSA public-private 
> keys than PGP keys.

PGP of course has vast amounts of identity infrastructure already
developed for it, infrastructure that simply doesn't exist for "Bitcoin
addresses"

In any case you'll be happy to know that secp256k1 has been added to the
GPG development branch, which means you can sign your code with a ECDSA
key corresponding to a Bitcoin address if you wish too.

-- 
'peter'[:-1]@petertodd.org
06fb87cb8ec6e0981b134953f1916c513f7210b534a94b8b


signature.asc
Description: Digital signature
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Peter Todd]

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 Bloom filters too, which are not public
> > information.
> 
> As soon as you tell it to an unknown/public peer, it is public information.

Mike is correct here: It *might* be public information, and probably
won't be. We already can give weak assurance that it probably won't be
against many weaker attackers, simply because getting lots of IP
addresses is moderately expensive, and in the future additional methods
will be developed and deployed.

-- 
'peter'[:-1]@petertodd.org
239344fc532bbad8a679e3fc30e8900772523a10c4720a0c


signature.asc
Description: Digital signature
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?

[Peter Todd]

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
Description: Digital signature
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?

[Peter Todd]

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 the occasional thing related to releases, I'm not sure.

Doesn't seem like there's any evidence of that either. For instance the
archive.org Jan 31st 2009 capture of bitcoin.org with v1.3 has a link to
his PGP key, but the release itself is unsigned:
https://web.archive.org/web/20090131115053/http://bitcoin.org/

Similarly the Nov 29 2009 capture of the sourceforge download directory
has releases v0.1.0, v0.1.2, v0.1.3, and v0.1.5, none of which have
signatures:

https://web.archive.org/web/20091129231630/http://sourceforge.net/projects/bitcoin/files/Bitcoin/

The earliest signature I can find is from v0.3.20 from Gavin Andresen:

https://web.archive.org/web/20110502125522/http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.20/

Earliest sig in the git commit history is the v0.3.21 tag, again from
Gavin.


My best guess is Satoshi only created the PGP key in case
someone needed to send him a security-related bug report. Which leads to
a related question:

Do we have any evidence Satoshi ever even had access to that key? Did he
ever use PGP at all for anything?

-- 
'peter'[:-1]@petertodd.org
0ce4f740fb700bb8a9ed859ac96ac9871567a20fca07f76a


signature.asc
Description: Digital signature
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?

[Peter Todd]

-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 OT really, although obviously this was the right venue to 
be sure the required audience saw it and settle the question.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJUFxHcMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfCtCACLNgMrxRQ4YlX4Tkyt
CIlqRh4AOLVRXeh6ER+BJJhJA+hbunNfH6kkROIinpBsFxlRfoHwrv2ax6GIlegO
s1+MSLFAoOob3tLQY/LrVF0PMTbKybdQRqQopzu81hbLTCjpnrnN2sDpAOA/bDsV
xDTHNVbOWS7UapkZf7AjueDfuyW3yhvcgsq1Tuc4r7pdKCEQA/HjBzIqyFT2K9hp
uahaENzCfsCVsEiTmAu+p9EvXhLWmMRfRz15z7D/KtOBTI83/t/WR7UnWlSRHn4i
Xyhj/iDv+kPj/vsGXZClCUZ7T/64ovVvoeY9Pk+1fc6okWWXmTHsH+R72szkhgEu
O4QP
=C27J
-END PGP SIGNATURE-


--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] From block 0 to block 72499 the Merkle root is the same as the coinbase transaction id. Why is that?

[Peter Todd]

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();

So here all the txids are pushed onto the vMerkleTree vector:

BOOST_FOREACH(const CTransaction& tx, vtx)
vMerkleTree.push_back(tx.GetHash());

For most of the early blocks there's just the coinbase transaction and
no other transactions.

int j = 0;
for (int nSize = vtx.size(); nSize > 1; nSize = (nSize + 1) / 2)

That means this for loop never executes! nSize = vtx.size() == 1, and
the loop terminates when nSize <= 1

{
for (int i = 0; i < nSize; i += 2)
{
int i2 = std::min(i+1, nSize-1);
vMerkleTree.push_back(Hash(BEGIN(vMerkleTree[j+i]),  
END(vMerkleTree[j+i]),
   BEGIN(vMerkleTree[j+i2]), 
END(vMerkleTree[j+i2])));
}
j += nSize;
}
return (vMerkleTree.empty() ? 0 : vMerkleTree.back());
}

Thus the vMerkleTree still has only the coinbase txid in it, and and
vMerkleTree.back() returns that txid as the merkle root. There's no
problem with the merkle root algorithm working that way - to make a long
story short all this means is that the merkle tree algorithm
consistently uses the txid as the merkle root whenever there is only one
transaction. The contents of the block is still being securely committed
to by the merkleroot, which is the important thing, and there's no way
to lie about those contents.

There is however a serious flaw in the algorithm, unrelated to the case
of a single transaction, where the merkle tree is indistinguishable from
a merkle tree with duplicate txids if there are a non-power-of-two
number of items in the tree. For bitcoin we fixed this flaw with BIP30
and BIP34; for any other application you should *never* use the Satoshi
merkle root calculation code. Get it right on day one and do things
correctly.

-- 
'peter'[:-1]@petertodd.org
0fbf83c9e14d8711e4b2264ceda0d1d06d169c811387eadd


signature.asc
Description: Digital signature
--
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [ann] Bitcoin Core 0.9.3 has been released

[Peter Todd]

On Sat, Sep 27, 2014 at 09:32:02PM +0200, Melvin Carvalho wrote:
> > As well as everyone that helped translating on
> > [Transifex](https://www.transifex.com/projects/p/bitcoin/).
> >
> 
> Great work!
> 
> Apologies if this has been covered.  But I was curious about:
> 
> - 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 on number of pubkeys for P2SH CHECKMULTISIG outputs.
Previously with the 500 byte scriptSig limit there were odd restrictions
where even a 1-of-12 P2SH could be spent in a standard transaction(1),
yet multisig scriptPubKey's requiring more signatures quickly ran out of
scriptSig space.

From a "stuff-data-in-the-blockchain" point of view not much has changed
as with the prior commit now only allowing the dummy value to be null
the newly allowed scriptSig space can only be used for signatures. In
any case, just using more outputs is trivial and doesn't cost much.

1) See 779b519480d8c5346de6e635119c7ee772e97ec872240c45e558f582a37b4b73
   Mined by BTC Guild.

diff --git a/src/main.cpp b/src/main.cpp
index a0b6842..63b87b8 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -513,10 +513,14 @@ bool IsStandardTx(const CTransaction& tx, string& reason)

 BOOST_FOREACH(const CTxIn& txin, tx.vin)
 {
-// Biggest 'standard' txin is a 3-signature 3-of-3 CHECKMULTISIG
-// pay-to-script-hash, which is 3 ~80-byte signatures, 3
-// ~65-byte public keys, plus a few script ops.
-if (txin.scriptSig.size() > 500) {
+// Biggest 'standard' txin is a 15-of-15 P2SH multisig with compressed
+// keys. (remember the 520 byte limit on redeemScript size) That works
+// out to a (15*(33+1))+3=513 byte redeemScript, 513+1+15*(73+1)=1624
+// bytes of scriptSig, which we round off to 1650 bytes for some minor
+// future-proofing. That's also enough to spend a 20-of-20
+// CHECKMULTISIG scriptPubKey, though such a scriptPubKey is not
+// considered standard)
+if (txin.scriptSig.size() > 1650) {
 reason = "scriptsig-size";
 return false;
 }

-- 
'peter'[:-1]@petertodd.org
188beaebec22c62bcff1a5d92e5d21432e797ec717cfed3a


signature.asc
Description: Digital signature
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] replace-by-fee v0.9.3 release

[Peter Todd]

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 actual signed double-spend?
> 
> #4570 relays the first double-spend AS an alert.  Running this branch on 
> mainnet, I have been keeping a live list of relayed double-spend 
> transactions at http://respends.thinlink.com

Speaking of, I ported my replace-by-fee branch the recent v0.9.3
release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.3

I actually ported it a few days ago; that release has been running on a
half-dozen or so nodes right now for a few days with no issues.

The v0.9.3 release's scriptSig size limit increase adds a new category
of double-spending exploit. I'm not going to get time to add that
exploit to my replace-by-fee toolkit(1) for at least another week or so
though - pull-reqs accepted.

1) https://github.com/petertodd/replace-by-fee-tools

-- 
'peter'[:-1]@petertodd.org
084778cc7b7394a48d65c9451a59dcf98d0f1e1078f39c3a


signature.asc
Description: Digital signature
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] New opcodes and transaction version numbers (was 'relax the IsStandard rules for P2SH transactions')

[Peter Todd]

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 problem consider the "re-define
OP_NOP1 to be OP_Q_CHECKSIGVERIFY" example. It says "Transactions that
use the new opcode are given a new version number." The problem is in
the definition of "use"

Lets first suppose that the evaluation of a scriptPubKey was done
according to the transaction version # of the transaction creating the
scriptPubKey. This is technically feasible as the UTXO set records the
version of the transaction creating the txout. However if I create a
P2SH address whose redeemScript makes use of a new opcode - say the new
OP_Q_CHECKSIGVERIFY - non-upgraded clients sending funds to that address
will be creating scriptPubKeys whose contents can be spent by anyone.
Not exactly ideal! 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 new
addresses for every new opcode defeats the purpose of P2SH.

On the other hand suppose scriptPubKey evaluation is done according to
the version of the transaction spending the scriptPubKey. This is
insecure as now transaction outputs using the new opcode can be
trivially spent by just spending them in a transaction with the previous
version number; the OP_Q_CHECKSIGVERIFY is evaluated as OP_NOP and
checks nothing.

If txouts be spent only by transactions with nVersion >= the nVersion of
the transaction spending them, but again you're forced to upgrade the
address format for every new opcode. Interestingly this shows that the
common assertion that "P2SH should have been done by upgrading the tx
version #" is in fact wrong except for the fact that P2SH required an
address format upgrade anyway; doing that for future opcode upgrades
would be a mistake.

With the above in mind the "Relax IsStandard rules for P2SH
transactions" pull-req(1) is incomplete as it doesn't blacklist usage of
the upgradable NOPx opcodes. After a future soft-fork redefining a NOPx
opcodes' behavior non-upgraded nodes will accept and mine transactions
that may now be invalid, the latter creating invalid blocks and thus
false confirmations. I've created a pull-req to fix this issue by
specifically blacklisting the NOPx opcodes if they are executed:

https://github.com/bitcoin/bitcoin/pull/5000

Secondly the "Blockchain Rule Update Process" gist above should be
rewritten to say that new opcodes will be enabled for all scripts by the
block nVersion upgrade mechanism; scripts must never depend on a NOPx
opcode being executed least they be rendered unspendable by a future
upgrade.

By comparison BIP62 proposes that the transaction version # be increased
to indicate that the sender wants anti-malleability rules to be applied.
This is an appropriate usage of tx version numbers as in this case the
person creating the transaction wants the anti-malleability rules
applied; the creator of the scriptPubKey's being spent does not care
whether or not they are spent in a transaction that is or is not
malleable. Equally the new owners of the txouts being created don't in
general care how they were created. (modulo certain special-purpose
protocols where they would have the transaction anyway)

1) https://github.com/bitcoin/bitcoin/pull/4365

-- 
'peter'[:-1]@petertodd.org
05ec432fd4c506119a0123a028911fa3981bcde0568b66ab


signature.asc
Description: Digital signature
--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] New opcodes and transaction version numbers (was 'relax the IsStandard rules for P2SH transactions')

[Peter Todd]

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 new
> > addresses for every new opcode defeats the purpose of P2SH.
> 
> Can't this be solved with a single update to the address format,
> allowing a tx version number to be part of the address serialization? 
> Then the sending software will apply that version to the payment tx.   
> Of course, I'm not sure if allowing nodes to create transactions with
> version numbers outside of their programming is safe.  It seems like it
> should be since we're talking about soft forks anyway, but there's
> probably some subtleties I'm overlooking.

Keep in mind that when a *wallet* - not a node - creates a transaction
the scriptPubKeys in the transaction outputs have been specified by the
receiver(s) and aren't executed until they are spent. Modulo sigops(1)
there is absolutely no reason why the wallet should care what the
contents of those scriptPubKeys are at all.

This is particularly apparent when you remember that there may be
multiple recipients of a transaction. If I'm paying Alice and Bob, who
have specified that they want the transaction to have version number 2
and 3 respectively, now what? Do we take the highest of the two and
constrain ourselves for how scripts are interpreted for all eternity? It
just doesn't make very much sense.

Meanwhile the man-hours of effort that would be required to implement
that "one-time" address format change is huge - it took literally years
for everyone to update their software to just support P2SH addresses.
I'm working on a CHECKLOCKTIMEVERIFY implementation right now, and know
of exchanges who would like to use it ASAP. Why make them wait years for
everyone to upgrade?

On that basis alone I think the question ought to be why should we use
transaction version numbers to enable new opcodes rather than just
enabling them globally based on block version numbers.


1) Satoshi implemented a per-block sigop limit to prevent blocks from
causing an unreasonable number of signature checking operations, but
rather than computing that limit based on the scripts actually executed,
the limit is computed based on the contents of all scriptSigs and
scriptPubKeys in the block. This is bizzare given that the contents of
the latter are *not* executed, and the former misses the prevout
scriptPubKeys that *are* executed. In short this means you can create a
block that passes the sigop limit, yet executes millions of expensive
signature operations by being filled with scriptSigs spending txouts
with large numbers of sigops in their scriptPubKeys. P2SH improves on
this situation somewhat by counting the sigops in redeemScripts towards
the limit, but missed the opportunity to just count all sigops in all
scriptSigs directly.

-- 
'peter'[:-1]@petertodd.org
092e056ab9c5a3242bfa911ba9a0a8a3836bcd4b5fcab2f8


signature.asc
Description: Digital signature
--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

[Peter Todd]

I've written a reference implementation and BIP draft for a new opcode,
CHECKLOCKTIMEVERIFY. The BIP, reproduced below, can be found at:


https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki

The reference implementation, including a full-set 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 opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin
scripting system that allows a transaction output to be made unspendable until
some point in the future.


==Summary==

CHECKLOCKTIMEVERIFY re-defines the existing NOP2 opcode. When executed it
compares the top item on the stack to the nLockTime field of the transaction
containing the scriptSig. If that top stack item is greater than the transation
nLockTime the script fails immediately, otherwise script evaluation continues
as though a NOP was executed.

The nLockTime field in a transaction prevents the transaction from being mined
until either a certain block height, or block time, has been reached. By
comparing the argument to CHECKLOCKTIMEVERIFY against the nLockTime field, we
indirectly verify that the desired block height or block time has been reached;
until that block height or block time has been reached the transaction output
remains unspendable.


==Motivation==

The nLockTime field in transactions makes it possible to prove that a
transaction output can be spent in the future: a valid signature for a
transaction with the desired nLockTime can be constructed, proving that it is
possible to spend the output with that signature when the nLockTime is reached.
An example where this technique is used is in micro-payment channels, where the
nLockTime field proves that should the receiver vanish the sender is guaranteed
to get all their escrowed funds back when the nLockTime is reached.

However the nLockTime field is insufficient if you wish to prove that
transaction output ''can-not'' be spent until some time in the future, as there
is no way to prove that the secret keys corresponding to the pubkeys controling
the funds have not been used to create a valid signature.


===Escrow===

If Alice and Bob jointly operate a business they may want to
ensure that all funds are kept in 2-of-2 multisig transaction outputs that
require the co-operation of both parties to spend. However, they recognise that
in exceptional circumstances such as either party getting "hit by a bus" they
need a backup plan to retrieve the funds. So they appoint their lawyer, Lenny,
to act as a third-party.

With a standard 2-of-3 CHECKMULTISIG at any time Lenny could conspire with
either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer
not to have immediate access to the funds to discourage bad actors from
attempting to get the secret keys from him by force.

However with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of
the form:

IF
 CHECKLOCKTIMEVERIFY DROP
 CHECKSIGVERIFY
1
ELSE
2
ENDIF
  2 CHECKMULTISIG

At any time the funds can be spent with the following scriptSig:

  0

After 3 months have passed Lenny and one of either Alice or Bob can spend the
funds with the following scriptSig:

  1


===Non-interactive time-locked refunds===

There exist a number of protocols where a transaction output is created that
the co-operation of both parties to spend the output. To ensure the failure of
one party does not result in the funds becoming lost refund transactions are
setup in advance using nLockTime. These refund transactions need to be created
interactively, and additionaly, are currently vulnerable to transaction
mutability. CHECKLOCKTIMEVERIFY can be used in these protocols, replacing the
interactive setup with a non-interactive setup, and additionally, making
transaction mutability a non-issue.


Two-factor wallets

Services like GreenAddress store Bitcoins with 2-of-2 multisig scriptPubKey's
such that one keypair is controlled by the user, and the other keypair is
controlled by the service. To spend funds the user uses locally installed
wallet software that generates one of the required signatures, and then uses a
2nd-factor authentication method to authorize the service to create the second
SIGHASH_NONE signature that is locked until some time in the future and sends
the user that signature for storage. If the user needs to spend their funds and
the service is not available, they wait until the nLockTime expires.

The problem is there exist numerous occasions the user will not have a valid
signature for some or all of their transaction outputs. With
CHECKLOCKTIMEVERIFY rather than creating refund signatures on demand
scriptPubKeys of the following form are used instead:

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

[Peter Todd]

-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 another minor release or two.


On 1 October 2014 11:29:48 GMT-04:00, Sergio Lerner  
wrote:
>I like the proposal.
>
>I suggest that applications and nodes should only broadcast
>transactions
>having OP_CHECKLOCKTIMEVERIFY a few blocks after the timeout value.
>If a node broadcasts a TX having OP_CHECKLOCKTIMEVERIFY and nLockTime
>is
>equal to the current height and equal to the timeout value, but that
>peer is one block behind in the blockchain, the transaction will be
>rejected by the peer and the source will be banned.
>
>Another option will be not to ban peers sending transactions failing to
>verify OP_CHECKLOCKTIMEVERIFY , but I don't like this.
>
>Still another option would be that the sender checks periodically the
>height of it's peers (using the version command) in order to be sure to
>send the transaction having OP_CHECKLOCKTIMEVERIFY only to the peers
>that are up to date with the blockchain.
>
>Regards,
> Sergio.
>
>
>
>
>--
>Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS
>Reports
>Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>___
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJULDR7MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhS8ACADKQYHqOvmKJBYv+ZZM
Vs6358sMEtHGIEoTEjPio/vGbM0TkCGvRAnvzXDYz20WQcQsWZ4jflP1BihdbszE
NrQ+4JYm11Sw6vK5RpxeI4rJSb/hMUJooR0WQn8TOSZowtVxhINUnBku+N21Dhuf
IBCzji5bW2wjeN50psWOjJkBo1gZP761tjfmpI9kdNFe6RYIceAIWIIhccKX4PhA
FucuPawjB8+Ajd707UGHew82VHbXis+6Oxzob7hVJRH/wNKpkR6LXRxh2dwVaRAw
/Eytbt8LZRcRZGNXvMZ4GKG0xP79cBQI30QhrgM88gGyioMxrWcP2hVhtADOVl40
E4yh
=C9fu
-END PGP SIGNATURE-


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

[Peter Todd]

-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. 
scriptPubKey would be:

GET-TXIN-BLOCKHEIGHT-EQUALVERIFY

(fails unless top stack item is equal to the txin block height)

 ADD

(top stack item is now txin height + delta height)

CHECKLOCKTIMEVERIFY

> A limitation of encoding the
>target
>height/time directly, is that miners may choose not to mine the first
>transaction until they can also take the "burn to fee". So, one may
>prefer to
>say "cannot be spent until 100 blocks after the first transaction is
>mined",
>in effect reproducing the generation maturity rule.

You'd want these sacrifices to unlock years into the future to thoroughly 
exceed any reasonable business cycle; that's so far into the future that miners 
are almost certain to just mine them and collect the fees.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJULJa7MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhYlFB/4r2Hv82RK85BDe+hAT
ZQJtzXv1JRCa+o7Y344unMJ8y7rSDJRFSH+X+4VeCln833XKb8FNgj2loniQAq5H
FIH04gPf7yuXvDrKI6HwCj9Q3KLPv4UZM1+LjijczOM/y4e/C82squpTpgFaton+
6VXU/WyaCDYDS4he975E14YhBBVhoadZZMOW3Moxgpnde2RwAYZdkcdhqvh/3dJC
/9VOEUBu0ENyraL5HHGdZyjSJT2MsY4CBTCCd54RxBBMoMZqFRvIi4Xrt2vE1T+Y
R2DtKs7upjydnfg9KPm484upvO2U3lcnPBW9rqOVQyV2q81TcloRtUIU4QQ9GCAk
ayj2
=p0BG
-END PGP SIGNATURE-


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

[Peter Todd]

-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.

No, the redeemScript has to be provably published to miners for the sacrifice 
to be valid; if not you can exploit the scheme by hiding the redeemScript and 
having a big miner mine it at lower-than-face-value cost when it unlocks.

>Only after at least one confirmation, if there was some risk that
>revealing
>the redeeming script would make miners refuse to mine that first
>transaction because they want to get it plus the CHECK TIME BLOCK VERIFY
>"burn"
>transaction.

Yes, you could do that in a followup tx containing the redeemScript in an 
OP_RETURN output to prove publication. That said as I said to Luke-Jr, the 
sacrifices need to unlock pretty far into the future, so I don't see miners 
bothering to do this.





-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJULJiDMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhTwKCACD+GWzID7Qhn2no1p9
KYNiYlQVNt+DPZY0QB7MujL8riAmyJBliF9zptfjEdvglShoIzonJien/DOCjp9S
Lw2wMvPhtZGgSttJEvlr3wclty6TfWygd4Y+v/MR8TnYC99su7HhiQ1pkqohkklv
RxeF9jXhcJMERzN6wPUyeowfziBAfbWw+M5CwiXRlzLLBWO37eoDTXzUD0Np5Nia
nFxQ7sAsSbLijVpvigh9uIi3/1347VqwMc+0ZsZoZ2AnMICA8Q+XKNHv7DKpChxw
Xa+P532Di34uu8dlG/Z/UwYdENvb15P1yUZ7CEDfqNqrZp0RM7x+XKMA7QPwhuz3
YSBp
=mvKP
-END PGP SIGNATURE-


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

[Peter Todd]

-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) benefits of having this outweigh risks
>b) we're all happy with exact semantics
>
>Then we can have a knock-down drag-out argument about whether it should
>roll out as a soft fork, wait for a hard fork, be combined with some
>other
>things that it would be nice to add or change, etc.

Agreed. People should keep in mind that leaving the deployment details as "TBD" 
was quite deliberate. There is some code in the repo to implement a softfork, 
but it's only meant to be illustrative.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJULKT9MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhevAB/0eTWleef5GehrH03tZ
NrOdtJ881NhXJpB3p81jPyT9z4gv9u3M5bkjMOvClQaf8PX551ICgKbWDQTNf9oS
TF/blkqWRWX28VLkNsMUQNN/dd7rdqDMpnwcN8worgHToRMa4drFBU/MXapedMLQ
Sb2ETXGYPm4b/HqgFf9j/EGt8jhmnk4HiSwZ6wdhdYLbbZ6NhplSR8tTs+GouAWp
PHntN6DQI8oFDaIKkMbs2dDlpXSGG9hxr6m46LBwp/CHBY9aKkwLyaJXkMVovP3J
HrSYTzlCmjrDNbLJwIze+fyO2UDkgZUzjVENfMvixcQNdz0pVoCzJ2BK8b4fAc7Y
maRA
=Mz3E
-END PGP SIGNATURE-


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

[Peter Todd]

-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 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.
>> scriptPubKey would be:
>> GET-TXIN-BLOCKHEIGHT-EQUALVERIFY
>> (fails unless top stack item is equal to the txin block height)
>>  ADD
>> (top stack item is now txin height + delta height)
>> CHECKLOCKTIMEVERIFY
>
>This sounds do-able, although it doesn't address using timestamps.

For timestamps replace "height" with "time" in the above example; the minimum 
block time rule will prevent gaming it.


>> You'd want these sacrifices to unlock years into the future to
>thoroughly
>> exceed any reasonable business cycle; that's so far into the future
>that
>> miners are almost certain to just mine them and collect the fees.
>
>For many use cases, short maturity periods are just as appropriate IMO.

Very easy to incentivise mining centralisation with short maturities. I 
personally think just destroying coins is better, but it doesn't sit well with 
people so this is the next best thing.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o
JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV
f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb
63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr
1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm
vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq
SOgO
=WybM
-END PGP SIGNATURE-


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

[Peter Todd]

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 inattentive,
> now-inconsequential miners.
> 
> There is some headroom built in for just that... less disruptive
> upgrades that don't require 100%.

Anyway the stuff Mike is saying about being able to detect upgrades is
incorrect - detecting an upgrade is *easier* with a soft-fork, just look
at the block header nVersion numbers and warn the user if they increase
beyond what you know is valid. Bitcoin Core implements this IIRC, and
bitcoinj should.

Someone with more time should write all this up for the bitcoin.org
developer docs BTW... There's extensive discussions on #bitcoin-dev and
others about all of this.

-- 
'peter'[:-1]@petertodd.org
12367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622


signature.asc
Description: Digital signature
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

[Peter Todd]

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 have to resort to extra dependent
> > transaction(s) (and work-around malleability until that is fully
> > fixed) just to get the effect.
> 
> Right, ... moreover, even with all the malleability fixes, they only
> work if you refrain from using certain features (e.g. cannot do an
> anyone-can-pay) and we cannot be completely sure all accidental
> vectors for malleability are gone (we've been unable to construct a
> proof that our strengthening of ECDSA turns it into a strong
> signature, though it seems likely).
> 
> Having the locktime control in a scriptPubKey sidesteps all those
> limitations and simplifies protocols (e.g. not requiring some three
> step state machine and a bunch of risky validation code to be sure a
> refund you receive is actually workable).

Speaking of, can anyone think of an example of a complex transaction
use-case that is affected by malleability which can't be fixed by
CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head
trying to think of a good example.

-- 
'peter'[:-1]@petertodd.org
12367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622


signature.asc
Description: Digital signature
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Malleable booleans

[Peter Todd]

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 sign bit when interpreting as a number) is
> interpreted as true, anything else as false. Other than numbers,
> they're not even restricted to 4 bytes. Worse, the code for dealing
> with booleans is not very consistent: OP_BOOLAND and OP_BOOLOR first
> interpret their arguments as numbers, and then compare them to 0 to
> turn them into boolean values.
> 
> This means that scripts that use booleans as inputs will be inherently
> malleable. Given that that seems actually useful (passing in booleans
> to guide some OP_IF's during execution of several alternatives), I
> would like to change BIP62 to also state that interpreted booleans
> must be of minimal encoded size (in addition to numbers).
> 
> Any opinions for or against?

I noticed this awhile back myself. More interestingly, I remember
noticing some non-std scripts on mainnet that had opcodes that appeared
to be attempts to solve this issue with variations of the following:

DUP
IF
1 EQUALVERIFY

ELSE
0 EQUALVERIFY

ENDIF

I'll have to admit, I decided to keep quiet about it because it's a good
example of how relying on BIP62 for specialty contract applications that
absolutely need to avoid malleability for security reasons is a dubious
idea; it's hard to be sure that we've really gotten every relevant case
correct.

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 transaction manually to spend the output, preventing funds
from getting lost. Meanwhile in the general case of a compenent script
author having the canonical bool testing in every boolean-using opcode
saves a lot of bytes.

-- 
'peter'[:-1]@petertodd.org
147fe2005d7d4490938a7ab96901b8256dcd9d4eac78cb8c


signature.asc
Description: Digital signature
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Malleable booleans

[Peter Todd]

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 transaction manually to spend the output, preventing funds
> > from getting lost. Meanwhile in the general case of a compenent script
> > author having the canonical bool testing in every boolean-using opcode
> > saves a lot of bytes.
> 
> The real question is whether there are use cases for not having this
> requirement. I can't come up with any, as that would imply a boolean
> that is also interpretable as a hash, a pubkey or a signature - all of
> which seems crpytographically impossible to ever result in false.

I'm kinda inclined to agree, however there is an opposing argument too:
How often is BOOLAND and BOOLOR applied to unsanitised input from the
scriptSig? I can't think of a script type where that would be the case,
unlike OP_IF where the logical way of writing scripts is to have the
scriptSig select which brance you take. In every script I've ever
thought of BOOLAND and BOOLOR is applied to stuff generated within the
script itself, which isn't a malleability concern.

-- 
'peter'[:-1]@petertodd.org
05f3f265a1636bd90c2c8098093c2db2ccfc91c17890a714


signature.asc
Description: Digital signature
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP process

[Peter Todd]

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 with a non-google
> address if google has any hint that your address is associated with a
> gmail account.  Quite frustrating.

I'll second that request. Something mailman based; don't particularly
care where it's hosted.

After all, one of the big advantages of open mailing lists is that
multiple third-parties can easily provide archives, for instance
www.mail-archive.com

-- 
'peter'[:-1]@petertodd.org
0a91d3bbf16d2b80e142f98e6ff45b615f668dba558a4413


signature.asc
Description: Digital signature
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP process

[Peter Todd]

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 frustrating.
> 
> 
> Mailman is good enough...

I used these guys for awhile to host a small mailman list with
absolutely no issues. Just $5/month for 1000 subscribers.

https://www.mailmanlist.net/

-- 
'peter'[:-1]@petertodd.org
19e75ca8667f175b61a41ad950d15b61d83d3faf1a128f94


signature.asc
Description: Digital signature
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

[Peter Todd]

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 instance see @cozz in Issue 4866
> .

I don't have time to look at the details of your statistical methods
unfortunately due to some deadlines, but a quick comment:

You should think about the malleability of your estimates to attackers.
For instance the current fee estimation code has a serious issue where
it'll happily estimate ludicriously high fees based on very little date.
There is a 'insane fees' failsafe, but it's IIRC set to allow
transactions with fees of less than 100mBTC/tx, roughly $50 at current
exchange rates. It's relatively easy to get a wallet into a condition
where this happens as the estimations are considered valid even based on
very little data - a simple sybil attack suffices. (e.g. the recently
published paper(1) on Tor sybil attacks comes to mind as one example of
many ways to do this) Obviously this could empty someone's wallet pretty
quickly; an exchange that makes a few dozen transactions an hour could
easily lose tens of thousands of dollars due to this exploit. Someone
correct me if I'm wrong, but last I checked in git HEAD this exploit is
still unfixed.

A user-configurable failsafe limit is a pretty obvious solution here,
albeit a crude one; it'd be interesting to see if a plausible security
argument could be made for something more sophisticated, like taking
into account coin-age of observed transactions that estimates are based
on.

1) "Bitcoin over Tor isn't a good idea",
   http://arxiv.org/abs/1410.6079

-- 
'peter'[:-1]@petertodd.org
098d3c9095b47ff1fd692fef5ac6731340802c7c63d38bb0


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP62 and future script upgrades

[Peter Todd]

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 before) the second stage evaluation.
> Otherwise it would reject all spends from P2SH (which rely on
> "superfluous" inputs to pass data to the second stage).
> 
> I submitted a Pull Request to clarify this in BIP62:
> https://github.com/bitcoin/bips/pull/115
> 
> However, this also leads to the interesting observation that the
> clean-stack rule is incompatible with future P2SH-like constructs -
> which would be very useful if we'd ever want to deploy a "Script 2.0".
> Any such upgrade would suffer from the same problem as P2SH, and
> require an exception in the clean-stack rule, which - once deployed -
> is no longer a softfork.
> 
> Luke suggested on the pull request to not apply this rule on every
> transaction with nVersion >= 3, which indeed solves the problem. I
> believe this can easily be generalized: make the (non mandatory) BIP62
> rules only apply to transaction with strict nVersion==3, and not to
> higher ones. The higher ones are non-standard anyway, and shouldn't be
> used before there is a rule that applies to them anyway - which could
> include some or all of BIP62 if wanted at that point still.
> 
> Opinions?

I agree with Luke: make the rules only apply to transactions with a
strict nVersion==3. If we want to extend that later we can do so in
another soft-fork.


On another topic, I'm skeptical of the choice of nVersion==3 - we'll
likely end up doing more block.nVersion increases in the future, and
there's no reason to think they'll have anything to do with
transactions. No sense creating a rule that'll be so quickly broken.

-- 
'peter'[:-1]@petertodd.org
02986604739bc94cc42d5c6adf75186e80ba3dbb501a076d


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP62 and future script upgrades

[Peter Todd]

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
> >> likely end up doing more block.nVersion increases in the future, and
> >> there's no reason to think they'll have anything to do with
> >> transactions. No sense creating a rule that'll be so quickly broken.
> >
> > Moderately agreed.
> >
> > Earlier in BIP 62 lifetime, I had commented on ambiguity that arose
> > from bumping tx version simply because we were bumping block version.
> > The ambiguity was corrected, but IMO remains symptomatic of potential
> > problems and confusion down the road.
> >
> > Though I ACK'd the change, my general preference remains to disconnect
> > TX and block version.
> 
> I prefer to see consensus rules as one set of rules (especially
> because they only really apply to blocks - the part for lone
> transactions is just policy), and thus have a single numbering. Still,
> I have no strong opinion about it and have now heard 3 'moderately
> against' comments. I'm fine with using nVersion==2 for transactions.

Keep in mind that we may even have a circumstance where we need to
introduce *two* different new tx version numbers in a single soft-fork,
say because we find an exploit that has two different fixes, each of
which breaks something.

I don't think we have any certainty how new features will be added in
the future - just look at how we only recently realised new opcodes
won't be associated with tx version number bumps - so I'm loath to setup
expectations.

Besides, transactions can certainly be verified for correctness in a
stand-alone fashion outside a block; CHECKLOCKTIMEVERIFY was
specifically designed so that verifying scripts containing it could be
done in a self-contained manner only referencing the transaction the
script was within.

-- 
'peter'[:-1]@petertodd.org
036655c955dd94ba7f9856814f3cb87f003e311566921807


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT

[Peter Todd]

So right now git head will accept the following invalid transaction into
the mempool:

010001140de229e08fda25cbc16ded2618cdacce49fcb18c0b6ccdace00040909adae49000493046022100f7828d81c849c5448ba5ba4ef55df6b4d0ba3ae3f1a59cff3291880c2c8e524f022100d2f5bc9dc2f0674eded31023cb47e61a596e10f8f1ddd44cf92d290c9db577c70144410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455ac9101102717a914e661a2229cc824329c9409f49d99cb5ac350c92887

which spends the redeemScript:

0778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455
CHECKSIG NOT

That pubkey is valid and accepted by OpenSSL as it's obscure "hybrid"
format. The transaction is invalid because the signature is correct,
causing CHECKSIG to return 1, which is inverted to 0 by the NOT.

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 the transaction. Similar to the invalid due to too
many sigops DoS attack I found before, this lets you fill up the mempool
with garbage transactions that will never be mined. OTOH I don't see any
way to exploit this in a v0.9.x IsStandard() transaction, so we haven't
shipped code that actually has this vulnerability. (dunno about
alt-implementations)

I suggest we either change STRICTENC to simply fail unrecognized pubkeys
immediately - similar to how non-standard signatures are treated - or
fail the script if the pubkey is non-standard and signature verification
succeeds.

Thoughts?

-- 
'peter'[:-1]@petertodd.org
152dc55f27338b58325f0432d2dc6edb90c8d449d9959583


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT

[Peter Todd]

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:
> 
> 010001140de229e08fda25cbc16ded2618cdacce49fcb18c0b6ccdace00040909adae49000493046022100f7828d81c849c5448ba5ba4ef55df6b4d0ba3ae3f1a59cff3291880c2c8e524f022100d2f5bc9dc2f0674eded31023cb47e61a596e10f8f1ddd44cf92d290c9db577c70144410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455ac9101102717a914e661a2229cc824329c9409f49d99cb5ac350c92887
> 
> which spends the redeemScript:
> 
> 0778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455
> CHECKSIG NOT

...and while we're at it, bitcoin-ruby's forked yet again...

-- 
'peter'[:-1]@petertodd.org
152dc55f27338b58325f0432d2dc6edb90c8d449d9959583


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT

[Peter Todd]

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,
> > rather than failing the transaction. Similar to the invalid due to too
> > many sigops DoS attack I found before, this lets you fill up the mempool
> > with garbage transactions that will never be mined. OTOH I don't see any
> > way to exploit this in a v0.9.x IsStandard() transaction, so we haven't
> > shipped code that actually has this vulnerability. (dunno about
> > alt-implementations)
> 
> Yeah, there's even a comment in script/interpreter.h currently about
> how STRICTENC is not softfork safe.

Indeed.

I actually was thinking about SCRIPT_VERIFY_MINIMALDATA, CScript(), and
FindAndDelete() Specifically that if you were to change CScript() to
convert single-character PUSHDATA's to OP_ you'd be making a
consensus-critical change due to how FindAndDelete() is called with a a
CScript() signature. You didn't make that mistake, and I couldn't find a
way to exploit it anyway, but it reminded me of this STRICTENC stuff.

> I didn't realize that this would
> lead to the mempool accepting invalid transactions (I thought there
> was a second validity check with the actual consensus rules; if not,
> maybe we need to add that).

It should be enough to just duplicate the CheckInputs() call in
the AcceptToMemoryPool() function:

if (!CheckInputs(tx, state, view, true, STANDARD_SCRIPT_VERIFY_FLAGS, true))
{
return error("AcceptToMemoryPool: : ConnectInputs failed %s", 
hash.ToString());
}
if (!CheckInputs(tx, state, view, true, MANDATORY_SCRIPT_VERIFY_FLAGS, 
true))
{
return error("AcceptToMemoryPool: : BUG FOUND Standard verify flags 
passed yet mandatory flags failed. %s", hash.ToString());
}


> > I suggest we either change STRICTENC to simply fail unrecognized pubkeys
> > immediately - similar to how non-standard signatures are treated - or
> > fail the script if the pubkey is non-standard and signature verification
> > succeeds.
> 
> Sounds good to me, I disliked those semantics too.

Ok, then given we have to support hybrid encoding for awhile longer
anyway - I noticed your secp256k1 library supports it - lets do the
latter as a "least invasive" measure. I can't think of any case where
that'd be triggered other than delibrately. Doing that should make
STRICTENC a soft-fork-safe change, and we can decide at a later date if
we want to get rid of hybrid-encoded pubkeys in a further tightening of
the rules.

-- 
'peter'[:-1]@petertodd.org
19b3c625f667bd0b93011c0a37950545a6a8fccf0b08ae73


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

[Peter Todd]

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 to a bug that others reject,
you're forked and the world ends.

Long answer... well you reminded me I've never actually written up a good
example for others, and a few people have asked me for one. A great example of
this is the SIGHASH_SINGLE bug in the SignatureHash() function:

uint256 SignatureHash(CScript scriptCode, const CTransaction& txTo, 
unsigned int nIn, int nHashType)
{



else if ((nHashType & 0x1f) == SIGHASH_SINGLE)
{
// Only lock-in the txout payee at same index as txin
unsigned int nOut = nIn;
if (nOut >= txTmp.vout.size())
{
printf("ERROR: SignatureHash() : nOut=%d out of range\n", nOut);
return 1;
}


}



// Serialize and hash
CHashWriter ss(SER_GETHASH, 0);
ss << txTmp << nHashType;
return ss.GetHash();
}

So that error condition results in SignatureHash() returning 1 rather than the
actual hash. But the consensus-critical code that implements the CHECKSIG
operators doesn't check for that condition! Thus as long as you use the
SIGHASH_SINGLE hashtype and the txin index is >= the number of txouts any valid
signature for the hash of the number 1 is considered valid!

When I found this bug¹ I used it to fork bitcoin-ruby, among others.
(I'm not the first; I found it independently after Matt Corallo) Those
alt-implementations handled this edge-case as an exception, which in
turn caused the script to fail. Thus they'd reject blocks containing
transactions using such scripts, and be forked off the network.

You can also use this bug for something even more subtle. So the
CHECKSIG* opcode evaluation does this:

// Drop the signature, since there's no way for a signature to sign itself
scriptCode.FindAndDelete(CScript(vchSig));

and CHECKMULTISIG* opcode:

// Drop the signatures, since there's no way for a signature to sign itself
for (int k = 0; k < nSigsCount; k++)
{
valtype& vchSig = stacktop(-isig-k);
scriptCode.FindAndDelete(CScript(vchSig));
}

We used to think that code could never be triggered by a scriptPubKey or
redeemScript, basically because there was no way to get a signature into a
transaction in the right place without the signature depending on the txid of
the transaction it was to be included in. (long story) But SIGHASH_SINGLE makes
that a non-issue, as you can now calculate the signature that signs '1' ahead
of time! In a CHECKMULTISIG that signature is valid, so is included in the list
of signatures being dropped, and thus the other signatures must take that
removal into account or they're invalid. Again, you've got a fork.

However this isn't the end of it! So the way FindAndDelete() works is as
follows:

int CScript::FindAndDelete(const CScript& b)
{
int nFound = 0;
if (b.empty())
return nFound;
iterator pc = begin();
opcodetype opcode;
do
{
while (end() - pc >= (long)b.size() && memcmp(&pc[0], &b[0], 
b.size()) == 0)
{
pc = erase(pc, pc + b.size());
++nFound;
}
}
while (GetOp(pc, opcode));
return nFound;
}

So that's pretty ugly, but basically what's happening is the loop iterates
though all the opcodes in the script. Every opcode is compared at the *byte*
level to the bytes in the argument. If they match those bytes are removed from
the script and iteration continues. The resulting script, with chunks sliced
out of it at the byte level, is what gets hashed as part of the signature
checking algorithm.

As FindAndDelete() is always called with CScript(vchSig) the signature
being found and deleted is reserialized. Serialization of bytes isn't
unique; there are multiple valid encodings for PUSHDATA operations. The
way CScript() is called the most compact encoding is used, however this
means that if the script being hashed used a different encoding those
bytes are *not* removed and thus the signature is different.

Again, if you don't get every last one of those details exactly right, you'll
get forked.

...and I'm still not done! So when you call CScript(vchSig) the relevant code
is the following:

class CScript : public std::vector
{



explicit CScript(const CScriptNum& b) { operator<<(b); }



CScript& operator<<(const std::vector& b)
{
if (b.size() < OP_PUSHDATA1)
{
insert(end(), (unsigned char)b.size());
}
else if (b.size() <= 0xff)
{
insert(end(), OP_PUSHDATA1);
insert(end(), 

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

[Peter Todd]

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. While redoing Bitcoin in a hardfork is nice,
> its a very long-term thing, so I'm not sure about making people wait for
> a large hardfork just to use payment channels.

BIP62 is a less-than-ideal way of making contracts secure against
malleability as it relies on a "whack-a-mole" approach to security that
is insecure if any flaw is missed. If you only wanted to make contracts
secure, you'd either implement a new SignatureHash() that could leave
out the prevout field in favor of hashing the previous input's CTxOut()
structure, and/or implement the significantly more limited
CHECKLOCKTIMEVERIFY.

Equally BIP62 fails at making more complex types of contracts secure.
For instance suppose I had a multi-step protocol that required more than
two transactions:

tx1: Alice -> (Alice, Bob)
tx1_refund: (Alice, Bob) -> Alice

tx2: (Alice, Bob) -> Charlie
tx2_refund: (Alice, Bob) -> Bob

tx1 can only be modified by Alice, so tx1_refund is secure. However the
second stage, where the output of tx1 is spent by tx2, with a refund
transaction giving the funds back to Bob, can't be made secure as BIP62
can't prevent Alice from changing her signature, getting tx2' mined
instead, and making tx2_refund invalid.

OTOH a new form of signature hash that was a signature on tx2.vout
structure rather than it's txid would be secure, as tx2_refund would be
valid regardless of tx2's actual txid.

Obviously there are good reasons to not use such signature hashes in the
general case, as they imply you can't reuse scriptPubKeys securely, but
that's a minor problem for purpose-built contract protocols. It's
certainly a much more minor problem then the huge number of holes
possible with BIP62.

BIP62 does make life easier for wallet authors as they don't have to
deal with malleability - maybe! - but for contracts it's a bad design.

> Also, I echo the difficulty of writing consensus-compatible code and
> highly suggest anyone with money behind an implementation that is doing
> script verification in code that isnt Bitcoin Core rethink that decision.

FWIW I've done due-dilligence reviews for investors on projects and
companies that have re-implemented Bitcoin Core consensus-critical code,
and every time my review lists doing so as a major red flag.

-- 
'peter'[:-1]@petertodd.org
166801ed3959dde6b7d979735c290e7c4271ae3cf75ced63


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

[Peter Todd]

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 problems not otherwise solvable with a
> hard fork.  However, hard forks clearly have risks, notably the Big
> Risk akin to a US Constitutional Convention:  once you open the door,
> anything can happen, any rule no matter how "sacred" can be changed.

I think people in this community often miss the serious political and
legal ramifications of hard-forks. Being in the social position of being
able to succesfully pull off hard-forks, particularly for new features,
is clear evidence that you have de-facto control over the system.
Regulators around the world appear to be going in directions that would
make that control subject to regulation and licensing, e.g. the European
Banking Association proposals, and initial Bitlicense proposals.

Equally, look how hard-forks - known as flag days elsewhere - are
generally considered to be dangerous and worth avoiding in other
contexts due to simple engineering reasons. It's just easier to upgrade
systems in backward compatible ways, especially when they incorporate
features specifically to make that possible. (as does bitcoin!)

> Soft forks are not without their own risks, e.g. reducing some things
> to SPV levels of security.

This is a misconception; you can't prevent soft-forks from happening, so
you always have an SPV level of security by that standard.

People put *way* too much trust in small numbers of confirmations...

-- 
'peter'[:-1]@petertodd.org
0094d543907eaf0f94f4ff5f4c760b3552d84ff811cd9053


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

[Peter Todd]

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 problems to worry about.

Flag days are really rare in engineering, and for good reason.

-- 
'peter'[:-1]@petertodd.org
08f2290924a6882928d4566f487f33cc57203a6535795201


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

[Peter Todd]

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 bugs: either as part of a
> controlled, planned, and managed process, or as a response to an
> immediate disaster.
> 
> The alternative to scheduling and planning the upgrades which are
> necessary to fix the bugs in the protocol, where such fixes can be
> written, tested, and documented at leisure, is to wait for some crisis
> and slap on another bandaid when the network breaks again (like it did
> March of last year).

The protocol is what the protocol is; the bugs are when you don't match
the protocol.

> Who benefits from not fixing bugs in Bitcoin?

We can bring up politics if you want.

In the current model, the specification *is* the protocol, and the
Bitcoin Core team is scared to death of changing anything; they've got
very little real power. Soft-forks are the minimum-viable way of making
changes to the protocol, and it's very clear how they get adopted:
minerr consensus. They're also a fundemental way of changing the
protocol that is impossible to prevent, so you might as well use it.

Hard-forks require political consensus to achieve, and the way you
create that political consensus is by creating committes, groups,
associations... Foundations. Every last one of those things requires
centralization and political power.

You know, the smartest thing the Bitcoin Foundation could do if they
wanted to cement their place in the Bitcoin ecosystem as a power broker
would be to setup a program of periodic hard-forks, say every year or
two, and then manage the committees that decide what goes into those
hard-forks. That they haven't suggested that yet is a sign that they're
either not evil, or they don't understand Bitcoin very well.

I think programmers find this reality hard to accept, because they're
mostly interested in writing code that'll get widely used. To them it's
hard to accept that the Bitcoin protocol *is* a few thousand lines of
C++ code, and they're not good enough to write their own implementation
and make it match; if we replaced programmers with writers we might get
the equally bizzare and pointless situation of people taking perfectly
good RFCs and rewriting them in their own words.

If you do care about keeping the politics of Bitcoin development free
from centralized control you should do what I advised the Dark Wallet
team to do a year ago: fork Bitcoin Core and change the
non-consensus-critical code that implements policy. I've done this
myself in a minor way with my replace-by-fee(1) version. Luke-Jr has
also done this with his Eligius branch, a fork that something like 30%
of the Bitcoin hashing power appear to run. (Discus Fish has been mining
non-standard transactions(2) lately)

Multiple *forks* of the Bitcoin Core reference client that are actually
getting used by miners and other users ensures that no one group
maintaining such a fork has the ability to change anything without
strong consensus. Forking the codebase, rather than rewriting it, best
ensures that your code actually implements the protocol properly, is
safe to use for mining, and actually gets used.

Rewriting Bitcoin Core is a fun project, but it's terrible politics.

1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.3
2) 
https://blockchain.info/tx/e24a4085c54a6362e615f8eab758c12d80e488b73757e6d2b8ab6bfc8be7007e

-- 
'peter'[:-1]@petertodd.org
08f2290924a6882928d4566f487f33cc57203a6535795201


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

[Peter Todd]

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 a mistake, not
intentionally.

Of course, that's not including the two serious soft-fork proposals in
the air right now, Pieter Wuille's BIP62 and my CHECKLOCKTIMEVERIFY.
However dealing with proposed changes like those in an environment where
the competing implementations all use essentially the same
consensus-critical code is much easier than in an environment where they
don't; I say this on both a technical and political level.

-- 
'peter'[:-1]@petertodd.org
0c901eb1b6b765519b99c3afd7a9062ff4cfa29666ce140d


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

[Peter Todd]

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. First step is a
stand-alone script verification library:

https://github.com/theuni/bitcoin/blob/da18a0266c4de76c2a461cc2984aa2fa066c42f5/src/script/bitcoinconsensus.h

#ifndef H_BITCOIN_BITCOINCONSENSUS
#define H_BITCOIN_BITCOINCONSENSUS

#if defined(BUILD_BITCOIN_INTERNAL) && defined(HAVE_CONFIG_H)
#include "config/bitcoin-config.h"
  #if defined(_WIN32)
#if defined(DLL_EXPORT)
  #if defined(HAVE_FUNC_ATTRIBUTE_DLLEXPORT)
#define EXPORT_SYMBOL __declspec(dllexport)
  #else
#define EXPORT_SYMBOL
  #endif
#endif
  #elif defined(HAVE_FUNC_ATTRIBUTE_VISIBILITY)
#define EXPORT_SYMBOL __attribute__ ((visibility ("default")))
  #endif
#elif defined(MSC_VER) && !defined(STATIC_LIBBITCOINCONSENSUS)
  #define EXPORT_SYMBOL __declspec(dllimport)
#endif

#ifndef EXPORT_SYMBOL
  #define EXPORT_SYMBOL
#endif

#ifdef __cplusplus
extern "C" {
#else
#include 
#endif

/** Script verification flags */
enum
{
bitcoinconsensus_SCRIPT_FLAGS_VERIFY_NONE  = 0,
bitcoinconsensus_SCRIPT_FLAGS_VERIFY_P2SH  = (1U << 0), // evaluate 
P2SH (BIP16) subscripts
};

/// Returns true if the input nIn of the serialized transaction pointed to by
/// txTo correctly spends the scriptPubKey pointed to by scriptPubKey under
/// the additional constraints specified by flags.
EXPORT_SYMBOL bool bitcoinconsensus_verify_script(const unsigned char 
*scriptPubKey, const unsigned int scriptPubKeyLen,
const unsigned char *txTo, const 
unsigned int txToLen,
const unsigned int nIn, const unsigned int 
flags);

EXPORT_SYMBOL unsigned int bitcoinconsensus_version();

#ifdef __cplusplus
} // extern "C"
#endif

#undef EXPORT_SYMBOL

#endif // H_BITCOIN_BITCOINCONSENSUS

-- 
'peter'[:-1]@petertodd.org
01208038fd7130083ff118147890dbb37913ffa83c1f48cd


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...

[Peter Todd]

-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 draft. That said I think writing up some actual working 
examples, in code, of CHECKLOCKTIMEVERIFY using protocols is a bigger priority. 
Micropayment channels comes to mind, as well as a greenaddress-style wallet.

When I get a chance I'm going to rebase the initial implementation and add to 
it a command-line-flag to verify CHECKLOCKTIMEVERIFY as an IsStandard() rule 
for testing purposes.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJUd+luMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhWmcB/0UK030Q6TSpi95x0Gh
hGYaSAInUWpbZzZtP+1AFrGDGRdGo0glFFf8xggI+U5kuc0woPYrn/VEGcprPhvs
KQFZrirXVr7Q09TVlHiPDen5v3Y7xwL5kQDUrBPP71Pe3R2o6IbfdwxsZ8+yYso8
hY6WQmImQpKJd4gEd76w1QrF8Btl1Jz/PGh4EE3GSPGlflvBwA6igSiRoD/czb1x
63y4AsPEil2hrmIjTZHqwnl40BqnmZ8qpNLWeIEjE++pbkxLTjvUcPy03/wtTWZA
5dCGeY5WavgZsPazhSdaTtM5/7wPSQQ0PDXNHdHgmewkvbyBpy78orV/3bEG+xFz
2SWi
=4OmI
-END PGP SIGNATURE-


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Serialised P2SH HD chains

[Peter Todd]

-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 payments a
>single token
>> that can be used to generate many P2SH addresses paying to a multisig
>script.
>>
>> I'm thinking of something along the lines of a simple series of
>tokens, each
>> indicating either a HD chain or literal script content. For all HD
>chains in
>> the data, a child key would be generated based on the payment number,
>and all
>> tokens concatenated to form the P2SH serialised script. Eg, for a
>simple 2-
>> of-2, you would do something like this:
>>literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECKMULTISIG)
>> Does this sufficiently cover all reasonable use cases?
>
>
>What is the use case for something like this?  It’s my impression that
>a single token that can be used to obtain many P2SH addresses paying to
>a multisig script looks something like
>
>bitcoin:?r=https://payee.com/customer12345/recurring/paymentrequest/new
>
>As it’s impossible to actually transmit a tx without network access,
>why would it be necessary to, at payment time, not contact the payee
>and use the existing bip70 authenticated payment request protocol to
>find out exactly what multisig address they’d like paid at that moment?

It's quite common to run into situations where the payee is *not* online. 
Similarly requiring them to be online is a security risk and defeats many ways 
of authenticating payment addresses. This stuff isn't evident in trivial 
consumer<->merchant use-cases, but is very common in anything else. For 
instance, consider the case of moving funds from a hot wallet or cold, and 
vice-versa.

Luke-Jr: sounds like some of the ideas I've been playing around with for 
generalised stealth addresses, using a declarative template scheme to avoid 
specifying scriptPubKey formats too explicitly. (though obcs k-anon set issues)
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJUgMd0MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhRJjB/0fvNisFR4cktOhDJYl
nq2gb39aiV7Wufh7NcTI0mqsC1yhIgFW5fgl7TmiK76Tn4gH0rhfJe3u7GhVsmSy
Sx1qEJJN6yNsiu6elmLe8xISVTwHu+kLqKFTyZNrd4BObHVumyLAhea2lFSzZmBu
GQF/AnVzf06vAT8CnZZm3hMgt1kFv32KglIIWLdztvvgi7yK6fi2GlZUW1J+jCUk
6AyQbnpPkHPHIJe7UMM0oeC2w6cN5nH0ccIutwkYDHwo/APa0TkX1hu3bJh5/Cor
zh+BLdOYgAP28wUZ1fkQoAj/0l79+3wyBC7+6lblV90y7C68G6zqMav7lDZdsBK9
4DU0
=Atvv
-END PGP SIGNATURE-


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Setting the record straight on Proof-of-Publication

[Peter Todd]

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 give a
clear definition of proof-of-publication and its weaker predecessor
timestamping, describe some usecases for it, and finally dispel some of
the common myths about it.


What is timestamping?
=

A cryptographic timestamp proves that message m existed prior to some
time t.

This is the cryptographic equivalent of mailing yourself a patentable
idea in a sealed envelope to establish the date at which the idea
existed on paper.

Traditionally this has been done with one or more trusted third parties
who attest to the fact that they saw m prior to the time t. More
recently blockchains have been used for this purpose, particularly the
Bitcoin blockchain, as block headers include a block time which is
verified by the consensus algorithm.


What is proof-of-publication?
=

Proof-of-publication is what solves the double-spend problem.

Cryptographic proof-of-publication actually refers to a few closely
related proofs, and practical uses of it will generally make use of more
than one proof.


Proof-of-receipt


Prove that every member p in of audience P has received message m. A
real world analogy is a legal notice being published in a major
newspaper - we can assume any subscriber received the message and had a
chance to read it.


Proof-of-non-publication


Prove that message m has *not* been published. Extending the above real
world analogy the court can easily determine that a legal notice was not
published when it should have been by examining newspaper archives. (or
equally, *because* the notice had not been published, some action a
litigant had taken was permissable)


Proof-of-membership
---

A proof-of-non-publication isn't very useful if you can't prove that
some member q is in the audience P. In particular, if you are to
evaluate a proof-of-membership, q is yourself, and you want assurance
you are in that audience. In the case of our newspaper analogy because
we know what today's date is, and we trust the newspaper never to
publish two different editions with the same date we can be certain we
have searched all possible issues where the legal notice may have been
published.


Real-world proof-of-publication: The Torrens Title System
-

Land titles are a real-world example, dating back centuries, with
remarkable simularities to the Bitcoin blockchain. Prior to the torrens
system land was transferred between owners through a chain of valid
title deeds going back to some "genesis" event establishing rightful
ownership independently of prior history. As with the blockchain the
title deed system has two main problems: establishing that each title
deed in the chain is valid in isolation, and establishing that no other
valid title deeds exist. While the analogy isn't exact - establishing
the validity of title deeds isn't as crisp a process as simple checking
a cryptographic signature - these two basic problems are closely related
to the actions of checking a transaction's signatures in isolation, and
ensuring it hasn't been double-spent.

To solve these problems the Torrens title system was developed, first in
Australia and later Canada, to establish a singular central registry of
deeds, or property transfers. Simplifying a bit we can say inclusion -
publication - in the official registery is a necessary pre-condition to
a given property transfer being valid. Multiple competing transfers are
made obvious, and the true valid transfer can be determined by whichever
transfer happened first.

Similarly in places where the Torrens title system has not been adopted,
almost always a small number of title insurance providers have taken on
the same role. The title insurance provider maintains a database of all
known title deeds, and in practice if a given title deed isn't published
in the database it's not considered valid.


Common myths


Proof-of-publication is the same as timestamping


No. Timestamping is a significantly weaker primitive than
proof-of-publication. This myth seems to persist because unfortunately
many members of the Bitcoin development and theory community - and even
members of the Blockstream project - have frequently used the term
"timestamping" for applications that need proof-of-publication.


Publication means publishing meaningful data to the whole world
---

No. The data to be published can often be an otherwise meaningless
nonce, indistinguishable from any other random value. (e.g. an ECC
pubkey)

For example colored 

[Bitcoin-development] Near-zero fee transactions with hub-and-spoke micropayments

[Peter Todd]

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 second that Bitcoin can support.


So a micropayment channel enables a payor to incrementally pay a payee
by first locking a deposit of Bitcoins in a scriptPubKey of the
following form:

IF
 CHECKLOCKTIMEVERIFY OP_DROP
ELSE
 CHECKSIGVERIFY
ENDIF
 CHECKSIGVERIFY

(obviously many other forms are possible, e.g. multisig)

Once the funds are confirmed, creating txout1, the payor creates
transactions spending txout1 sending some fraction of the txout value to
the payee and gives that half-signed transaction to the payee. Each time
the payor wants to send more money to the payee they sign a new
half-signed transaction double-spending the previous one.

When the payee is satisfied they can close the channel by signing the
most recent, highest value, tx with their key, thus making it valid. If
the payee vanishes the payor can get all the funds back once the timeout
is reached using just their key.

Since confirmation is controlled by the payee once the initial deposit
confirms subsequent increases in funds sent happen instantly in that the
payor can not double-spend the input until the timeout is reached.

(there's another formulation from Jeremy Spilman that can be almost
implemented right now using a signed refund transaction, however it is
vulnerable to transaction mutability)


Hub-and-Spoke Payments
==

Using a nearly completely untrusted hub we can allow any number of
parties to mutually send and receive Bitcoins instantly with near-zero
transaction fees. Each participant creates one or two micropayment
channels with the hub; for Alice to send Bob some funds Alice first
sends the funds to the hub in some small increment, the hub sends the
funds to Bob, and finally the hub gives proof of that send to Alice. The
incremental amount of Bitcoins sent can be set arbitrarily low, limited
only by bandwidth and CPU time, and Bob does not necessarily need to
actually be online. The worst that the hub can do is leave user's funds
locked until the timeout expires.


Multiple Hubs
=

Of course, hubs can in turn send to each other, again in a trustless
manner; multiple hops could act as a onion-style privacy scheme. The
micropayments could also use an additional chaum token layer for
privacy, although note that the k-anonymity set involves a trade-off
between privacy and total # of Bitcoins that could be stolen by the hub.

Of course, in general the micropayment hub breaks the linkage between
payor and payee, with respect to the data available from the blockchain.


Capital Requirements


A business disadvantage with a hub-and-spoke system is that it ties up
capital, creating a tradeoff between fees saved and Bitcoins tied up.
How exactly to handle this is a business decision - for instance opening
the micropayment channel could involve a small initial payment to
account fo rthe time-value-of-money.


Embedded consensus/Colored coins


Note how many embedded consensus schemes like colored coins are
compatible with micropayment channels. (though have fun figuring out who
deserves the dividends!)

-- 
'peter'[:-1]@petertodd.org
12367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

[Peter Todd]

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 soft-fork, but you can do a hard-fork.
> Using scheduled updates: client simply stops working at a certain block,
> and user is required to download an update.

You're quite mistaken actually. One of the first things to come out of
my research as Mastercoin's Chief Scientist - indeed after a week on the
job - was how to safely upgrade embedded consensus systems in a
decentralized fashion:

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03890.html

To recap, where valuable scarce tokens are concerned we want to ensure
that an attacker can't use a fork caused by an upgrade to double-spend
tokens. We solve this problem by ensuring that when a token visible to
version V_i is spent in a V_{i+1} client, the token appears spent to
version V_i clients as well. This is easy to accomplish by a "split
transaction" scheme that separates all operations into separate
"increment" and "decrement" operations.

The simplest example of this principle in action is colored coins, which
are certainly an example of an embedded consensus system. Colored coin
implementations naturally ensure that all versions of the system see a
token getting spent the same way - the corresponding txout is spent! So
long as changes to the coloring rules are handled such that only one set
of rules - one version - can apply to a given txout spend we get
anti-doublespend protection.

The second aspect of the problem is the social/political implications of
upgrades - because embedded consensus systems don't outsource trust they
very clearly require the co-operation of the economic majority in an
upgrade. For instance if the community has two competing proposals for
how to upgrade version V1 of Counterparty, V2a and V2b, choosing to move
your tokens to either version becomes a vote with serious economic
consequences. In fact, it's quite possible that a community would choose
to simply fork into two different systems each offering a different set
of features. Equally in the event of such a fork someone can create a
third version, V3, that recombines the two incompatible forks. Again,
anyone who agrees with version V3 can choose to move their tokens to it,
healing the fork.

Arguably this process of handling forks by direct economic voting is
significantly *more* decentralized than Bitcoin's soft-fork mechanism as
adoption of a new version is something all participants in the system
play a part in equally. (as measured by economic stake) Of course, it
will lead to sometimes ugly political battles, but that's simply part of
the cost of having democratic systems.


> It looks like people make a cargo cult out of Bitcoin's emergent
> properties.

+1

-- 
'peter'[:-1]@petertodd.org
0681f4e5c84bc0bf7e6c5db8673eef225da652fbb785a0de


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

[Peter Todd]

On Sun, Dec 14, 2014 at 12:32:22AM +1100, Gareth Williams wrote:
> On 13/12/14 04:04, Alex Mizrahi wrote:
> > Well, client-side validation is mathematically secure, while SPV is
> > economically secure.
> > I.e. it is secure if you make several assumptions about economics of the
> > whole thing.
> 
> Comparisons with the SPV security of sidechains are fallacious. The
> alternative to a proof-of-publication system reliant on client-side
> validation is a blockchain. The question of whether the token used on
> said blockchain should be two-way-pegged to BTC is completely orthogonal.
> 
> (ie. yes, sidechains are "economically secure", in that you're reduced
> to balancing economic incentives to avoid peg theft. But sidechains also
> give us something unique in return - the ability to innovate without
> needing to start new artificial scarcity races. Nothing else can do that.)

I covered this in my original post: 1-way-pegs allow the creation of new
valuable tokens without those tokens being useful for speculation.

To recap, a 1-way-peg allows the conversion of Bitcoins to another token
by provably destroying the Bitcoins, thus capping the maximum possible
value of that token and ensuring the token can-not become an investment.
For owners of these tokens they can convert them back to Bitcoin by
selling them at a discount to buyers who would otherwise be able to
purchase them via provable destruction. A pragmatic implementation may
wish to make obtaining the token via destruction option unattractive
compared to obtaining them through trade by incorporating a time delay
into the destruction process to encourage liquidity. (interestingly a
natural outcome of an announce-commit sacrifice-to-fees scheme)

Of course even without 1-way-pegs there's a much more important issue
with your objection: worrying about creating new artificial scarcity
races while innovating is fundementally a *moralistic* and *regulatory*
concern that has no little if any bearing on whether or not the systems
created are useful and secure. It's also an objection that raises
serious questions about conflicts of interest between giving accurate
and honest technical advice and promoting ways of using Bitcoin that
will drive the price up.

> > You know, The Great Fork of 2013 was resolved through human
> > intervention, Bitcoin nodes were not smart enough to detect that
> > something is going awry on their own.
> 
> I hate to think what the outcome would've been on a proof-of-publication
> system. You don't even have a fork. You just have a whole bunch of nodes
> who sort-of-mostly agree on a shared history, except where they don't.
> Maybe they just disagree on the validity of a single transaction.
> They'll slowly diverge over time (as bad transactions are used as input
> to other transactions.) You have no reliable way to detect this lapse in
> consensus, nor any mechanism to incentivse convergence. Indeed, you have
> no consensus mechanism in the first place.

A number of mechanisms for detecting divergence are possible in embedded
consensus systems, some of them even natural outcomes. For instance
transactions can contain a hash of the previous consensus state, thereby
creating an indicator of consensus measured in terms of economic stake.
Extending that idea many anti-censorship proposals are to use such state
hashes as encryption keys - if you are out of consensus you won't even
see the transaction. (and you can'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'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. IIRC one point he made was that scheduled, regular
> hardforks were a real threat - if a single entity (eg. the Bitcoin
> Foundation) were to become politically established as the coordinator of
> such forks, they would have de-facto control over the protocol.

Indeed I did, which is why I worked out a better way to do upgrades
almost a year ago:

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06578.html


> (Also worth noting: all such systems are effectively "mandatory
> updating" due to the risk of subtle consensus bugs of the type I
> described above. Your only assurance that your view of the world is the
> same as everyone elses' is that you're running the exact same software.
> I played with Counterparty a while ago and quickly learned - the hard
> way - to do a 'git pull'

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

[Peter Todd]

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; if I can start with accepting that
95% of what my opponents say is true, yet still end up being correct,
all the better!

> I think the Mastercoin devs are doing fine work and I consider the
> zerocash devs to have developed (in v2, mint and pour) to have
> developed something that will really turn the world on its ear, but
> what do I know? Nothing.  Nothing at all.

My personal opinion is that what Mastercoin has started will turn the
world on its ear, but I'd be surprised if the succesful implementations
of the underlying ideas come from that team. But there's nothing
surprising about that - when was the last time you used Netscape
Navigator, let alone NCSA Mosaic?

-- 
'peter'[:-1]@petertodd.org
0681f4e5c84bc0bf7e6c5db8673eef225da652fbb785a0de


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

[Peter Todd]

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 idea actually - I outlined a system I eventually called
"zookeyv"¹ based on the notion of sacrificing Bitcoins to achieve
consensus a year and a half ago on #bitcoin-wizards. The discussion
started here and continued for a few days:

https://download.wpsoftware.net/bitcoin/wizards/2013/05/13-05-29.log

I later wrote up the idea in the context of adding Zerocoin to Bitcoin:

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html

For key-value mapping I eventually decided that the system didn't
necessarily need to be a strict linear blockchain - a directed acyclic
graph of commitments had advantages as there needed to be less
syncronization between transactions. This also means that the graph
doesn't necessarily need to be revealed directly in the blockchain,
exposing it to miner censorship. OTOH revealing it makes it easy to
determine if an attacker larger than you exists. These days I'd suggest
using timelock crypto to defeat miner censorship, while ensuring that in
principle consensus over all possible parts of the chain can eventually
be reached.²

Proof-of-sacrifice for consensus has a few weird properties. For
instance you can defeat attackers after the fact by simply sacrificing
more than the attacker. Not unlike having a infinite amount of mining
equipment available with the only constraint being funds to pay for the
electricity. (which *is* semi-true with altcoins!)

As for your specific example, you can improve it's censorship resistance
by having the transactions commit to a nonce in advance in some way
indistinguishable from normal transactions, and then making the
selection criteria be some function of H(nonce | blockhash) - for
instance highest wins. So long as the chain selection is based on
cumulative difficulty based on a fixed target - as is the case in
Bitcoin proper - you should get a proper incentive to publish blocks, as
well as the "total work information rachet" effect Bitcoin has against
attackers.


1) In honor of Zooko's triangle.

2) This doesn't necessarily take as much work as you might expect: you
   can work backwards from the most recent block(s) if the scheme
   requires block B_i to include the decryption key for block B_{i-1}.

-- 
'peter'[:-1]@petertodd.org
18d439a78581d2a9ecd762a2b37dd5b403a82beb58dcbc7c


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged

[Peter Todd]

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, removing the
txTo and nIn arguments that used to contain the transaction the script was in
and the txin # respectively. CHECKLOCKTIMEVERIFY needs txTo to obtain the
nLockTime field of the transaction, and it needs nIn to obtain the nSequence of
the txin.

We need to fix this if CHECKLOCKTIMEVERIFY is to be merged.

Secondly, that this change was made, and the manner in which is was made, is I
think indicative of a development process that has been taking significant
risks with regard to refactoring the consensus critical codebase. I know I
personally have had a hard time keeping up with the very large volume of code
being moved and changed for the v0.10 release, and I know BtcDrak - who is
keeping Viacoin up to date with v0.10 - has also had a hard time giving the
changes reasonable review. The #4890 pull-req in question had no ACKs at all,
and only two untested utACKS, which I find worrying for something that made
significant consensus critical code changes.

While it would be nice to have a library encapsulating the consensus code, this
shouldn't come at the cost of safety, especially when the actual users of that
library or their needs is still uncertain. This is after all a multi-billion
project where a simple fork will cost miners alone tens of thousands of dollars
an hour; easily much more if it results in users being defrauded. That's also
not taking into account the significant negative PR impact and loss of trust. I
personally would recommend *not* upgrading to v0.10 due to these issues.

A much safer approach would be to keep the code changes required for a
consensus library to only simple movements of code for this release, accept
that the interface to that library won't be ideal, and wait until we have
feedback from multiple opensource projects with publicly evaluatable code on
where to go next with the API.

1) https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
2) https://github.com/bitcoin/bitcoin/pull/4890

-- 
'peter'[:-1]@petertodd.org
1b18a596ecadd07c0e49620fb71b16f9e41131df9fc52fa6


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

[Peter Todd]

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 by ghash.io.
> But the thing is, Bitcoin doesn't offer one a good way to attack the whole,
> as there are powerful factors which will work against the attacker.
> But this is not the case with sidechains (or any merged-mined chains, for
> that matter).
> And once you have a clear incentive, collusion is much more likely.

+1

It's notable that blockstream hasn't published much if anything concrete
on what exactly you'd use merge-mined sidechains for; they're even worse
than Ethereum in that regard.

> > Proof of Burn is a real cost for following the rules.
> >
> 
>  So what? As long as cost is less than revenue, it is OK.

It's even better than that: if an attack does happen, the participants
in the consensus system have an incentive to defend against it to
maintain the value of their tokens. Proof-of-burn allows that defense to
be in response to a threat, and essentially unlimited in size.

So now any attacker knows that if they launch an attack in theory the
response could be as strong as the value of the system itself.

This can be improved upon with systems that allow the tokens to be
burned, "internal" proof-of-burn. This suffers from "nothing-at-stake"
vulnerabilities to an extent, OTOH within the context of the system it
is a true sacrifice of value; probably not a big deal in a zookeyv-style
block-DAG where multiple lines of history can be combined. Here the
incentives of the defenders are even more strongly tipped towards
burning their value to preserve the system, not unlike
replace-by-fee-scorched-earth thinking.

-- 
'peter'[:-1]@petertodd.org
0e0c078667795abe21bfdebb913eba60cc7a625c732f0a89


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles

[Peter Todd]

 R_{i+1}. As the output can only be spent once it is
not possible to create a valid-looking R_{i+1}'

However to prove to Bob that R_{i+1} is the most recent set of records
Alice still needs to use proof-of-publication, by showing him txout
T_{i+1} is unspent.


Case study: Fidelity-bonded Ledgers/Federated Sidechains


The author's Fidelity-Bonded Ledgers⁶ and the more general idea of
Federated Sidechains⁷ both describe the notion of a trusted third party,
possibly implemented as a federated majority set, who guarantees the
correct maintenance of some financial ledger according to some set of
rules. Coins can be moved to/from the ledger by payment to a specific
set of scriptPubKey's. Federated sidechains proposes that the
scriptPubKey simply be a n-of-m multisig; fidelity-bonded ledgers
proposes new opcodes that allow redemption via proof-of-fraud.

In any case someone relying on a transaction within the ledger itself
still needs to be able to audit that their view of the ledger is the
same view everyone else sees; in short that there do not exist
double-spends on the ledger. The author's fidelity-bonded ledgers paper
proposed that the ledger be made available over a Tor-accessible website
to prevent selective censorship. The federated sidechains proposal is
mute on this issue.

As the state of the ledger is a specific instance of the more general
set of records problem that Uniquebits solves as can use the same
principles for fidelity-bonded ledgers/federated sidechains. The third
party periodically publishes the ledger state to the Bitcoin blockchain
allowing anyone to detect if their copy of the ledger is incomplete; if
not there may be double-spends in it. Finally proof of such
double-spends can trigger the destruction of a fidelity-bond⁸ and/or
return funds to their rightful owners. (with appropriate opcodes⁷)

Censorship of the ledger state publications is an issue, however in the
case of financial ledgers with pegged funds we can use the pegged funds
themselves in the publication. Censoring those publications by
preventing the designated txouts from being spent then becomes
equivalent to blacklisting funds. This requires a majority of hashing
power supporting the blacklist, and is a highly politically charged
issue⁹ in the Bitcoin community.


References
==

1) Really Really ultimate blockchain compression: CoinWitness,
   Gregory Maxwell, Aug 19th 2013, Accessed 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 pricing and market depth,
   Peter Todd, Feb 9th 2014,
   
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03892.html

4) Uniquebits, Peter Todd, Accessed 2014-12-20,
   
https://github.com/petertodd/uniquebits/tree/b9213f6769d80305bdd192925e8bd7bd04239d1b

5) Homomorphic Payment Addresses and the Pay-to-Contract Protocol,
   Ilja Gerhardt and Timo Hanke, Dec 13th 2012,
   http://arxiv.org/abs/1212.3257

6) Fidelity-bonded ledgers, Peter Todd, Feb 25th 2013,
   
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg01786.html

7) Enabling Blockchain Innovations with Pegged Sidechains,
   Blockstream, Oct 22nd 2014,
   SHA256: 680c71aef9ed578720e25c58fd50de5cdbee755c3800e7601dad9a745ca65cf3,
   http://www.blockstream.com/sidechains.pdf

8) Fidelity-bonded banks: decentralized, auditable, private, off-chain payments,
   Peter Todd, Feb 23rd 2014,
   https://bitcointalk.org/index.php?topic=146307.0

9) WARNING: Bitcoin Address Blacklists have been forced into the Gentoo Linux 
bitcoind distribution by Luke-jr against the will of other core devs. Gentoo 
maintainers are clueless and not reversing the change.  Boycott Gentoo now.,
   historian, Oct 10th 2014, Accessed 2014-12-20,
   
https://www.reddit.com/r/Bitcoin/comments/2ityg2/warning_bitcoin_address_blacklists_have_been/

-- 
'peter'[:-1]@petertodd.org
01eeaba4cdadaf5b8338cb1b2ae0cf969de77437dd83faac


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles

[Peter Todd]

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
> > exists says nothing about who be in posession of that message, or
> > indeed, any message at all. Thus anti-replay is not sufficient to
> > implement other uses of proof-of-publication such as decentralized
> > exchange³.
> >
> 
> I think you are trying to say something more specific / limited than that,
> and I suggest you adjust your wording accordingly. Decentralized exchange
> would be possible today with vanilla bitcoin using SIGHASH_SINGLE if only
> the protocol supported multiple validated assets (which it could, but
> doesn't). Rather straightforward further extensions to the protocol would
> enable market participants to use a wider class of orders, as well as
> enable the buyer rather than the seller to dictate order sizes via partial
> redemption, as we demonstrate in our Freimarkets paper.

Do you realise that all those Freimarket's uses are either based on
proof-of-publication, or insecure due to sybil attacks?

-- 
'peter'[:-1]@petertodd.org
17d70ee98f4cee509d95c4f31d5b998bae6deb09df1088fc


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

[Peter Todd]

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 else can do that" WRT 2-way-pegs was overreaching.

Yup.

> I still don't see what "2-way-peg vs. 1-way-peg" has to do with
> "embedded consensus vs. blockchain consensus" though, and feel it
> disingenious to conflate them.

1-way-pegs don't require the Bitcoin protocol to change; 2-way-pegs do.

> Blockchain consensus (eg. sidechains) can utilise either mechanism,
> 1-way-peg or 2-way-peg. Arguments in favour of 1-way-peg are
> interesting, but they're ultimatley just arguments in favour of one
> type of sidechain over another.

No, they're in favor of systems that are client-side validatable vs.
systems that either allow anyone with sufficient hashing power to steal
coins *or* require "moon-math" that isn't yet available to production
systems.

> IMO the question of whether scarcity can be preserved while enabling
> innovation bears heavily on the liklihood of longterm viability of
> said innovations - and perhaps of Bitcoin itself.
> 
> FWIW I'll happily declare that I hold a modest amount of BTC and have
> an interest in the price appreciating. I'm sure you'll admit you're
> hardly an impartial party in this discussion yourself Peter :) But it
> really shouldn't matter. I'm not here today to make it, but I think
> the argument for preservation of scarcity stands quite well on its own
> merits - as rightly it should, regardless of anybody's interests.

But again, all these discussions about scarcity are fundementally
*moral* arguments that have no bearing on what's actually the most
appropriate solution for an *individual* problem.

In a decentralized system filled with anonymous actors telling people
"stop doing that! it's bad!" on reddit has pretty severe limitations in
trying to convince people to act against their own best interests.

> > The quality of Counterparty's software engineering has no bearing on
> > whether or not the underlying idea is a good one; you wouldn't say ring
> > signatures are an inherently bad idea just because the CryptoNote
> > implementation of them is atrocious.
> 
> Very interesting. I admit I hadn't come across these ideas before; I
> really must search the archive before posting :) They certainly offer
> a measure of robustness over the naive approach. I'm not sure they
> address my primary concerns however, WRT how consensus is demonstrated
> and incentivised.

I think you think consensus in Bitcoin is more "magical" than it really
is; Bitcoin is just code running on computers; consensus isn't really
incentivised at the protocol level beyond "screw it up and you'll lose
money"

Embedded consensus systems are no different: screw up consensus and
you'll lose money in a variety of ways.

> The obvious "embedded consensus" answer of "wait until N other
> transactions have occurred that include a hash of system state that
> includes your transaction" doesn't provide me with any confidence; it
> could be simulated with a Sybil attack.

No it can't - the transactions are in the blockchain so the sybil attack
has to attack the host system as well.

In any case, keep in mind all of this is in the context of tradeoffs:
for a different and sometimes more fragile consensus mechanism embedded
consensus gets immunity to attack by miners. You're trading off one type
of fragility for another - I'd much rather take the "one-time" fragility
inherent in having to write really solid software than the ongoing
fragility of always being vulnerable to miners.

Notably this is the exact same tradeoff taken elsewhere by the majority
of the crypto world.

-- 
'peter'[:-1]@petertodd.org
17d70ee98f4cee509d95c4f31d5b998bae6deb09df1088fc


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles

[Peter Todd]

On Sun, Dec 21, 2014 at 02:18:18PM +0800, Mark Friedenbach wrote:
> Care to expand?
> 
> Freimarkets does not require proof of publication of bids or asks, which
> are distributed out of band from the block chain until a match is made. It
> does not guarantee ordering of market transactions. Indeed, front-running
> is embraced as the mechanism for generating miner fees to pay for the
> service.

Right, so Freimarkets is delibrately insecure.

Best of luck on that.

> Sybil attacks? I'm not sure what you could be referring to. In Freimarkets
> a bid or ask is valid when received; a double-spend is required to cancel
> it. You could only flood the network with actual executable orders, and the
> counter-party to the order doesn't care if they all came from the same
> person or not.
> 
> Can you explain what it is you are objecting to?

Read my paper¹ - proof-of-publication is what allows you to detect
front-running robustly within certain parameters. Protecting against
that is widely considered to be a very important goal by people actually
in finance, to the point where I've had discussions with people where
anti-front-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.sourceforge.net/msg03892.html

-- 
'peter'[:-1]@petertodd.org
00c879729eae178096b092248706a407ec1b18eb62a792e9


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles

[Peter Todd]

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
> says nothing about who be in posession of that message, or indeed, any
> message at all. Thus anti-replay is not sufficient to implement other uses
> of proof-of-publication such as decentralized exchange³.
> 
> How does proof of publication prove who is in possession of that message?
> Or of any message at all?

With the blockchain you prove the message in in the blockchain; anyone
in posession of the blockchain will be in posession of the message.
Secondly determining if you are in posession of the blockchain is
possible subject to the usual considerations about attacker size,
whether or not your local clock is up-to-date, etc.

> The data written in an anti-replay system and
> the data written in a proof of publication system differs in that you can't
> repeat data in an anti-replay system according to some understanding of the
> rules of the meaning of the data (if I am following your description
> correctly).

I'm not sure you understand what an anti-replay system is; data isn't
written to them; they're an abstract mathematical model that may be
actually implemented in a variety of ways.

Now it is true that any conceivable implementation must involve some
type of storage, but that storage can easily 100% local to the
anti-replay oracle and need not store the data itself. For instance a
trusted computer in a vault that maintains an extremely large bloom
filter of previously used keys would be a perfectly reasonable
implementation.

> If the data itself defines possession, the "ownership of the message" (it
> isn't even clear to me what you mean by that phrase) isn't defined by
> either proof, but by the message itself.  And the message itself isn't
> constrained by either to prohibit proving ownership (what ever you mean by
> that).

Wait, where did I say "ownership of the message"? What you quoted above
says *posession*, which != ownership.

> Of course, I do assume I can test a message (or a set of messages sharing
> some feature like a particular input on a transaction) as being publishable
> in an anti-replay system without actually publishing it.  That does allow
> one to prove non-publishing.  You can determine if a message exists that
> would preclude the publishing of a message; the very purpose of an
> anti-replay proof.
>
> And I would assert that such a search (i.e. the idea that such a search has
> meaning in a anti-replay system) is already incorporating the assumption
> that such a search is possible and must be possible for an anti-replay
> system.

You're confused about what an anti-replay system actually is - you're
really talking about a specific implementation of one based on
proof-of-publication, not the concept itself.

-- 
'peter'[:-1]@petertodd.org
1b728df6414af5ef95388557f1c3e5d29c569d7636b93681


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles

[Peter Todd]

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
> > VerifyAntiReplaySig(m, p, sig2) -> True or False
> >
> > Additionally once AntiReplaySign() has been used once for a given pubkey
> > it is impossible to re-run the primitive on a different message m'. This
> > is of course impossible to implement with math alone, but we can
> > implement it with a trusted third party.
> 
> Well while you cant prevent it you could render it insecure enabling
> miners to take funds.
> 
> That could work via a one-show signature; normal ECDSA being address
> a=H(Q), public key Q=dG, R=kG, r=R.x, s=(H(m)+rd)/k, signature (r,s),
> verify: a=?H(Q) and sR=?H(m)G+rQ one-show being: a=H(Q,R), verify
> being: a=?H(Q,R) and sR=?H(m)G+rQ.  Now that is unsafe to double-spend
> by design as only that specific R is usable and as we know reusing R
> with different messages leaks the private key because: s=(H(m)+rd)/k
> and s'=(H(m')+rd)/k implies sk=H(m)+rd and s'k=H(m')+rd so
> k=(H(m)-H(m'))/(s'-s), and d=(sk-H(m))/r.

There's no need to get into the specifics of crypto math so early; you
can just as easily and only slightly less efficiently obtain the same
result with a few extensions to the Bitcoin scripting system to verify
ECDSA signatures directly.

The interesting question is how "risky" this actually is? Sybil attacks
are reasonably easy to pull off, and users have little incentive to
validate if 99% of the time everything works, so you don't want to
create a system where an actual attack will likely go undetected.
Talking about the low level details of how double-spend punishment is
actually detailed is just premature optimization.

As usual in Bitcoin, the hard part is *not* the math.

-- 
'peter'[:-1]@petertodd.org
12f5511833a1304a72a754df8afef26f5712438bcc40826b


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles

[Peter Todd]

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 the architecture we created users remain in control of their funds
> at all times, and miners have incentives to mine the host chain. So I don't
> know what insecurity you are possibly talking about, and seem unwilling to
> elaborate.

Sybil attacks leading to front-running.

You may not be aware of this, but not being able to get the best price
due to a sybil attack *is* considered to be a security issue by the
users of these systems.

> I have read your posting and engaged with you in that very thread, where I
> point out that global ordering of bids & asks is a superfluous requirement.

It's superfluous until you have real businesses actually using these
systems.

> As to front-running, there is a distinct difference between centralized
> systems where front-running is essentially theft, and a distributed block
> chain system with actual costs paid by fees captured from the spread.

Among other things, ever noticed how this incentivises people to sybil
attack the entire system? Not good.

-- 
'peter'[:-1]@petertodd.org
12f5511833a1304a72a754df8afef26f5712438bcc40826b


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development