Mark van Cuijk | 28 Jul 15:06 2014

Re: "On behalf of" BIP 70 extension proposal

On 28 Jul 2014, at 14:46 , Mike Hearn <mike <at> plan99.net> wrote:

I do like the idea coined by Mike that a PP can issue non-SSL certificates for the purpose of merchant identification, as long as a customer is free to determine whether he trusts the PP for this purpose.

I don't think I proposed this exactly? It's the other way around - a merchant issues an extension cert to allow the PP to act on their behalf.

I referred to your idea in https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04076.html which is indeed not the proposal itself.

Regarding the choice of how to authenticate the PP, I’m a bit undetermined. Disregarding backward compatibility, I think the extended certificate system proposed by Mike is cleaner. However, I don’t like the concept of requiring two separate signatures for old and new clients. Taking backward compatibility in mind, I tend to prefer my proposal.

I'm not sure I understand. Your proposal also has two signatures. Indeed it must because delegation of authority requires a signature, but old clients won't understand it.

I’ll rephrase what I intended to say. In your proposal two signatures need to be computed over the payment request data, one with the key related to the X.509 certificate (for backwards compatibility) and one with the ECDSA public key. On my proposal only one signature needs to be computed over the payment request data using the former key, the same way it happens now.

Indeed there is another signature, which is to authenticate the payment delegation. If you take it into account in the signature count, then your proposal has three signatures.

/Mark
------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Jeremy | 28 Jul 04:12 2014
Picon

Abnormally Large Tor node accepting only Bitcoin traffic

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


--
Jeremy Rubin
------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Mark van Cuijk | 27 Jul 08:55 2014

"On behalf of" BIP 70 extension proposal

When I asked a non-tech friend to do a BIP 70 payment using our wallet as a first round of user experience
testing, he made the remark the he wanted to do a payment to a merchant, but instead our software shows a
payment to “BitPay, Inc.”

This can be problematic for a couple of reasons:
- As a user you don’t need to know and trust individual payment processors. As long as you can identify and
authenticate the merchant, you should be able to rely on the merchant’s choice for a payment processor.
- An attacker can become a client of a payment processor, use it to create a PaymentRequest message and send
this message to a victim as part of a MITM attack; the victim now thinks he is paying a merchant through the
payment processor, but is actually paying the attacker through the payment processor.

I have a proposal that can be transformed into a BIP or into an extension of BIP 70 and adds a way to include
merchant identity in the PaymentRequest message and I’d like to see a discussion on this topic.

At this moment, the PaymentRequest message contains a pki_data field with a certificate chain to
authenticate the entity that generates the message, which in the above case is the payment processor.

I’m proposing to extends the PaymentRequest message with three more fields:
- payee_pki_type
- payee_pki_data
- payee_mandate

The payee_pki_type and payee_pki_data fields can be of the same format as the pki_type and pki_data
fields, except that they authenticate the identity of the merchant, instead of the identity of the
payment processor. The payee_mandate fields contains a claim by the merchant, signed using his own
private key, that he grants the payment processor the right to collect the payment on his behalf.

The solution is backwards compatible, since existing wallets can ignore these fields. They will not show
the identity of the merchant, but keep showing the identity of the payment processor, they are still able
to verify the signature in the PaymentRequest message and therefore can complete the payment process.

A wallet that understands this extension, needs to check the validity of both certificate chains when
present and also the validity of the mandate. If all is fine, it can now show the identity information from
the merchant certificate instead of (or besides) the identity of the payment processor and allow an end
user to correctly identify the merchant.

A payment processor supporting this extension may offer it as an optional service to clients. A client that
wishes to use this extension needs to obtain his own certificate from a CA and use it to sign a mandate. One
potential obstacle is that this process probably needs to be repeated both when the certificate of the
merchant or the certificate of the payment processor expires, but we may be able to address that when
defining the format of the mandate.

/Mark
------------------------------------------------------------------------------
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
Ron OHara | 25 Jul 03:14 2014
Picon

Time


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I thought I should shortcut my research by asking a direct question here.

As I understand it, the blockchain actually provides an extra piece of
reliable data that is not being exploited by applications.

Which data?  The time.   In this case 'the time' as agreed by >50% of
the participants, where those participants have a strong financial
incentive to keep that 'time' fairly accurate. (+/- about 10 minutes)

Is this a reasonable understanding of 'time'? ... aka timestamps on the
block

Ok... 'time' on the blockchain could be 'gamed' ... but with great
difficulty. An application presented with a fake blockchain can use
quite a few heuristics to test the 'validity' of the block chain.
It can review the usual cryptographic proofs, and check that difficulty
is growing/declining only in a realistic manner up to the most recent
block. Even use some arbitrary test like difficulty > 10,000,000,000 
... on the presumption that any less means that the Bitcoin system has
failed massively from where it currently is and has become an unreliable
time source.

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.

So if this presumption is correct, then we can now build time capsule
applications that can not be tricked into exposing their contents too
early by running them in a virtual environment with the wrong system time.

Is this right? or did miss I something fundamental?

Ron

- -- 
public identify: https://www.onename.io/ron_ohara
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT0a9sAAoJEAla1VT1+xc2ONQH/0R09guSNNCxP36KziAjfcBc
JEhxMpIlqTTYEvNXaBmuPy4BN+IZQ9izgrW/cvlEJJNMmc5/VIBk83WZltmDwcKl
oo4MIdmp6vz984GWToyyLcLSEDT60UE9Hhe+U9RyF5J9kwbN8Uy4ozUHhFVP/0EL
q4O1V6ggPbHWgH4q8m8E9qWOlIFXCDgCjxpL8Ptxsk+UlBq2NWMiwTz6Tbc9KOB4
hOffzXCZV+DkwjFZD2Rc4rHaxw1yLuYr7DzmzwZbhRQclv9tZt9hoVaAT+RQpE1k
X7pi+zVzeMMng0bzUv8t/G+gq0gaelyV41MJQRparEXhnuYkgU7rAPKIQEG8qpc=
=T5fw
-----END PGP 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
Sergio Lerner | 21 Jul 19:30 2014

Question on creating test cases for block.CheckBlock()

I'm working on a BIP which needs to modify the block acceptance rules. I
have two ways of testing:

- Mining blocks on the testnet
- Creating test cases for Bitcoin Core.

I want to create those test cases for block.CheckBlock(), which involves
verifying 100 dynamically generated blocks.
What is the state of the blockchain when a test case is executed ? Is is
configured for the regtest, testnet3 or mainnet? What blocks are in the
blockchain? Only the genesis block?

checkblock_tests.cpp seems to be the only test case for CheckBlock() and
it assumes the mainnet is configured.
I need to use the regtest so I can create blocks of difficulty 1.

Best regards and thank you in advance,

------------------------------------------------------------------------------
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
Wladimir | 21 Jul 15:43 2014
Picon

Policy for DNS seeds

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.

0. A DNSseed operating organization or person is expected
to follow good host security practices and maintain control of
their serving infrastructure and not sell or transfer control of their
infrastructure. Any hosting services contracted by the operator are
equally expected to uphold these expectations.

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.

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.

3. The results may not be served with a DNS TTL of less than one minute.

4. Any logging of DNS queries should be only that which is necessary
for the operation of the service or urgent health of the Bitcoin
network and must not be retained longer than necessary or disclosed
to any third party.

5. Information gathered as a result of the operators node-spidering
(not from DNS queries) may be freely published or retained, but only
if this data was not made more complete by biasing node connectivity
(a violation of expectation (1)).

6. Operators are encouraged, but not required, to publicly document
the details of their operating practices.

7. A reachable email contact address must be published for inquiries
related to the DNSseed operation.

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.

========

See
https://github.com/bitcoin/bitcoin/pull/4566

Wladimir

------------------------------------------------------------------------------
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
Kaz Wesley | 20 Jul 23:01 2014
Picon

Trickle and transaction propogation

The inv trickling mechanism currently serves two purposes:
- protect casual users' privacy by slightly obscuring a tx's originating node
- reduce invs unnecessarily sent both directions for a connection
It has some drawbacks:
- it slows transaction propagation
- it delays knowledge between two nodes of what txes are mutually known
These drawbacks will be especially costly once optimizations based on
mutually-known transactions are available (in progress, see "sparse
blocks" thread).

Both of the benefits of trickling can be achieved more efficiently and
without the costs to transaction propagation and mutual transaction
knowledge.

Privacy: trickling helps hide the origin of 3/4 of the transactions a
node is pushing by preventing most of the node's neighbors from seeing
the transactions from that node right away; by the time a peer becomes
the trickle node, it may have received the same inv from another of
its peers.
This staggering of introduction of new invs to the network could be
made more effective by scheduling staggered pushes of wallet
transactions to each peer in a structure similar to mapAskFor.
This does have the drawback that someone who has established multiple
connections to a node can observe that some invs are pushed at
different times, suggesting they are in the stagger set. I don't see
any straightforward way to remedy this, but trickling is also
vulnerable to sybil attacks, and floods 1/4 of its transactions
immediately anyway -- so I think staggered push would be an overall
privacy improvement.
Likelihood of a partial sybil obtaining inv origin information could
be reduced by a policy of ending staggering and pushing to all peers
once another peer has received the tx from elsewhere and inved the
transaction back to the original node; if the staggering is
sufficiently slow, only one or two nodes would receive the initial
push to the network and after that the inv would be treated
indistinguishably from if it originated externally.

Redundant invs: without trickling, when two nodes receive transactions
at around the same time they may each send each other an inv before
receiving the other's. Trickling reduces this by giving all
non-trickleSend nodes a chance to send first. Thus just eliminating
trickling would at most double inv traffic. Although invs are small
they are numerous, being the only common message potentially sent from
every node to all its neighbors.
A more efficient solution to the who-sends-first problem would be for
connections to have directional parity:
- a node initiating a connection would announce its parity (even or odd)
- an inv is sent right away to peers with matching parity, but only
sent against parity if a certain timeout has elapsed without the inv
being received
In order to allow for nodes with few peers (i.e. -connect) or nodes on
local connections that might as well flood everything to each other,
parity could be specified as a mask (fEven << 1 & fOdd). Peers from
pre-directional-parity versions can be treated as having the mask
fully set.

Both push staggering and directional parity admit simple
implementations. The specific staggering delay distribution would need
some thought; it could be set slower than the typical trickle cycle
period for better than current privacy, since general transaction
propagation would not impeded by heavy staggering. What do you think
of this approach? Any gotchas/improvements/alternatives?

------------------------------------------------------------------------------
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
Richard Moore | 19 Jul 06:33 2014

Signature with negative integer?

Hey all,

I'm wondering if anyone can help explain to me tx 70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d...

(https://blockchain.info/tx/70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d)

The input signature script
is:

304402206b5c3b1c86748dcf328b9f3a65e10085afcf5d1af5b40970d8ce3a9355e06b5b0220cdbdc23e6d3618e47056fccc60c5f73d1a542186705197e5791e97f0e6582a3201 

Which decodes to:

r= 48560432700441876832361368709121298776045893858160378595187765610521057848155
s= -22732680560694206332190468058638664750027418114195068375538144640549433890254

(http://lapo.it/asn1js/#304402206B5C3B1C86748DCF328B9F3A65E10085AFCF5D1AF5B40970D8CE3A9355E06B5B0220CDBDC23E6D3618E47056FCCC60C5F73D1A542186705197E5791E97F0E6582A32)

The ECC library I'm using is failing to verify this, which I think makes sense, since I the point needs to be
positive, no? But it is obviously valid, as it has been verified and spent. I have tried simply modulo
curve.order to positive-ify it, but that didn't seem to work either. Given a point P (with Py < 0) is there
some fancy way to bring it into the elliptic curve space, such that Px >= 0 and Py >= 0?

Thanks!

RicMoo

.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>

Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo <at> geneticmistakes.com
www: http://GeneticMistakes.com

------------------------------------------------------------------------------
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
Pieter Wuille | 18 Jul 17:14 2014
Picon

Small update to BIP 62

Hi all,

I've sent a pull request to make a small change to BIP 62 (my
anti-malleability proposal) which is still a draft; see:
* https://github.com/bitcoin/bips/pull/90 (the request)
* https://github.com/sipa/bips/blob/bip62up/bip-0062.mediawiki (the result)

It makes two of the 7 new rules mandatory in new blocks, even for
old-style transactions. Both are already non-standard since 0.8.0, and
have no use cases in my opinion.

The reason for this change is dropping the requirement for signature
verification engines to be bug-for-bug compatible with OpenSSL (which
supports many non-standard encodings for signatures). Requiring strict
DER compliance for signatures means any implementation just needs to
support DER.

Comments?

--

-- 
Pieter

------------------------------------------------------------------------------
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
Kaz Wesley | 17 Jul 23:35 2014
Picon

Squashing redundant tx data in blocks on the wire

OVERVIEW

To improve block propagation, add a new block message that doesn't include
transactions the peer is known to have. The message must never require an
additional round trip due to any transactions the peer doesn't have, but should
be compatible with peers sometimes forgetting transactions they have known.

APPROACH

For peers advertising support for squashed blocks: a node tracks what txes it
knows each peer has seen (inv received, tx sent, tx appeared in competing block
known to peer). Nodes push block contents as txes-not-already-known +
txids-known.

A node should be able to forget invs it has seen without invalidating what peers
know about its known txes. To allow for this, a node assembles a bloom filter of
a set of txes it is going to forget, and sends it to peers. The node can erase
the txes as soon as no blocks requested before the filter was pushed are in
flight (relying on the assumption that messages can be expected to be processed
in order).

When a node receives a forgotten-filter, it ORs it into its forgotten-filter for
that peer. Any transactions matching the forgotten-filter are always included in
full with a block. If the filter is getting full, the node can just clear it
along with peer.setTxKnown.

COSTS

Bloom filtering:
Since the bloom filter is likely to grow slowly and can be dropped when it is
becoming full, a cheap set of hash functions and element size can be used to
keep overhead more restricted than the bloom filtering done for spv. It's
important for testing txes against the filter to be fast so that it doesn't
delay pushing the block more than the squashing helps.
Nodes currently forget txes rarely, so the bloom filters would only need to be
used at all under conditions that are not currently common -- but I think
they're important to include to allow for different node behavior in this regard
in the future.

Tracking txes known to peers:
A multimap of txid->peerId would obviate the current setCurrentlyKnown, and
would not take much more space since each additional peer adds about 1 peerId
per txid (setCurrentlyKnown keeps a uint256 per peer per txid, although it
tracks somewhat fewer txid per node).

Potential vulnerabilities:
- Since the bloom filters will have lower maximum overhead than the current SPV
  filters and can be dropped at will, this shouldn't enable any resource
  exhaustion attacks that aren't already possible.
- A squashed block with bogus or missing data would be easily detected not to
  produce the correct merkle root for its BlockHeader.

BENEFITS

Assuming a fairly typical 500 tx block with transaction sizes averaging 300b
(both on the low side), for a 150kb block:

% pruned | block size reduction | relative size reduction
-------- | -------------------- | -----------------------
100      | 134 kB               | 89%
50       | 67 kB                | 45%
25       | 33.5 kB              | 17%

I've been doing some logging, and when my node pushes a block to a peer it seems
to typically know that a peer has seen most of the txes in the block. Even in
the case of a small block with only 25% known-known transactions, total network
bandwidth saved is greater than the bloom filters transmitted unless a node is
forgetting transactions so rapidly that it pushes new maximum-size
forget-filters every block.

So this is a net gain even in total bandwidth usage, but most importantly it's
an improvement in block propagation rate and in how block propagation rate
scales with additional transactions.

IMPLEMENTATION QUESTIONS

How should block squashing capability be advertised -- new service bit?

Bloom filters:
- How fast to test against could a suitable bloom filter be made?
- How much memory would each filter need to take, at maximum?
- Can the inputs all being 32 byte hashes be used to optimize filter hash
  calculations?

ROADMAP

If there's support for this proposal, I can begin working on the specific
implementation details, such as the bloom filters, message format, and
capability advertisment, and draft a BIP once I have a concrete proposal for
what those would look like and a corresponding precise cost/benefit analysis.

--kaz
------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Jeff Garzik | 17 Jul 18:14 2014

Decentralizing ming

Define acceptable.  The 40% thing is marketing and a temporary
solution.  And people come down on both sides of whether or not
marketing "40%" is a good idea.

I think it is a baby step that is moving in the right direction.  You
want the numbers and sentiment moving in that direction (down, versus
"own the market! </IPO>").

The more critical piece is fleshing out the various proposals and
technical solutions for decentralized transaction selection and other
aspects of SPOF-proofing mining.

Historical note:  On one hand, Satoshi seemed to dislike the early
emergence of GPU mining pools quite a bit.  On the other hand, Satoshi
noted that the network would probably devolve down to a few big
players if we ever reached VISA/MC transaction levels.  Satoshi
clearly never figured this part out :)

Today, there is consensus on the need for a "keep bitcoin free and
open" technical solution, but it remains to be seen how much we
engineers can really do to make life fair.  Making transaction
selection a bit more independent from hashpower seems one step.  There
are several other proposals floating about.

--

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

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

Gmane