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.
(Continue reading)

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
(Continue reading)

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
(Continue reading)

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
(Continue reading)

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
Melvin Carvalho | 17 Jul 12:59 2014
Picon

Mining Hashrate Caps

I noticed this article today. 

GHash Commits to 40% Hashrate Cap at Bitcoin Mining Summit

http://www.coindesk.com/ghash-commits-40-hashrate-cap-bitcoin-mining-summit/

Here's a quote from Satoshi when the mining arms race began:

"We should have a gentleman’s agreement to postpone the GPU arms race as long as we can for the good of the network. It’s much easer to get new users up to speed if they don’t have to worry about GPU drivers and compatibility. It’s nice how anyone with just a CPU can compete fairly equally right now."

Maybe outdated now, but I thought it was interesting.
------------------------------------------------------------------------------
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
Jeremy | 16 Jul 19:56 2014
Picon

Pay to MultiScript hash:

Hey all,

I had an idea for a new transaction type. The base idea is that it is matching on script hashes much like pay to script hash, but checks for one of N scripts.

A motivating case is for "permission groups". Let's say I want to have a single "root user" script, a 2 of 3 group, and a 2 of 2 group able to spend a utxo. This would allow for any one of these permission groups to spend.

Right now, this could be expressed multiple ways (ie, using an op_dup if then else chain) , but all would incur additional costs in terms of complicated control flows. Instead, I would propose:

OP_HASH160 [20-byte-hash-value 1]...[20-byte-hash-value N] OP_N OP_MULTISCRIPTHASHVERIFY


could be spent with

...signatures... {serialized script}


​And the alternative formulation: (more complex!)​

​OP_HASH160 OP_DUP [20-byte-hash-value 1]​
​ OP_IF OP_EQUAL​
​ OP_VERIFY OP_ELSE   <OP_DUP  [20-byte-hash-value 2]​​  OP_IF......> OP_ENDIF​



Of course, the permission group example is just one use case, there could be other interesting combinations as well
​.


There is an implication in terms of increased utxo pool bloat, but also an implication in terms of increased txn complexity (each 20 byte hash allows for a 500 byte script, only one of the 500 byte scripts has to be permanently stored on blockchain).


Looking forward to your feedback -- the idea is a bit preliminary, but I think it could be exciting.

Best,

Jeremy




--
Jeremy Rubin
------------------------------------------------------------------------------
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
Gregory Maxwell | 16 Jul 16:57 2014
Picon

Re: Draft BIP for geutxos message

On Wed, Jul 16, 2014 at 7:25 AM, Jeff Garzik <jgarzik <at> bitpay.com> wrote:
> On the specific issue I raised, the BIP only says "Querying multiple
> nodes and combining their answers can be a partial solution to this"
> which is not very helpful advice.  That's a partial answer to my
> question #2 with zero response for question #3.
>
> This sort of thing really needs a warning label like "use only if you
> don't have a trusted solution" and discussion of that choice is
> completely absent (question #1).

In IETF documents there is a required security considerations section,
see http://tools.ietf.org/html/bcp72

In many of our documents the whole thing is a security consideration
but for ones like these we should probably always document the
weaknesses as set out from the rest of the document.  See how BIP32
enumerates the one-private-key-breaks the chain.

On this point the getutxos document is doing well.  Perhaps breaking
some things out of the auth section into a security /
security-limitations section.  In particular, can this document
specifically call out that a local network attacker can MITM all the
peers.

(If Mike would prefer, I can send a diff with proposed changes)

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