Re: [Bitcoin-development] merged mining hashcash & bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-14 Thread Adam Back 
On Mon, May 13, 2013 at 06:00:27PM -0400, Jeff Garzik wrote:
>When a transaction's input value exceeds its output value, the
>remainder is the transaction fee.  The miner's reward for processing
>transactions is the 25 BTC initial currency distribution + the sum of
>all per-transaction fees.  A destroy-by-miner fee transaction is a
>normal bitcoin transaction sent by any user, that might look like
>
>Input 1: 1.0 BTC
>Output 1: 0.5 BTC
>
>(the miner fee is implicitly 0.5 BTC, paid to whomever mines the
>transaction into a block)
>
>Sadly the bitcoin protocol prevents zero-output,
>give-it-all-to-the-miner transactions.

Well if it is a later transaction, not an integral part of the reward
transaction (that is definitionally mined by being serialized into the
coinbase), the user may elect to withhold the promised transaction
give-to-miner, so thats not so good.

Or do you mean to say you could have (implicit reward 25BTC) and reward
transaction .001 BTC to self and 24.999 BTC with existing bitcoin format and
validation semantics?  That would be close enough to give-to-miner.  Also
the output sum > 0BTC limitation could be changed to >= maybe... (just one
well placed character :)

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
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] ecash and revocability

2013-05-14 Thread Adam Back 
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
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability)

2013-05-14 Thread Adam Back 
On Tue, May 14, 2013 at 01:51:51PM +0200, Adam Back wrote:
> Adam Back in Sep 1999, cypherpunks list:
>>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.

So I still think that is an important point.  "Ecash should not be
revocable".  I think bitcoin currently has a partial problem because of
taint.

Now blinding based unlinkability, in a distributed cryptographic payer/payee
anonymous system like Sander & Ta Shma [1] and zerocoin has so far been
based on ZKP of set membership.  Of course that is somewhat expensive,
though zerocoin improved the ZKP with an relatively efficient (but still
cut-and-choose) proof.

Bitcoins relative lack of privacy creates a problem with tainted coins
risking becoming unspendable, or spendable only with some users, or at a
discount.  So while the policy coded says all coins are equally acceptable,
the information exists so people can unilaterally reject them, depending on
what the taint is.  So far revocability hasnt reared it's head that I heard,
nor taint inspection too much?  However people have the choice and technical
means to check the taint and send the bitcoins back.


Another aspect is that bitcoin, like systemics sox/digigold, makes a
different privacy tradeoff.  Somewhat private, but not very much.

But it creates the question: could the taint issue be fixed efficiently (eg
even without blinding or ZKP of set membership?)


One related concept is commitments.  I think its relatively easy to commit
to a payment and lock a coin without identifying yourself, until the
commitment is released.  You might do the commitment, wait 6-blocks for
confirmation, then reveal the commitment.  Then that is like a self-issued
green coin with no need for trust, that can be immediately cleared.  The
recipient has to be committed to at the same time to prevent double
spending.

So just commit = H( input-pub ) H( transaction ) and put it in the block
chain.  Where transaction the is usual ( input signature, output-pub,
script).  (Fee for the commit would have to come from an unlinked coin or
the input-pub reveals the coin).  Wait 6 blocks, send/reveal the transaction
(free because fee was already paid).  Validators check input-pub hash
against committed coins by hash, check the transaction hash, and the usual
ransaction validations = sum inputs, otherwise reject.  The user better pay
change if any to a different public key, as the inputs public keys are one
use - are after the reveal they are DoS lockable by other people reposting
H( input-pub ).

The input-pub coin is locked as normal transactions have their public key hash
validate as not being locked.

Adam

[1] Sander & Ta Shma "Auditable, Anonymous Electronic Cash"
 http://www.cs.tau.ac.il/~amnon/Papers/ST.crypto99.pdf

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability)

2013-05-14 Thread Simon Barber 
Adam,

Take a look at this privacy enhancing solution based on fair exchange 
implemented by bitcoin contracts and cut-and-choose. It would require a 
public pool of users willing to exchange in common denominations at 
moments in time together to ensure unlinkability. It also leave a trace 
of exchange activity in the chain. This could all be added to wallet 
software to become automatic.

http://robotics.stanford.edu/~xb/fc12/index.html

Simon


On 05/14/2013 07:09 AM, Adam Back wrote:
> On Tue, May 14, 2013 at 01:51:51PM +0200, Adam Back wrote:
>> Adam Back in Sep 1999, cypherpunks list:
>>> 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.
>
> So I still think that is an important point.  "Ecash should not be
> revocable".  I think bitcoin currently has a partial problem because of
> taint.
>
> Now blinding based unlinkability, in a distributed cryptographic payer/payee
> anonymous system like Sander & Ta Shma [1] and zerocoin has so far been
> based on ZKP of set membership.  Of course that is somewhat expensive,
> though zerocoin improved the ZKP with an relatively efficient (but still
> cut-and-choose) proof.
>
> Bitcoins relative lack of privacy creates a problem with tainted coins
> risking becoming unspendable, or spendable only with some users, or at a
> discount.  So while the policy coded says all coins are equally acceptable,
> the information exists so people can unilaterally reject them, depending on
> what the taint is.  So far revocability hasnt reared it's head that I heard,
> nor taint inspection too much?  However people have the choice and technical
> means to check the taint and send the bitcoins back.
>
>
> Another aspect is that bitcoin, like systemics sox/digigold, makes a
> different privacy tradeoff.  Somewhat private, but not very much.
>
> But it creates the question: could the taint issue be fixed efficiently (eg
> even without blinding or ZKP of set membership?)
>
>
> One related concept is commitments.  I think its relatively easy to commit
> to a payment and lock a coin without identifying yourself, until the
> commitment is released.  You might do the commitment, wait 6-blocks for
> confirmation, then reveal the commitment.  Then that is like a self-issued
> green coin with no need for trust, that can be immediately cleared.  The
> recipient has to be committed to at the same time to prevent double
> spending.
>
> So just commit = H( input-pub ) H( transaction ) and put it in the block
> chain.  Where transaction the is usual ( input signature, output-pub,
> script).  (Fee for the commit would have to come from an unlinked coin or
> the input-pub reveals the coin).  Wait 6 blocks, send/reveal the transaction
> (free because fee was already paid).  Validators check input-pub hash
> against committed coins by hash, check the transaction hash, and the usual
> ransaction validations = sum inputs, otherwise reject.  The user better pay
> change if any to a different public key, as the inputs public keys are one
> use - are after the reveal they are DoS lockable by other people reposting
> H( input-pub ).
>
> The input-pub coin is locked as normal transactions have their public key hash
> validate as not being locked.
>
> Adam
>
> [1] Sander & Ta Shma "Auditable, Anonymous Electronic Cash"
>   http://www.cs.tau.ac.il/~amnon/Papers/ST.crypto99.pdf
>
> --
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] merged mining hashcash & bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-14 Thread Jeff Garzik 
On Tue, May 14, 2013 at 5:25 AM, Adam Back  wrote:
> On Mon, May 13, 2013 at 06:00:27PM -0400, Jeff Garzik wrote:
>>
>> When a transaction's input value exceeds its output value, the
>> remainder is the transaction fee.  The miner's reward for processing
>> transactions is the 25 BTC initial currency distribution + the sum of
>> all per-transaction fees.  A destroy-by-miner fee transaction is a
>> normal bitcoin transaction sent by any user, that might look like
>>
>> Input 1: 1.0 BTC
>> Output 1: 0.5 BTC
>>
>> (the miner fee is implicitly 0.5 BTC, paid to whomever mines the
>> transaction into a block)
>>
>> Sadly the bitcoin protocol prevents zero-output,
>> give-it-all-to-the-miner transactions.
>
>
> Well if it is a later transaction, not an integral part of the reward
> transaction (that is definitionally mined by being serialized into the
> coinbase), the user may elect to withhold the promised transaction
> give-to-miner, so thats not so good.

That evaluation largely depends on the needs of the service in question.

In my decentralized identity (SIN) example, you merely need to prove
to the cloud that you sacrificed some bitcoins to any-miner.  The
confirmed, in-chain, non-coinbase transaction becomes the root node
for off-chain identity data.

The penalty for the user withholding the sacrifice transaction is that
their SIN is not created.  That incentive may not exist in that way,
in another service.

> Or do you mean to say you could have (implicit reward 25BTC) and reward
> transaction .001 BTC to self and 24.999 BTC with existing bitcoin format and
> validation semantics?  That would be close enough to give-to-miner.  Also
> the output sum > 0BTC limitation could be changed to >= maybe... (just one
> well placed character :)

Just referring to a standard, fee-bearing, user-created bitcoin
transaction, where output_value < input_value.  The fee is paid to the
first miner who includes that transaction in a block, as part of the
protocol.

-- 
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] merged mining hashcash & bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-14 Thread Mike Hearn 
> I've been thinking about a decentralized way to create an anonymous
> identity


This is the fidelity bond/anonymous passport idea that has been kicked
around in the forums quite a few times. I mentioned it on the tor-talk once
as a solution to the problem that you cannot create Google accounts via Tor
without a phone number. It's a good idea but not new. I have encouraged
people to implement a server that does it and then some integration for
MediaWiki, Wordpress or phpBB, as they're both quite common software that
gets a lot of spam and abuse. For instance we could use it on our own wiki
instead of paying the wiki operator (does anyone know what happens to those
funds by the way?).

You don't need GPG or anything like that - the transactions that spend to
fees also contain pubkeys in the inputs, which you own the private keys
for. So you can sign a challenge nonce from the server to prove ownership
of the "passport"/fidelity bond.
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] bitcoin taint & unilateral revocability (Re: ecash and revocability)

2013-05-14 Thread grarpamp 
> Bitcoins relative lack of privacy creates a problem with tainted coins
> risking becoming unspendable, or spendable only with some users, or at a
> discount.  So while the policy coded says all coins are equally acceptable,
> the information exists so people can unilaterally reject them, depending on
> what the taint is.  So far revocability hasnt reared it's head that I heard,
> nor taint inspection too much?  However people have the choice and technical
> means to check the taint and send the bitcoins back.

a) Is there a paper detailing bitcoin traceability issues?
Particularly when using various combinations of the often
advised 'use different address for every transaction', 'wash coins',
and 'use anonymity networks' privacy enhancement methods.

b) People would be nuts to reject tainted coins on the current
chain, or any chain. How many of the bills in your wallet passed
through 'illicit' transactions? How would you feel if your payee's
serial checker bounced yours, possibly forcing you to dispense
with them through other, possibly illicit, means? What about a
total blackball? Who's going to compensate you? How exactly do
you roll that all back? And are you going to KYC and scour the lives
of your every potential customer beforehand? What if someone has
money to burn and blackballs a million notes for fun. A currency of
common global adoption that you can't spend after some thieving
crackdealer bought an onion off your garden stand isn't of much use
to anyone, not even the purists who come up with such ideas.
Specialized currencies in special markets, sure, maybe, all still
fraught with the same dilemmas. But for a global common one? No.

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides

2013-05-14 Thread Peter Todd 
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]@petertodd.org
016be577c0f0ce4c04a05fdbfc8e0b6f69053659f32aeea3a518


signature.asc
Description: Digital signature
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides

2013-05-14 Thread Melvin Carvalho 
On 14 May 2013 20:41, Peter Todd  wrote:

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

Just out of curiosity, could PGP keyservers suffer from a similar 51%
attack as the bitcoin network?


>
> --
> 'peter'[:-1]@petertodd.org
> 016be577c0f0ce4c04a05fdbfc8e0b6f69053659f32aeea3a518
>
>
> --
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides

2013-05-14 Thread Peter Todd 
On Tue, May 14, 2013 at 09:16:28PM +0200, Melvin Carvalho wrote:
> > 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.
> >
> 
> Just out of curiosity, could PGP keyservers suffer from a similar 51%
> attack as the bitcoin network?

What guarantees do you think a keyserver provides about the keys it
returns?

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


signature.asc
Description: Digital signature
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides

2013-05-14 Thread Harald Schilly 
On Tue, May 14, 2013 at 9:16 PM, Melvin Carvalho
 wrote:
> Just out of curiosity, could PGP keyservers suffer from a similar 51% attack
> as the bitcoin network?

Well, no, and yes. It doesn't work like that.

If you have your own domain, you can store your key there as a TXT entry.

$ dig +short harald._pka.schil.ly. TXT

and even use it automatically:
$ gpg … --auto-key-locate pka -r email@address.domain

H

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] merged mining hashcash & bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-14 Thread Adam Back 
On Tue, May 14, 2013 at 12:50:27PM -0400, Jeff Garzik wrote:
>> Well if it is a later transaction, not an integral part of the reward
>> transaction (that is definitionally mined by being serialized into the
>> coinbase), the user may elect to withhold the promised transaction
>> give-to-miner, so thats not so good. [...]
>[...]
>Just referring to a standard, fee-bearing, user-created bitcoin
>transaction, where output_value < input_value.  The fee is paid to the
>first miner who includes that transaction in a block, as part of the
>protocol.

Yes but thats inferior in the sense that it is spamming the bitcoin payment
protocol slightly, to the small reward of miners, and involves actual money
and traceability to real-name (where did you get the coin from to spend). 

If alternatively you just proof you direct mined on a block with a coinbase
that immediately makes payment to future miners its better because: a) you
can do that with no new traffic for the bitcoin network (except when you
mine a whole block, you'll post it); and b) anyone with a reasonable
verification on the blockchain head (even if the spender has to give it to
them!) can verify it without any other network traffic; and c) if its
micro-mined on the spot it can be bound to the service whereas if you give
it to fees as an on network transaction you are limited to values above the
min tx fee.  

So idealy I think you need to be able to simultanously mine and give reward
to future block miners.

What you could do with out that is d) mine for the reward of bitcoin
foundation/software author/or service provider.  In the last case (service
provider) its an extreme form of Rivests peppercoin probabilistic payment

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
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides

2013-05-14 Thread Adam Back 
On Tue, May 14, 2013 at 09:39:46PM +0200, Harald Schilly wrote:
>If you have your own domain, you can store your key there as a TXT entry.
>
>$ dig +short harald._pka.schil.ly. TXT
>
>and even use it automatically:
>$ gpg … --auto-key-locate pka -r email@address.domain

Nice.  But we all kow about the security of DNS ;)

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
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] RFC: c32d encoding

2013-05-14 Thread Luke-Jr 
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
# Digits are chosen to be the least ambiguous
# They all have unique seven-segment glyphs, and cannot be easily confused by humans
digits = '123456789abcdehjnrtyACEFGHJLOPUY'
radix = len(digits)

def encode(v):
	if not len(v):
		return ''
	n = 0
	bits = 0
	o = []
	pad = (len(v) * 8) % 5
	if pad:
		v = b'\0' + v
	v = bytearray(v)  # For Python 2.7 compatibility
	for i in range(len(v) - 1, -1, -1):
		n |= v[i] << bits
		bits += 8
		while bits >= 5:
			o.insert(0, digits[n & 0x1f])
			n >>= 5
			bits -= 5
			if i == 0 and pad:
break
	return ''.join(o)

def decode(s):
	n = 0
	bits = 0
	o = bytearray()
	for i in range(len(s) - 1, -1, -1):
		n |= digits.index(s[i]) << bits
		bits += 5
		while bits >= 8:
			o.insert(0, n & 0xff)
			n >>= 8
			bits -= 8
	return bytes(o)

def test():
	from math import ceil
	assert '' == encode(b'')
	for (i, oc) in (
		(1, '8'),
		(2, '2'),
		(3, 'j'),
		(4, '4'),
		(5, 'Y'),
		(6, '8'),
		(7, '2'),
		(8, 'j'),
		(9, '4'),
	):
		ol = int(ceil(i * 8 / 5.))
		try:
			inzero = b'\0' * i
			inone = b'\xff' * i
			ezero = encode(inzero)
			eone = encode(inone)
			dzero = decode(ezero)
			done = decode(eone)
			
			assert ezero == '1' * ol
			assert eone == oc + ('Y' * (ol - 1))
			assert dzero == inzero
			assert done == inone
		except AssertionError:
			raise AssertionError('Input of length %s failed test' % (i,))
	try:
		for c in range(1024):
			decode('111' + chr(c))
	except ValueError:
		pass
	else:
		raise AssertionError('Invalid decode input (%02x) did not throw a ValueError' % (c,))

if __name__ == '__main__':
	test()
	print("Tests passed")
import c32
import hashlib
import struct

def _checksum(v):
	return hashlib.sha256(hashlib.sha256(v).digest()).digest()[-4:]

'''
String format:
- c32(Raw format) in reverse order

Raw format:
- 4 bytes checksum
- N bytes data (NOTE: encoded to prevent hidden changes)
- - for script:
- - - N bytes: varint preimage data length
- - - N bytes: preimage data
- - - N bytes: script data
- - for BIP32 HD parent key:
- - - 32 bytes: chain code
- - - 33 bytes: parent pubkey
- - for BIP32 serialized key:
- - - 1 byte: depth
- - - 4 bytes: child number
- - - 32 bytes: chain code
- - - One of:
- - - - 32 bytes: private key data
- - - - 33 bytes: public key data
- 1 byte flag (ignored if unknown)
- 1 byte type
- - 01 script (with preimage data)
- - 02 script hash preimage
- - 03 BIP32 HD parent key
- - 04 BIP32 serialized public key
- 2 bytes namespace (blockchain id)
- - 2d41 Bitcoin  ('2bc')
- - 2e01 Namecoin ('2nc')
- - 2e37 Freicoin ('FRC')
'''

class c32d:
	__slots__ = ('data', 'ns', 'dtype', 'dflag')
	
	def __init__(self, data, ns, dtype, dflag):
		self.data = data
		self.ns = ns
		self.dtype = dtype
		self.dflag = dflag
	
	@classmethod
	def decode(cls, s, raw = False):
		if not raw:
			full = c32.decode(s[::-1])
		else:
			full = s
		
		csum = bytearray(full[:4])
		v = bytearray(full[4:])
		
		# Encode the configuration bytes to simplify decoding
		pv = 0xbf
		for i in range(len(v) - 1, len(v) - 5, -1):
			pv = v[i] ^ (csum[i % 4]) ^ pv
			v[i] = pv
		
		v.append(0xbf)
		for i in range(len(v) - 1):
			v[i] ^= csum[i % 4] ^ v[i + 1]
		v.pop()
		
		v = bytes(v)
		if cs