Re: [Bitcoin-development] Determine input addresses of a transaction

2011-10-24 Thread Simon Barber
PKI would avoid the need for the trust aggregator to be consulted for 
each transaction. Obviously checking for revocation would be essential. 
The CA cert can state what kind of guarantee is available.

Simon


On 10/24/2011 09:25 AM, Mike Hearn wrote:
 You know, just thinking out loud...

 Green addresses could be implemented as a second signature in the
 scriptSig.


 I think this would solve one of the other issues I raised about the
 green address idea  you can have some kind of trust aggregator sign
 the transactions. Merchants like MtGox that send would create a
 transaction, export it, upload it to the trusted authority which can
 just check IP address or something to verify it's really coming from
 MtGox, then sign it and broadcast it.




 --
 The demand for IT networking professionals continues to grow, and the
 demand for specialized networking skills is growing even more rapidly.
 Take a complimentary Learning@Cisco Self-Assessment and learn
 about Cisco certifications, training, and career opportunities.
 http://p.sf.net/sfu/cisco-dev2dev



 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

2012-06-15 Thread Simon Barber
separate filterinit / filterload - so you can do a new filterload later 
on if your list changes, without the privacy implications of filteradd.

Simon


On Thu 14 Jun 2012 04:52:29 AM PDT, Mike Hearn wrote:
 filterinit(false positive rate, number of elements): initialize
 filterload(data): input a serialized bloom filter table metadata and data.

 Why not combine these two?

 'filterload' and 'filteradd' enable special behavior changes for
 'mempool' and existing P2P commands, whereby only transactions
 matching the bloom filter will be announced to the connection, and
 only matching transactions will be sent inside serialized blocks.

 Need to specify the format of how these arrive. It means that when a
 new block is found instead of inv-getdata-block we'd see something
 like  inv-getdata-merkleblock where a merkleblock structure is a
 header + list of transactions + list of merkle branches linking them
 to the root. I think CMerkleTx already knows how to serialize this,
 but it redundantly includes the block hash which would not be
 necessary for a merkleblock message.

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Fwd: Service bits for pruned nodes

2013-04-30 Thread Simon Barber
And then the problem of what domain name to use - ideally a single name 
would be used so caches had the maximum chance to reuse content. To 
keep the network distributed perhaps the existing DNS seed mechanism 
could be used - a few names, each serving a random bitcoind's address. 
Put :8333 after the name, and enhance bitcoind to respond to HTTP and 
p2p caching would be used!

Simon


On Tue 30 Apr 2013 12:27:10 PM PDT, Andy Parkins wrote:
 On Tuesday 30 April 2013 19:04:59 Jeff Garzik wrote:

 The format currently used by bitcoind would be just fine --
 blocks/blk.dat for raw data, size-limited well below 1GB.  Just
 need to add a small metadata download, and serve the raw block files.

 That doesn't seem very generic.  It's tied far too much to the current storage
 format of bitcoind.

 Wouldn't it be better to add support for more bitcoin-protocol-oriented HTTP
 requests?  Then any client can supply the same interface, rather than being
 forced to create blk.dat on the fly?

   http://bitcoind.example.com/block/BBB
   http://bitcoind.example.com/tx/
   http://bitcoind.example.com/block/oftx/TTT
   http://bitcoind.example.com/peers
   http://bitcoind.example.com/peer/nnn

 Essentially: block explorer's raw mode but in every bitcoind.  The hardest
 operation for light clients is finding out the block that contains a
 particular transaction -- something that bitcoind already knows.

 I'd like to see support for HTTP POST/PUT of signed transactions and block
 announcements too.



 Andy


--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
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