Eric Voskuil | 25 Mar 09:04 2015

Re: On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

On 02/14/2015 05:13 AM, Peter Todd wrote:
> So stop wasting your time. Help get the consensus critical code out of
> Bitcoin Core and into a stand-alone libconsensus library...

done

https://github.com/libbitcoin/libbitcoin-consensus

> ...
> Then ... when the next time we decide to soft-fork Bitcoin the
> process isn't some secretive IRC discussion by a half-dozen "core
> developers" - and one guy who finds the term hilarious - but a full on
> DIRECT DEMOCRACY OCCUPY WALL STREEET MODIFIED CONSENSUS POW-WOW,
> complete with twinkle fingers.

You seriously made me laugh out loud with this one Peter.

e

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
(Continue reading)

Tom Harding | 25 Mar 02:57 2015

Address Expiration to Prevent Reuse

The idea of limited-lifetime addresses was discussed on 2014-07-15 in

http://thread.gmane.org/gmane.comp.bitcoin.devel/5837

It appears that a limited-lifetime address, such as the fanciful

address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366

where 349366 is the last valid block for a transaction paying this 
address, could be made reuse-proof with bounded resource requirements, 
if for locktime'd tx paying address, the following were enforced by 
consensus:

  - Expiration
    Block containing tx invalid at height > 349366

  - Finality
    Block containing tx invalid if (349366 - locktime) > X
    (X is the address validity duration in blocks)

  - Uniqueness
    Block containing tx invalid if a prior confirmed tx has paid address

Just an an idea, obviously not a concrete proposal.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
(Continue reading)

Ethan Heilman | 23 Mar 16:33 2015
Picon

Research on partitioning Bitcoind nodes: "Eclipse Attacks on Bitcoin’s Peer-to-Peer Network"

Hi All,

There has been much discussion lately on the dev list about
misbehaving peers and attacks on the P2P network. We'd like to share
our research on partitioning Bitcoind nodes from the rest of the
network.

Eclipse Attacks on Bitcoin’s Peer-to-Peer Network
Abstract: We present eclipse attacks on bitcoin's peer-to-peer
network. Our attack allows an adversary controlling a sufficient
number of IP addresses to monopolize all connections to and from a
victim bitcoin node. The attacker can then exploit the victim for
attacks on bitcoin's mining and consensus system, including
N-confirmation double spending, selfish mining, and adversarial forks
in the blockchain. We take a detailed look at bitcoin’s peer-to-peer
network, and quantify the resources involved in our attack via
probabilistic analysis, Monte Carlo simulations, measurements and
experiments with live bitcoin nodes. Finally, we present
countermeasures, inspired by botnet architectures, that are designed
to raise the bar for eclipse attacks while preserving the openness and
decentralization of bitcoin’s current network architecture.

Full paper available here:
http://cs-people.bu.edu/heilman/eclipse/

Thanks,
Ethan

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
(Continue reading)

Justus Ranvier | 20 Mar 16:16 2015
Picon

Fwd: re Improving resistance to transaction origination harvesting


-------- Forwarded Message --------
Subject: re [Bitcoin-development] Improving resistance to transaction
origination harvesting
Date: Fri, 20 Mar 2015 14:06:59 +0100
From: Arne Bab. <Arne_Bab <at> web.de>
To: justus.ranvier <at> monetas.net

Hi Justus,

I read your proposal for a bitcoin darknet (friend-to-friend), but I’m
not on that list, so it would be nice if you could relay my message.

Wladimir J. van der Laan wrote:
> Experience with other networks such as Retroshare shows that … in
> practice most people are easily tricked into adding someone as
'friend'

This argumentation does not apply to the friend-to-friend connections
in Freenet, though, because in Retroshare you need friends to be
connected at all, while in Freenet adding Friends is optional. They
were made optional in direct response to seeing people exchange
friend-references with strangers.

An important aspect of friend-to-friend connections is that they have
to provide additional value for the communication with real-life
friends. I had few darknet contacts in Freenet until I started using
messages to friends for confidential communication (in which freenet
traffic provides a cover for the direct communication with friends).

(Continue reading)

Dennis Sullivan | 18 Mar 23:38 2015
Picon

Are Instant Confirmations safe?

Hello. This is my first time posting to this list. I wanted to ask your opinions on something relating to confirmation times.

I recently read about a "transaction locking" proposal which claims to make it possible to accept 0-conf transactions with guarantee they will get mined. This seems rather dubious to me, because if there was merit to the system, I would have already expected to see discussion on this list regarding it.

The scheme operates as follows:

As implemented into Darkcoin, an InstantX transaction is broadcast spending certain outputs. Certain nodes determined deterministically will sign a message which is relayed across the network locking this tx in mempool such it's inputs cannot be double spent. All nodes are instructed to reject any conflicting transactions and flush out any existing txs in the mempool that conflict with this "locked" tx. From this point onwards, the network will refuse to relay double spends and will also reject blocks that contain a conflicting tx thus forcing miners to play ball.

The idea is once a transaction receives a "consensus lock" across nodes in the mempool, the tx will eventually get mined as there is no way it can be double spent and no way a miner can mine a double spend of the consensus locked transaction. At the very least, this seems like it could be turned in on itself to fork the network because of the ability to cause blocks to be rejected. I am sure there is an attack vector there somewhere.

A full explanation is published in this paper: https://www.darkcoin.io/wp-content/uploads/2014/09/InstantTX.pdf

Dennis

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Justus Ranvier | 17 Mar 17:26 2015
Picon

Improving resistance to transaction origination harvesting


The ability of entities with large numbers of nodes to track the
origination of Bitcoin transactions is very similar to an attack on
the Freenet project.

The Freenet project addressed this weakness by via a technique they
called "Darket" - which means that nodes would only connected to a
defined set of trusted peers instead of being open to all connections
(Opennet) An individual Freenet node can operate in Opennet mode, or
Darknet mode, or mixed mode. [1]

This approach would be beneficial to Bitcoin as well to reduce privacy
leaks due to harvesting attacks.

Proposal:

Allow Bitcoin nodes to create authenticated connections with trusted
peers via CurveCP [2]. Nodes that have at least one CurveCP peer only
broadcast their transactions to those peers.

Use of CurveCP requires both sides of the connection to know each
other's long term public key. This key can be packaged in a structure
similar in concept to a Freenet node reference.

A Bitcoin node reference consists of a JSON structure containing one
or more "externalip" elements followed by one "pubkey" element. The
structure is then clearsigned by the long term CurveCP public key
contained in the "pubkey" element.

Users who wish to set up a secure connection between their nodes would
first use an API command to generate their node references, exchange
these files, and copy them to the ~/.bitcoin/curvecp directory with a
.ref extension. The node only accepts CurveCP connections from, and
attempts CurveCP connection to, peers whose references are present in
that directory.

Instead of listening both for regular TCP and CurveCP connections on
the same port, CurveCP connections would take place on a separate
port, designated by -bind_curvecp, -port_curvecp, and -externalip_curvecp

If -bind_curvecp is specified, the node will always listen for
incoming CurveCP connections, -listen=0 can be set to disallow
non-authenticated incoming connections.

Relationship with Tor:

This proposal would work along with, or independently of Tor usage.

The same network monitoring techniques which can track an originating
transaction to a particular IP address could do the same thing for a
node which is listening as a hidden service, and any technique for
deanonymising hidden services could then identify the point of origin.

Currently the only way to configure a node to submit its transactions
anonymously to the network is to make the node non-listening, which
means it can not contribute to the network.

This proposal would allow nodes to contribute to the network as
listening nodes, while retaining privacy with regards to transactions
originating from themselves.

SPV peers:

CurveCP connections also can be created between full nodes and SPV
nodes, in which case transactions originating from the SPV peers would
be routed as if they originated from the full node.

[1] https://wiki.freenetproject.org/Darknet
[2] http://curvecp.org

--

-- 
Justus Ranvier                   | Monetas <http://monetas.net/>
<mailto:justus <at> monetas.net>      | Public key ID : C3F7BB2638450DB5
                                 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
Attachment (0xEAD9E623.asc): application/pgp-keys, 17 KiB
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Peter Todd | 16 Mar 23:12 2015

My thoughts on the viability of the Factom token

Repost of https://www.reddit.com/r/Bitcoin/comments/2z9k5p/factom_announces_launch_date_for_software_token/cph0pvo
for archival/disclosure purposes:

I'm very skeptical about the long-term viability of Factom and the value of the
Factom token.

The idea behind Factom is to create a proof-of-publication medium where facts
for some purpose can be published; the token incentivises people to maintain
the infrastructure required for that medium. You can think of Factom as a two
layer system, with Factom servers provide a layer that in turn is used by
secondary proof-of-publication ledgers. By publishing records in the Factom
layer you prove that the secondary layer of actual facts is being maintained
honestly.

For instance one such secondary layer might be the property records of a
city using a digital Torrens title system¹ to maintain land titles.
Let's look at how this works step by step:

* You would know your digitally represented land title was valid because
  it was in the city's ledger and the digital signatures verify.

* You in turn know the *copy* of that ledger that you posess is the
  official version because you can inspect the ledger maintained by the
  Factom servers.

* You know that ledger is the official Factom layer - not a fork of that
  ledger - because you can run the Factom consensus protocol against the
  Bitcoin blockchain.

* You know you have the only Bitcoin blockchain and not a fork because
  of the Bitcoin Proof-of-Work consensus algorithm.

That's four steps in total. The problem is step #3 - the Factom
consensus layer - requires you to trust the Factom servers. The issue is
if the Factom servers ever publish a Factom ledger anchor in the Bitcoin
blockchain but don't make the data available you have no way of proving
that your Factom-secured ledger - e.g. the city's property title records
- is the only copy out there and you're not trying to defraud someone.
Those servers are voted in by a (quite complex) consensus algorithm, but
ultimately they are trusted third parties that can break your ability to
prove your Factom-secured records are honest.

Of course in practice if this happens people will just accept it and
patch their software to ignore the failure... but then why use Factom at
all? You can do the exact same thing with *far* less complexity by just
securing your ledger directly in the Bitcoin blockchain, skipping step
#3 and the dependency on trusted third parties. (I don't mean putting
the ledger itself in the chain, just hashes of it)

The only disadvantage to securing your records directly in the Bitcoin
blockchain is you have to pay transaction fees to do it. However
currently those fees are very small - they'll always be about the cost
to make a transaction - and if they do increase it's easy to create
"meta-ledgers" based on explicit trust relationships. For instance a
bunch of cities can get together to establish a meta-ledger for all
their per-city property title systems, perhaps using efficient
threshold-signature² multisig to ensure that a majority of those cities
have to sign off on any updates to the meta-ledger.

Of course all these Factom alternatives can be argued to "bloat the
blockchain" - but how are we going to force people to use less secure
alternatives to just using the blockchain? It's impossible to stop
people from securing ledgers in the blockchain technically; our only way
to do it is via social pressure like writing angry posts on reddit and
lawsuits.

tl;dr: For the Facom token to rise in value we need Bitcoin transaction
fees to rise greatly, and/or people to choose to use much more complex
and less secure systems in preference to much more simple systems.

Disclaimer: I've been hired by Factom to review the Factom protocol. I
also am working on a competing library called Proofchains that among
other things can be used to secure ledgers using Bitcoin directly. That
funding model for that effort is to convince individual clients that
they need the technology and should pay me to develop it.

1) http://en.wikipedia.org/wiki/Torrens_title

2) https://bitcoinmagazine.com/19528/threshold-signatures-new-standard-wallet-security/

--

-- 
'peter'[:-1] <at> petertodd.org
00000000000000000de14334f9da364dc660a7cb1d7b695c08a3472e94d3512a
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Kalle Rosenbaum | 14 Mar 19:16 2015
Picon

Re: Proof of Payment

Den 14 mar 2015 00:59 skrev "Patrick Mccorry (PGR)" <patrick.mccorry <at> newcastle.ac.uk>:
>
> That all seems more complicated than it needs to be - the service you are paying knows that it had received a payment from some public key Q (regardless of script type, as all scripts require a public key).

The service knows it had received a payment from Q1, Q2,...,Qn. A tx may have multiple inputs and each input may have several public keys.

>
> So I want to rent a movie, they send me a challenge and I respond with a zero knowledge proof to demonstrate that I am the owner of Q, and as they know that Q made a payment - then there is a proof of payment - as this is provided by the time stamped transaction on the blockchain - in this sense you are bootstrapping trust from the blockchain.
>

Ok. Without knowing much about zero knowledge proof, i guess you'd need a challenge/response for each of the keys Q1,..,Qn. If we settle on only a single key, what key from what input should we use? One input may be a multisig (2 of 3) input. Is it ok to settle on only one of the multisig keys? Probably not. I'd say that we need 2 of 3 signatures (just as in a bitcoin transaction), and not necessarily the same two that made the payment.

> For all of your scenarios, a simple challenge-response scheme would work. Adding an op_return makes the payment transaction worse as it is now distinguishable on the blockchain - you want use information that is already available on that transaction.

I'm not sure I follow. Do you mean that it's a problem that the PoP itself reveals what transaction I'm proving? Well, maybe it is a problem under some circumstances. The least you can do to protect yourself from revealing information to third party is to communicate over secure channels. Could you please elaborate on this?

Anyway, if both the client and the server knows what transaction to prove (ad-sign example) you are right that the tx info is kind of redundant. But if we don't send the tx hints from server to client, the client user must manually select the transaction to prove which makes the user experience worse.

Thank you very much for your comments,

/Kalle

>
> Sent from my iPhone
>
> On 13 Mar 2015, at 19:58, Kalle Rosenbaum <kalle <at> rosenbaum.se> wrote:
>
>> Hi all,
>>
>> I've been thinking about how a person can prove that she has made a payment. I came up with an idea I call Proof of Payment (PoP) and I would highly appreciate your comments. Has something like this been discussed somewhere before?
>>
>> Use cases
>>
>> There are several scenarios in which it would be useful to prove that you have paid for something. For example:
>> A pre-paid hotel room where your PoP functions as a key to the door.
>> An online video rental service where you pay for a video and watch it on any device.
>> An ad-sign where you pay in advance for e.g. 2-weeks exclusivity. During this period you can upload new content to the sign whenever you like using PoP.
>> A lottery where all participants pay to the same address, and the winner of the T-shirt is selected among the transactions to that address. You exchange the T-shirt for a PoP for the winning transaction.
>>
>> These use cases can be achieved without any personal information (no accounts, no e-mails, etc) being involved.
>>
>> Desirable properties:
>> A PoP should be generated on demand.
>> It should only be usable once to avoid issues due to theft.
>> It should be able to create a PoP for any payment, regardless of script type (P2SH, P2PKH, etc.).
>> Current methods of proving a payment, as I know of:
>> BIP0070, The PaymentRequest together with the transactions fulfilling the payment makes some sort of proof. However, it does not meet 1 or 2 and it obviously only meets 3 if the payment is made through BIP0070. Also, there's no standard way to request/provide the proof.
>> Signing messages, chosen by the entity that the proof is provided to, with the private keys used to sign the transaction. This could meet 1 and 2 but probably not 3. This is not standardized either.
>> Proof of Payment, the data structure
>>
>> A proof of payment for a transaction T, PoP(T), is used to prove that one has ownership of the credentials needed to unlock all the inputs of T. It has the exact same structure as a bitcoin transaction with the same inputs as T and with a single OP_RETURN output:
>>
>> OP_RETURN PoP <txid> <nonce>
>>         
>> | Field     | Size [B] | Description                        |
>> |-----------|----------|------------------------------------|
>> | PoP       | 3        | Literal identifying this as a PoP  |
>> | <txid>    | 32       | The transaction to Prove           |
>> | <nonce>   | 5        | Unsigned integer                   |
>>
>> The PoP is signed using the same signing process that is used for bitcoin transactions. The purpose of the nonce is to make it harder to use a stolen PoP. Once the PoP has reached the destination, that PoP is useless since the destination will generate a new nonce for every PoP.
>>
>> Proof of Payment, the process
>> A proof of payment request is sent from the server to the wallet. The request contains:
>> a random nonce
>> a destination where to send the PoP, for example a https URL
>> data hinting the wallet which transaction to create a proof for. For example:
>> txid, if known by the server
>> PaymentRequest.PaymentDetails.merchant_data (in case of a BIP0070 payment)
>> amount
>> label, message or other information from a BIP0021 URL
>> The wallet identifies the transaction T, if possible. Otherwise asks the user to select among the ones that fit the hints in 1.3.
>> The wallet checks that T is on the blockchain, meaning all the inputs are spent.
>> The wallet creates an unsigned PoP (UPoP) for T, and asks the user to sign it.
>> The user confirms
>> The UPoP(T) is signed by the wallet, creating PoP(T).
>> The PoP is sent to the destination in 1.2.
>> The server receiving the PoP validates it and responds with “valid” or “invalid”
>> The wallet displays the response in some way to the user.
>> Remarks:
>> The method of transferring the PoP request at step 1 is not very well thought through, but I think we can extend BIP0021 to cater for this. For example read a URI, representing a PoP request, using QR code or NFC. A more advanced approach would be to extend BIP0070.
>> The nonce must be randomly generated by the server for every new PoP request.
>> Validating a PoP
>>
>> The server needs to validate the PoP and reply with “valid” or “invalid”. That process is outlined below:
>> Check the format of the PoP. It must pass normal transaction checks, except for the inputs being already spent.
>> Check the output script. It must conform to the OP_RETURN output format outlined above.
>> Check that the nonce is the same as the one you requested.
>> Check that the txid in the output is the transaction you actually want proof for. If you don’t know what transaction you want proof for, check that the transaction actually pays for the product/service you deliver (in the video rental case, find the transaction among all payments for that specific video).
>> Check that the inputs of the PoP are exactly the same as in transaction T.
>> Check the signatures of all the inputs, as would be done on a normal transaction.
>> If the signatures are valid, the PoP is valid.
>> Security issues
>> Someone can intercept the PoP-request and change the destination so that the user sends the PoP to the bad actor.
>> Someone can intercept the PoP-request and change for example the txid to trick the user to sign a PoP for another transaction than the intended. This can of course be avoided by actually looking at the UPoP before signing it. The bad actor could also set hints for a transaction that the user didn’t make, resulting in a broken service.
>> Someone can steal a PoP and try to use the service hoping to get a matching nonce. Probability per try: 1/(2^40). The server should have mechanism for detecting a brute force attack of this kind, or at least slow down the process by delaying the PoP request by some 100 ms or so.
>> Even if a wallet has no funds it might still be valuable as a generator for PoPs. This makes it important to keep the security of the wallet after it has been emptied.
>> The first two issues are the same as for traditional bitcoin payments. They could be mitigated by using secure connections and possibly also extending BIP0070 to support PoPs.
>>
>> Further work
>> Figure out how to make use of, and extend, BIP0070 for the purpose of PoPs
>> Define an extension for BIP0021 to support PoP requests (something along the lines of BIP0072)
>> Implement a proof-of-concept
>> Possibly propose BIPs for the different parts.
>> Looking forward to reading your comments
>> Regards,
>> Kalle Rosenbaum
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development <at> lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Kalle Rosenbaum | 14 Mar 10:28 2015
Picon

Re: Proof of Payment

Actually, the security of the PaymetRequest is pretty much out of your control as soon as the PaymentRequest is created on the server. You have no idea what the hotel does with it. Also if it's stored in the hotel server I have to trust the hotel to keep it safe for me.

Well, yes. But if the hotel itself is hacked then the whole process is meaningless, no? The hacker could just make the hotel think the proof of payment is correct even though it was never made at all, for instance.

Maybe the hotel example is not perfect for this discussion. Let's instead assume that the server holds yearly subscriptions to some expensive video service. If that service stores PaymentRequests for all their subscribers, and accept them as proof of payment, that would be similar to storing username and (possibly hashed) passwords for all subscribers. If all the PaymentRequests for all users are stolen, then they have to shut down all accounts if they discover the theft. If they don't discover the theft the "accounts" are out in the wild, for sale, for blackmail, etc.

Wouldn't it be better if the service don't accept the reusable PaymentRequests as proof, and instead accept a proof generated on demand, at the very moment it is needed, and that it is only usable once? From a usability perspective there is no difference; The users simply need access the service and authorize the proof being sent to the server.
 
 
Another thing is that you assume BIP0070 is used for payments, which isn't necessarily is the case.

It's just a convenient place to put things. There are lots of useful features that need BIP 70. I hope eventually all wallets will support it.

I also hope BIP0070 will take off. It would greatly improve the user experience. But even then, all payments are not BIP0070. BIP0070 is primarily for merchants who have the skills, time and money to use certificates. I don't think a lottery at the local church would want to set up a secure BIP0070 server, but they still might want to use bitcoin for their lottery.

Regards,
Kalle
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Justus Ranvier | 13 Mar 21:01 2015
Picon

Criminal complaints against "network disruption as a service" startups


Given the recent news about Chainanalysis
(https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/),
and other companies who are disrupting the Bitcoin network
(https://www.reddit.com/r/Bitcoin/comments/2we0d9/in_an_unrelated_thread_a_bitcoin_dev_claimed/copzt3x)
it might be worth reviewing the terms of the Computer Fraud and Abuse
Act and similar legislation in other countries.

Although it's not possible to stop network attacks by making them
illegal, it's certainly possible to stop traditionally funded
companies from engaging in that activity. Note there exist no
VC-funded DDoS as a service companies operating openly.

It's also worth discussing ways to make the responsibilities of
network peers more explicit in the protocol, so that when an entity
decides to access the network for purposes other than for what full
node operators made connection slots available that behavior will be a
more obvious violation of various anti-hacking laws.
Attachment (0xEAD9E623.asc): application/pgp-keys, 17 KiB
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Kalle Rosenbaum | 13 Mar 20:29 2015
Picon

Proof of Payment

Hi all,

I've been thinking about how a person can prove that she has made a payment. I came up with an idea I call Proof of Payment (PoP) and I would highly appreciate your comments. Has something like this been discussed somewhere before?

Use cases

There are several scenarios in which it would be useful to prove that you have paid for something. For example:
  • A pre-paid hotel room where your PoP functions as a key to the door.
  • An online video rental service where you pay for a video and watch it on any device.
  • An ad-sign where you pay in advance for e.g. 2-weeks exclusivity. During this period you can upload new content to the sign whenever you like using PoP.
  • A lottery where all participants pay to the same address, and the winner of the T-shirt is selected among the transactions to that address. You exchange the T-shirt for a PoP for the winning transaction.

These use cases can be achieved without any personal information (no accounts, no e-mails, etc) being involved.

Desirable properties:
  1. A PoP should be generated on demand.
  2. It should only be usable once to avoid issues due to theft.
  3. It should be able to create a PoP for any payment, regardless of script type (P2SH, P2PKH, etc.).
Current methods of proving a payment, as I know of:
  • BIP0070, The PaymentRequest together with the transactions fulfilling the payment makes some sort of proof. However, it does not meet 1 or 2 and it obviously only meets 3 if the payment is made through BIP0070. Also, there's no standard way to request/provide the proof.
  • Signing messages, chosen by the entity that the proof is provided to, with the private keys used to sign the transaction. This could meet 1 and 2 but probably not 3. This is not standardized either.
Proof of Payment, the data structure

A proof of payment for a transaction T, PoP(T), is used to prove that one has ownership of the credentials needed to unlock all the inputs of T. It has the exact same structure as a bitcoin transaction with the same inputs as T and with a single OP_RETURN output:

OP_RETURN PoP <txid> <nonce>
        
| Field     | Size [B] | Description                        |
|-----------|----------|------------------------------------|
| PoP       | 3        | Literal identifying this as a PoP  |
| <txid>    | 32       | The transaction to Prove           |
| <nonce>   | 5        | Unsigned integer                   |


The PoP is signed using the same signing process that is used for bitcoin transactions. The purpose of the nonce is to make it harder to use a stolen PoP. Once the PoP has reached the destination, that PoP is useless since the destination will generate a new nonce for every PoP.

Proof of Payment, the process
  1. A proof of payment request is sent from the server to the wallet. The request contains:
    1. a random nonce
    2. a destination where to send the PoP, for example a https URL
    3. data hinting the wallet which transaction to create a proof for. For example:
  • txid, if known by the server
  • PaymentRequest.PaymentDetails.merchant_data (in case of a BIP0070 payment)
  • amount
  • label, message or other information from a BIP0021 URL
  • The wallet identifies the transaction T, if possible. Otherwise asks the user to select among the ones that fit the hints in 1.3.
  • The wallet checks that T is on the blockchain, meaning all the inputs are spent.
  • The wallet creates an unsigned PoP (UPoP) for T, and asks the user to sign it.
  • The user confirms
  • The UPoP(T) is signed by the wallet, creating PoP(T).
  • The PoP is sent to the destination in 1.2.
  • The server receiving the PoP validates it and responds with “valid” or “invalid”
  • The wallet displays the response in some way to the user.
  • Remarks:
    • The method of transferring the PoP request at step 1 is not very well thought through, but I think we can extend BIP0021 to cater for this. For example read a URI, representing a PoP request, using QR code or NFC. A more advanced approach would be to extend BIP0070.
    • The nonce must be randomly generated by the server for every new PoP request.
    Validating a PoP

    The server needs to validate the PoP and reply with “valid” or “invalid”. That process is outlined below:
    1. Check the format of the PoP. It must pass normal transaction checks, except for the inputs being already spent.
    2. Check the output script. It must conform to the OP_RETURN output format outlined above.
    3. Check that the nonce is the same as the one you requested.
    4. Check that the txid in the output is the transaction you actually want proof for. If you don’t know what transaction you want proof for, check that the transaction actually pays for the product/service you deliver (in the video rental case, find the transaction among all payments for that specific video).
    5. Check that the inputs of the PoP are exactly the same as in transaction T.
    6. Check the signatures of all the inputs, as would be done on a normal transaction.
    7. If the signatures are valid, the PoP is valid.
    Security issues
    • Someone can intercept the PoP-request and change the destination so that the user sends the PoP to the bad actor.
    • Someone can intercept the PoP-request and change for example the txid to trick the user to sign a PoP for another transaction than the intended. This can of course be avoided by actually looking at the UPoP before signing it. The bad actor could also set hints for a transaction that the user didn’t make, resulting in a broken service.
    • Someone can steal a PoP and try to use the service hoping to get a matching nonce. Probability per try: 1/(2^40). The server should have mechanism for detecting a brute force attack of this kind, or at least slow down the process by delaying the PoP request by some 100 ms or so.
    • Even if a wallet has no funds it might still be valuable as a generator for PoPs. This makes it important to keep the security of the wallet after it has been emptied.
    The first two issues are the same as for traditional bitcoin payments. They could be mitigated by using secure connections and possibly also extending BIP0070 to support PoPs.

    Further work
    • Figure out how to make use of, and extend, BIP0070 for the purpose of PoPs
    • Define an extension for BIP0021 to support PoP requests (something along the lines of BIP0072)
    • Implement a proof-of-concept
    • Possibly propose BIPs for the different parts.
    Looking forward to reading your comments
    Regards,
    Kalle Rosenbaum

    ------------------------------------------------------------------------------
    Dive into the World of Parallel Programming The Go Parallel Website, sponsored
    by Intel and developed in partnership with Slashdot Media, is your hub for all
    things parallel software development, from weekly thought leadership blogs to
    news, videos, case studies, tutorials and more. Take a look and join the 
    conversation now. http://goparallel.sourceforge.net/
    _______________________________________________
    Bitcoin-development mailing list
    Bitcoin-development <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    

    Gmane