Changing PGP identities/keys

As part of the process of moving to BitPay, I'll be switching to
jgarzik <at> bitpay.com as a PGP identity, with brand new signing keys.

Here is a message, signed by jgarzik <at> exmulti.com's key (the one listed
on bitcoin.org), proving they are the same person.

http://yyz.us/jgarzik-now-at-bitpay.txt
http://yyz.us/jgarzik-bitpay-pubkey.txt

If a couple people would run through this and verify that "I am me", I
would appreciate it.  A sig check and IRC ack would be great.  Thanks!
 bitcoin.org will be updated after this.

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

Jeff Garzik's business identity and PGP information is:

pub  2048R/7ADCA079 2013-05-23 Jeff Garzik <jgarzik <at> bitpay.com>
	 Fingerprint=3710 4081 6275 9FC5 A429  6536 E7A5 8E33 7ADC A079

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIVAwUBUZ4ykNodwg8tvwyoAQImAg//WdYc4RpZDtLUGWGMXr4Jnme9gjLdmFr4
em1McXk7faHls/qbQOlKdi46mTm4E/RZ6SLE7wMQkPD5RD0ukx3zkkFznbAuBuw2
/wCmNP2Tt/PZI2x3e9gfdBL0WxVfDTczZtMEMhz0ovMm3MtfZ8Xv9GtK3go+4LXa
eX4OguGVsuh/iJ1fSgr9ObZM1RSC7d7niXDw7oK8St6+G9z/4JiAs7jSpG1/jkw1
hNqSwxXSL/N5rbccPNvR91jWL7s63MQbrjYSWADxJQ81vLwV6JbyANyc6HnkfrPY
s0LmqtGqO3qa3xikhde8Iw0urejgyLSSJXcYLak+3TgRZqXmqJWhCW5bwRmathht

BIP 0021 idea: sendmany

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Double Spend Notification

The current BitCoin implementation is subject to relatively easy double 
spend attack for 0 confirmation payments.  Yet 0 confirmation payments 
are needed for typical in person transactions like most purchases at a 
local business.

Notably, it is easy to transmit two transactions from the same output at 
the same time to different sets of nodes on the network by using two 
instances of bitcoind with same wallet file and a spend on each daemon 
initiated by RPC by some easy to implement code.  If the first attempt 
to pay the merchant doesn't go through because they received the "wrong" 
transaction it could be quickly followed up with another initiated spend 
from a different output switching which daemon sends the transaction the 
merchant is expecting.  This means an unsophisticated attacker can 
reliably get away with this attack and it would be worth while for small 
transactions.  Given this, I would be reluctant to trust 0 confirmation 
transactions at all though I think many do in practice.  Someone could 
write and publish a special daemon to execute this attack further 
reducing the cost.

Right now a node will drop any second spend of the same output in the 
memory pool.  After the first transaction has propagated through the 
network issuing a second double spend transaction isn't likely to be 
seen by a significant number of miners as most nodes especially non 
miner nodes will drop this transaction.  Today, it is necessary to 
transmit both transactions on the network nearly simultaneously to 
reliably get away with this simple attack.  If in this case, the 
receiving end is quickly notified of the double spend this attack 
becomes more more difficult to get away with.

If the second transaction is relayed instead of being dropped to notify 
the receiving party of the double spend, most miners will receive both 
transactions and it is possible that some or even many of the miners 
would replace the first transaction with the second if it has a higher 
fee as it would be in their short term interest. This can happen some 
time after the first transaction has propagated through the network so 
the receiving end wouldn't get a timely notification of the double 
spend.  Depending on the choices of the miners, this approach to double 
spend notification could exacerbate the very problem it was attempting 
to fix compared to the current implementation.  While miners might 
continue to drop the second spends, the easy availability of the second 
spends would increase the short term reward for changing this policy.

This problem can be fixed if instead of sending the second transaction a 
new double spend message is sent with proof of the double spend but not 
the complete transactions.  This would allow the receiving end to be 
quickly notified of a double spend while in no way increase the chance 
over the current implementation that a double spend would be successful.

The proof of the double spend would include the scriptSig (input) from 
the original transactions and the hashes from the "simplified" 
transaction used by OP_CHECKSIG of the scriptPubKey (output) but not the 
entire transaction.  This is the hash computed by the SignatureHash 
function in script.cpp.   The double spend notification message should 
contain proofs of both signed transaction spending the same output 
ordered by hash to produce a canonical proof for a specific two 
transactions.  To reduce DOS potential, the proof should not be relayed 
unless one of the original transactions has been received to ensure 
there is some commitment to the block chain and different double spend 
proofs of the same output should not be relayed.  The forwarding of 
transactions should remain exactly the same as it is now where the 
second transaction is dropped but a double spend message is transmitted 
if appropriate.

The existing block chain needs to be checked to make sure the proof of 
double spend couldn't have been derived from the block chain and a 
single spend in the memory pool.  This could happen if there was already 
an identical transaction in the block chain.  This would typically only 
happen if someone was paying someone else the same amount they had 
before and neither side changed addresses.  In this case double spend 
detection wouldn't be reliable as it could be generated by anyone, but 
both the sending and receiving client could detect this situation and 
warn the user.

It would still be possible for an attacker to send the second 
transaction directly to powerful miners but this is a distinctly less 
viable attack than the current double spend attack.

I would expect this double spend notification implementation to make 
double spends more costly than they are worth for most cases today that 
0 confirmation acceptance is needed.  That said over time this provision 
might become less effective.  As the reward for each block mined 
decreases, transactions fees will become a more significant part of the 
mining reward accordingly increasing the incentive to replace 
transactions with higher fees.  Today most BitCoin participants have a 
high expectation of significant future appreciation of BitCoins and 
recognize anything that brings into question the integrity of the system 
is likely to reduce that future value so they have a long term self 
interest to keep up the impression of integrity.  As BitCoin becomes 
more establish this incentive will decrease.

On the other hand, non mining nodes have no incentive to replace by 
fee.  The continued increased capital costs of mining would likely 
increase the proportion of non mining nodes typically run by those with 
an incentive to assure integrity of the network such as merchants.  But 
increasing transaction volume is likely to increase node costs which 
would push out non mining nodes with lower incentive more than mining 
nodes.  Accordingly increasing block size would have a tendency to 
reduce the effectiveness of double spend notification.  The primary 
point is there are multiple counteracting forces that make predicting 
the future effectiveness of double spend notification uncertain.

I don't believe this necessary warrants conceding that we can not 
provide any protection from non trusted 0 confirmations transaction as a 
replace by fee implementation would do.  But it would still be important 
to work towards more robust solutions notably various forms of 3rd party 
trust.  This could be tamper resistant devices trusted to not duplicate 
spends, 3rd party certificates with proof the transaction was spent by 
the holder of the certificate or multi signature transactions on the 
block chain that must be signed by a trusted 3rd party to spend.  I 
would expect it would take significantly longer for the companies and 
technologies to be built to implement this on a wide scale than adding 
double spend proof messages to the current implementation.  In addition, 
there will likely always be some use cases where a 3rd party 
(centralization) is not viable.

Should a BIP and pull request implementing a double spend notification 
as described be accepted?

- Quinn

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

UUID to identify chains (payment protocol and elsewhere)

At the developer round-table it was asked if the payment protocol would 
alt-chains, and Gavin noted that it has a UTF-8 encoded string 
identifying the network ("main" or "test"). As someone with two 
proposals in the works which also require chain/coin identification (one 
for merged mining, one for colored coins), I am opinionated on this. I 
believe that we need a standard mechanism for identifying chains, and 
one which avoids the trap of maintaining a standard registry of 
string-to-chain mappings.

Any chain can be uniquely identified by its genesis block, 122 random 
bits is more than sufficient for uniquely tagging chains/colored assets, 
and the low-order 16-bytes of the block's hash are effectively random. 
With these facts in mind, I propose that we identify chains by UUID.

So as to remain reasonably compliant with RFC 4122, I recommend that we 
use Version 4 (random) UUIDs, with the random bits extracted from the 
double-SHA256 hash of the genesis block of the chain. (For colored 
coins, the colored coin definition transaction would be used instead, 
but I will address that in a separate proposal and will say just one 
thing about it: adopting this method for identifying chains/coins will 
greatly assist in adopting the payment protocol to colored coins.)

The following Python code illustrates how to construct the chain 
identifier from the serialized genesis block:

     from hashlib import sha256
     from uuid import UUID
     def chain_uuid(serialized_genesis_block):
         h = sha256(serialized_genesis_block).digest()
         h = sha256(h).digest()
         h = h[:16]
         h = ''.join([
             h[:6],
             chr(0x40 | ord(h[6]) & 0x0f),
             h[7],
             chr(0x80 | ord(h[8]) & 0x3f),
             h[9:]
         ])
         return UUID(bytes=h)

And some example chain identifiers:

     mainnet:  UUID('6fe28c0a-b6f1-4372-81a6-a246ae63f74f')
     testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9cec3ae')
     namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b157c80')

As for encoding the chain identifier, the simplest method is to give 
"network" the "bytes" type, but defining a "UUID" message type is also 
possible. In either case bitcoin mainnet would be the default, so the 
extra 12 bytes (vs: "main" or "test") would only be an issue for 
alt-chains or colored coins.

Kind regards,
Mark Friedenbach

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

is there a way to do bitcoin-staging?

Is there a way to experiment with new features - eg committed coins - that
doesnt involve an altcoin in the conventional sense, and also doesnt impose
a big testing burden on bitcoin main which is a security and testing risk?

eg lets say some form of merged mine where an alt-coin lets call it
bitcoin-staging?  where the coins are the same coins as on bitcoin, the
mining power goes to bitcoin main, so some aspect of merged mining, but no
native mining.  and ability to use bitcoins by locking them on bitcoin to
move them to bitcoin-staging and vice versa (ie exchange them 1:1
cryptographically, no exchange).

Did anyone figure anything like that out?  Seems vaguely doable and
maybe productive.  The only people with coins at risk of defects in a new
feature, or insufficiently well tested novel feature are people with coins
on bitcoin-staging.

Yes I know about bitcoin-test this is not it.  I mean a real live system,
with live value, but that is intentionally wanting to avoid forking bitcoins
parameters, nor value, nor mindshare dillution.  In this way something
potentially interesting could move forward faster, and be les risky to the
main bitcoin network.  eg particularly defenses against 

It might also be a more real world test test (after bitcoin-test) because
some parameters are different on test, and some issues may not manifest
without more real activity.

Then also bitcoin could cherry pick interesting patches and merge them after
extensive real-world validation with real-money at stake (by early
adopters).

Adam

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Service bits for pruned nodes

We would only end up with few copies of the historic data if users
could choose what parts of the blockchain to store. Simply store
chunks randomly, according to users available space, and give priority
to the "N most recent" chunks to have more replicas in the network.

You don't need bittorrent specifically for a DHT, if publicity is a
problem. There are many DHT proposals and implementations, and i bet
one of them should be more suitable to the bitcoin network than
bittorrent's.

>On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn <mike <at> ...> wrote:
>> I'd imagined that nodes would be able to pick their own ranges to keep
>> rather than have fixed chosen intervals. "Everything or two weeks" is rather
>
>X most recent is special for two reasons:  It meshes well with actual demand,
>and the data is required for reorganization.
>
>So whatever we do for historic data, N most recent should be treated specially.
>
>But I also agree that its important that <everything> be splittable into ranges
>because otherwise when having to choose between serving historic data
>and— say— 40 GB storage, a great many are going to choose not to serve
>historic data... and so nodes may be willing to contribute 4-39 GB storage
>to the network there will be no good way for them to do so and we may end
>up with too few copies of the historic data available.
>
>As can be seen in the graph, once you get past the most recent 4000
>blocks the probability is fairly uniform... so "N most recent" is not a
>good way to divide load for the older blocks. But simple ranges— perhaps
>quantized to groups of 100 or 1000 blocks or something— would work fine.
>
>This doesn't have to come in the first cut, however— and it needs new
>addr messages in any case.

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Modularizing Bitcoin

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2BTC reward for making probabalistic double-spending via conflicting transactions easy

Now that I have the replace-by-fee reward, I might as well spread the
wealth a bit.

So for all this discussion about replace-by-fee and the supposed
security of zero-conf transactions, no-one seems to think much about how
in practice very few vendors have a setup to detect if conflicting
transactions were broadcast on the network simultaneously - after all if
that is the case which transaction gets mined is up to chance, so much
of the time you'll get away with a double spend. We don't yet have a
mechanism to propagate double-spend warnings, and funny enough, in the
case of a single txin transaction the double-spend warning is also
enough information to allow miners to implement replace-by-fee.

So I'm offering 2BTC for anyone who comes up with a nice and easy to use
command line tool that lets you automagically create one version of the
transaction sending the coins to the desired recipient, and another
version sending all the coins back to you, both with the same
transaction inputs. In addition to creating the two versions, you need
to find a way to broadcast them both simultaneously to different nodes
on the network. One clever approach might be to use blockchain.info's
raw transaction POST API, and your local Bitcoin node.

If you happen to be at the conference, a cool demo would be to
demonstrate the attack against my Android wallet. I'll buy Bitcoins off
of you at Mt. Gox rates + %10, and you can see if you can rip me off.
Yes, you can keep the loot. :) This should be videotaped so we can put
an educational video on youtube after.

--

-- 
'peter'[:-1] <at> petertodd.org
00000000000000bafd0a55f013e058cc2a672ee0c66b9265a02390d80e4748f5

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

RFC: c32d encoding

https://bitcointalk.org/?topic=205878

This encoding is designed so that it could replace Base58Check in new data, 
with the following goals in mind:
- Impossible(?) to manipulate without completely changing it
- Clearly identifiable prefix, regardless of data size
- Cheaper to process (simpler and faster code; it's a power-of-two radix)
- Fixed length string for fixed length data
- More unambiguous (removal of chars 'isuvzSVZ')
- Compatible with using seven-segment displays
- Altcoin friendly (16 bit namespace, which can be read without decoding)

Since there are fewer digits and more identifying/signature characters, 
addresses are longer. This should be less of a problem since ordinary users 
will hopefully be using addresses less common as the payment protocol becomes 
more popular.

Example Python code (including tests) is attached.
I can write up a formal BIP if this seems useful.

For example:

160 bits of data, such as current addresses:
    2nc111dhAPE2aUdYAOF88JhLn5jEjbULy4eFe9tyFYFE8
An ordinary P2SH destination, incorporating Greg's "require the hash mid-image 
to be relayed" concept (256 bits of data):
    2bc511A95e74P13dPb6b5t7yrh12EhC363ayH98n1cFbr3rAHdA49nCcC1G3P71j
The same key in Namecoin:
    2nc5119ttL35HPhc3Hh6aHe2tOhF6rdFtAOE1ahFLt9Ecabhcn5FLea5Le71P56C
The example "puzzle" script from the wiki (arbitrary scripting):
    2bc311d126acCyAnHAjabeUtOHcr7F811j4UYE6ECtOcbcGGn4O9chAt7O7y2LU9ty9cnG4
An alternative for BIP32 extended public keys (560 bits):
    2bc911AcchHheAGFnn9LC6FdF7bOc99APJtcEc46U655JheH6LCr3Y333eFEOtPJ9rj22rEcchHheAGFnn9LC6FdF7bOc99APJtcEc46U655JheH6LCr3YJCtPYea
An alternative for BIP32 extended private keys (552 bits):
    2bcb11O77GHdP53FH7Jh44OdEh3rLd4eFr2h7c8rGeErELG18yCy9O7L9LednyHJa5hyeAP77GHdP53FH7Jh44OdEh3rLd4eFr2h7c8rGeErELG18yCyGG5drPF1

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Bitcoin2013 Speakers: Include your PGP fingerprint in your slides

report: https://bitcointalk.org/index.php?topic=205349.0

Every talk will be widely witnessed and videotaped so we can get some
reasonably good security by simply putting out PGP fingerprints in our
slides. Yeah, some fancy attacker could change the videos after the
fact, but the talks themselves will have wide audiences and a lot of
opportunities for fraud to be discovered. That means it'd also be
reasonable for people to sign those keys too if you are present and are
convinced you aren't looking at some impostor. (of course, presenters,
check that your PGP fingerprints are correct...)

Remember that PGP depends on the web-of-trust. No single measure in a
web-of-trust is needs to be absolutely perfect; it's the sum of the
verifications that matter. I don't think it matters much if you have,
say, seen Jeff Garzik's drivers license as much as it matters that you
have seen him in a public place with dozens of witnesses that would
recognize him and call out any attempt at fraud.

Secondly remember that many of us are working on software where an
attacker can steal from huge numbers of users at once if they manage to
sneak some wallet stealing code in. We need better code signing
practices, but they don't help without some way of being sure the keys
signing the code are valid. SSL and certificate authorities have
advantages, and so does the PGP WoT, so use both.

FWIW I take this stuff pretty seriously myself. I generated my key
securely in the first place, I use a hardware smartcard to store my PGP
key, and I keep the master signing key - the key with the ability to
sign other keys - separate from my day-to-day signing subkeys. I also
PGP sign emails regularly, which means anyone can get a decent idea of
if they have the right key by looking at bitcoin-development mailing
list archives and checking the signatures. A truly dedicated attacker
could probably sign something without my knowledge, but I've certainly
raised the bar.

--

-- 
'peter'[:-1] <at> petertodd.org
000000000000016be577c0f0ce4c04a05fdbfc8e0b6f69053659f32aeea3a518

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

ecash and revocability

So back in 1999, in an ecash thread on cypherpunks I claimed:

http://marc.info/?l=cypherpunks&m=95280154629900&w=2

> I wouldn't say ecash has to use blinding, but I would argue it would be a
> misuse of the word "ecash", if something which was revocable were dubbed
> ecash.

This was in the context of a discussion of digigold (e-gold stored the
physical gold, digigold offered "ecash" backed in that physical gold). 
Digigold ran on Systemics payment server/sox protocol.  Because of inferred
regulatory concerns and patent licensing issues digigold & systemics were
not using blind signatures.  However with systemics sox server, like
bitcoin, you could create multiple accounts on demand and shuffle payments
around for a degree of privacy.  The bitcoin analogy would be the
transaction log lived in the systemics server, so it had a central failure
point, but arguably more privacy as the log was not public.  Also systemics
SOX protocol (Ian Grigg & Gary Howland) had some aspect of bitcoins smart
contract concepts - ricardian contracts. 
http://iang.org/papers/ricardian_contract.html 

(Btw the anonymous reply itself was interesting -
http://marc.info/?l=cypherpunks&m=95280154629912&w=2 that could have been
Nakamoto, the only missing thing from the parts on the discussion room floor
to bitcoin is mathematical inflation control.)

The thread actually started here
http://marc.info/?l=cypherpunks&m=95280154629912&w=2 and then continues here
http://marc.info/?l=cypherpunks&m=95280154629900&w=2 because of a subject
line change and then http://marc.info/?l=cypherpunks&m=95280154629916&w=2
and http://marc.info/?l=cypherpunks&m=95280154629948&w=2
more subject line change confusion.

A related thread a few days later also covers Sander & Ta-Shma (which
zerocoin is based on):

http://marc.info/?l=cypherpunks&m=95280154630167&w=2

there were many more threads about various ecash technologies.

Adam

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d