Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Chris Pacia
On 06/18/2015 06:33 PM, Mark Friedenbach wrote:

   * Get safe forms of replace-by-fee and child-pays-for-parent
 finished and in 0.12.
   * Develop cross-platform libraries for managing micropayment
 channels, and get wallet authors to adopt
   * Use fidelity bonds, solvency proofs, and other tricks to minimize
 the risk of already deployed off-chain solutions as an interim measure
 until:
   * Deploy soft-fork changes for truly scalable solutions like
 Lightning Network.

One of my biggest concerns is that these solutions (lightning network in
particular) could end up being worse, in terms of decentralization, than
would be a bitcoin network using larger blocks. We don't exactly know
what the economies of scale are for pay hubs and could very well end up
with far fewer hubs than nodes at any conceivable block size.

Of course, it could also turn out to be fantastic, but it seems like an
enormous gamble to basically force everyone in the ecosystem to
collectively spend millions of dollars upgrading to Lightning /and then/
see whether it's actually an improvement in terms of decentralization.

To me, a much more sane approach would be to allow people to voluntarily
opt in to those other solutions after we've had an opportunity to
experiment with them and see how they actually function in practice, but
that can't happen if the network runs out of capacity first.

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


Re: [Bitcoin-development] bloom filtering, privacy

2015-02-21 Thread Chris Pacia
Adam seems to be making sense to me. Only querying a single node when an
address in my wallet matches the block filter seems to be pretty
efficient. The downside is it relies entirely on Tor for privacy, but
then again it's not the only aspect of spv clients that require it for
privacy (there's broadcasting for example).

And on a related note, if we eventually do end up receiving bip70
payments directly, we still need to query for block inclusion and that
would seem to be an easy way to do it.

On 02/20/2015 12:53 PM, Mike Hearn wrote:

 This is talking about a committed bloom filter. Not a committed
 UTXO set.


 I read the following comment to mean it requires the UTXO commitments.
 Otherwise I'm not sure how you prove absence of withholding with just
 current block structures+an extra filter included in the block:

 but with the bloom commitment (and UTXO trie organised commitment) he
 can verify that the positive hits are correct via the merkle path, and
 that the false positives are not being wrongly withheld by obtaining
 merkle path proof that they are not in the trie 





 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk


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

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bloom filtering, privacy

2015-02-21 Thread Chris Pacia
Yeah that overhead is pretty high. I wasn't thinking about 10 years out.

On Sat, Feb 21, 2015, 11:47 AM Mike Hearn m...@plan99.net wrote:

 Adam seems to be making sense to me. Only querying a single node when an
 address in my wallet matches the block filter seems to be pretty efficient.


 No, I think it's less efficient (for the client).

 Quick sums:  blocks with 1500 transactions in them are common today. But
 Bitcoin is growing. Let's imagine a system 10x larger than today. Doesn't
 seem implausible to reach that in the next 5-10 years, so 15,000
 transactions. Each transaction has multiple elements we might want to match
 (addresses, keys, etc).

 Let's say the average tx contains 5 unique keys/elements. That's the base
 case of {1 input, 2 outputs} without address reuse, plus fudged up a bit
 for multi-sends then down a bit again for address reuse.

 15,000*5=75,000 unique elements per block. With an FP rate of 0.1% we get:

 http://hur.st/bloomfilter?n=75000p=0.001

 131.63KB per block extra overhead.

 144 blocks in a day, so that's 18mb of data per day's worth of sync to
 pull down over the network. If you don't start your wallet for a week
 that's 126 megabytes of data just to get started.

 Affordable, yes (in the west). Fast enough to be competitive? Doubtful. I
 don't believe that even in five years mobiles will be pulling down and
 processing that much data within a few seconds, not even in developed
 countries.

 But like I said, I don't see why it matters. Anyone who is watching the
 wire close to you learns which transactions are yours, still, so it doesn't
 stop intelligence agencies. Anyone who is running a node learns which
 transactions in the requested block were yours and thus can follow the tx
 chain to learn which other transactions might be yours too, no different to
 today. If you connect to a single node and say give me the transactions
 sending money to key A in block N, it doesn't matter if you then don't
 request block N+6 from the same peer - they know you will request it
 eventually anyway, just by virtue of the fact that one of the transactions
 they gave you was spent in that block.



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-18 Thread Chris Pacia
On Nov 17, 2014 7:39 AM, Pieter Wuille pieter.wui...@gmail.com wrote:

 That is inevitable for any wallet that offers any functionality beyond
 just maintaining a balance and the ability to send coins. In
 particular, anything that wishes to list previous transaction (with
 timestamps, history, metadata, messages sent using t
 What HD wallets (or any type of deterministic derivation scheme) offer
 is the fact that you can separate secret data and public data. You
 only need one safe backup of the master secret key - all the rest can
 at most result in privacy loss and not in lost coins.

 --
 Pieter

I agree but right now wallets not using stealth will only lose metadata,
not coins, if their computer crashes and they have the seed backed up.

But if a user wants to upgrade to stealth, they then risk losing metadata
AND coins if they either didn't manually back up after every transaction or
use a centralized cloud backup service.

That's if OP_RETURN is not utilized for storage.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Chris Pacia

On 11/17/2014 06:20 AM, Adam Back wrote:
 b) backup: the blockchain is not an efficient reliable generic backup
 mechanism because its broadcast.  there are cheaper and relatively
 simple ways to get end2end secure backup, the main challenge of which
 is having secure keys and not forgetting them.  bitcoin already has
 that covered as its a central requirement of blockchain security.  If
 you want to archive your payment protocol receipts store them on some
 cloud storage service or disk encrypted with related keys.  for
 example tahoe-lafs is optimised for the decentralised long-term
 storage kind of use.

This is my main concern in the context of stealth addresses. I intend to
start a larger discussion on stealth addresses, but I wont hijack the
tread.

Of course it's easy to send the necessary data out of band as opposed to
OP_RETURN. The problem is if you do that the transaction cannot not be
recovered from seed. We've been fairly successful in transitioning to HD
wallets and avoiding the need to make regular wallet backups.

If users wishes to use stealth addresses with out of band communication,
the benefits of HD would largely be lost and they would be back to
making regular backups ― this time after /every/ transaction rather than
every 100.

There are only a couple options in such cases:

1) The user could send the payment to an addresses that is derived from
seed, but now you're using even /more/ storage space than you would by
just using OP_RETURN.

2) The user can backup after every transaction, which nobody wants to do.

3) The user could use some form of a cloud backup service and place
trust in them that their servers wont go down and lose their coins.

None of those options are really that appealing. OP_RETURN seems like
the best alternative to me, at least for that use case.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Update on mobile 2-factor wallets

2014-11-08 Thread Chris Pacia
Thanks Mike I'll have to read that threshold signature paper.

I am familiar with the Princeton threshold signature but I was under the
impression a single key needed to be generated on a single device then
split and distributed.

Does this scheme work the same way?

I would have concerns about generating a key on a compromised computer.
On Nov 8, 2014 11:05 AM, Mike Hearn m...@plan99.net wrote:

 Here is a summary of current developments in the space of decentralised
 2-factor Bitcoin wallets. I figured some people here might find it
 interesting.

 There has been very nice progress in the last month or two. Decentralised
 2FA wallets run on a desktop/laptop and have a (currently always Android)
 smartphone app to go with them. Compromise of the wallet requires
 compromise of both devices.

 Alon Muroch and Chris Pacia have made huge progress on Bitcoin
 Authenticator, their (HD) wallet app. The desktop side runs on
 Win/Mac/Linux and the mobile side runs on Android. Sending money from the
 desktop triggers a push notification to the mobile side, which presents the
 transaction for confirmation. Additionally the desktop wallet has a variety
 of other features like OneName integration. It's currently in alpha, but I
 suspect it will be quite popular once released due to its focus on UI and
 the simple mobile security model. I've tried it out and it worked fine.

 https://www.bitcoinauthenticator.org/
 https://github.com/cpacia/BitcoinAuthenticator/commits/master(mobile)
 https://github.com/negedzuregal/BitcoinAuthWallet   (desktop)

 Bitcoin Authenticator uses P2SH/CHECKMULTISIG to provide the 2-factor
 functionality. However, this has various downsides that are well known:
  less support for the address type and larger transactions that waste block
 chain space + result in higher fees.

 To solve this problem Christopher Mann and Daniel Loebenberger from Uni
 Bonn have ported the efficient DSA 2-of-2 signing protocol by MacKenzie and
 Reiter to ECDSA, and implemented their own desktop/Android wallet app pair
 showing that it works and has good enough performance. This means that P2SH
 / CHECKMULTISIG is no longer required for the two factor auth case, and
 thus it's as cheap as using regular addresses.

 https://github.com/ChristopherMann/2FactorWallet
 https://eprint.iacr.org/2014/629.pdf

 Their protocol uses an interesting combination of ECDSA, Paillier
 homomorphic encryption and some zero knowledge proofs to build a working
 solution for the 2-of-2 case only. Their app bootstraps from a QR code that
 includes a TLS public key and IP address of the desktop: the mobile app
 then connects to it directly, renders the transaction and performs the
 protocol when the user confirms. The protocol is online, so both devices
 must be physically present.

 Their code is liberally licensed and looks easy to integrate with Alon and
 Chris' more user focused work, as both projects are built with Android and
 the latest bitcoinj. If someone is interested, merging Christopher/Daniel's
 code into the bitcoinj multisig framework would be a useful project, and
 would make it easier for wallet devs to benefit from this work. I can write
 a design doc to follow if needed.

 Currently, neither of these projects implement support for BIP70, so the
 screen you see when signing the transaction is hardly user friendly or
 secure: you just have to trust that the destination address you're paying
 to isn't tampered with. Support for sending a full payment request between
 devices is the clear next step once these wallets have obtained a
 reasonable user base and are stable.




 --

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


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


Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties

2014-08-11 Thread Chris Pacia
One issue I do see is the protocol requires participants to check the
inputs submitted by others are valid. Lite clients (at least of the p2p
variety) cannot perform this check.

You could skip the verification part and if the inputs turn out to be
invalid then you'll find out when it doesn't confirm. This would problem
open the protocol up to dos attacks and prevent part of the blame phase
from working properly.

Alternatively you can have the participants submit the merkle proof for the
input. This would require inputs to have at least one confirmation, however.
On Aug 6, 2014 6:42 PM, Tim Ruffing tim.ruff...@mmci.uni-saarland.de
wrote:

 Hey,

 We (a group of researchers in Germany) propose a decentralized protocol for
 CoinJoin, a way to mix coins among users to improve anonymity. Our
 protocol is
 called CoinShuffle. We believe that CoinShuffle is a way to implement
 CoinJoin
 in the original spirit of Bitcoin, i.e., decentralized and without trusted
 third parties. (If you are not familiar with CoinJoin, the idea is
 explained
 here: https://bitcointalk.org/index.php?topic=279249.0 )

 The protocol is essentially a clever way to create a CoinJoin transaction.
 Recall that the idea of CoinJoin is mixing with one SINGLE transaction that
 has multiple input addresses and multiple fresh output addresses (i.e., one
 pair of addresses per user). The advantage of CoinJoin over mixing with a
 server or trusted party is that nobody can steal coins. Each user can
 check if
 the single transaction sends enough coins to his fresh output address. If
 this
 is not the case, the user can just refuse to sign the transaction and
 nothing
 (bad) happens.

 The difficulty in CoinJoin is to let the participants announce their fresh
 output addresses without breaking anonymity: Of course, if a participant of
 the protocol just announces I have 1 BTC at address X now and I would
 like
 to have it back at address Y, then everybody can link X and Y and mixing
 is
 useless. A naive approach is to send these two messages via a secure
 channel
 to a server that organizes the whole mixing. While the server cannot steal
 coins, the server still has to be trusted for anonymity, because it knows
 which input addresses belong to which output addresses.

 We present the list of CoinShuffle's features at the end of this e-mail. An
 overview over the technical details can be found on the project page:
 http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/

 Moreover, for the full details, have a look at the research paper on
 CoinShuffle that can be found here:
 http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf

 The paper has been accepted at a major European academic conference on
 security (ESORICS). We will present the idea there.

 Our Proof-of-concept Implementation
 ---
 There is a proof-of-concept implementation (written in Python) available on
 our project page. It is really only a proof-of-concept and it implements
 only
 the announcement of the addresses, not the creation of the transaction.
 Moreover, the code is CERTAINLY INSECURE and not well-written; our only
 goal
 was to demonstrate feasibility and estimate the performance of our
 approach.


 Our Future Plans
 
 Now we are planning a full, open-source implementation of the protocol. Of
 course, we would like to build on top of an existing wide-spread client.
 Since
 we do not have much experience in the design of existing Bitcoin clients,
 we
 would appreciate any help in the process. In particular, we did not decide
 which of the existing clients we would like to extend. Any hints towards
 this
 decisions would very helpful. Help in design and coding would be great but
 we
 also would like to hear your comments, criticism, and improvements for the
 protocol itself.

 CoinShuffle Features
 
 CoinShuffle has the following features:

  - Decentralization / no third party:
 There is no (trusted or untrusted) third party in a run of the protocol.
 (Still, as in all mixing solutions, users need some way to gather together
 before they can run the protocol. This can be done via a P2P protocol if a
 decentralized solution is desired also for this step.)


  - Unlinkability of input and output addresses:
 Nobody, in particular no server (there is none!), can link input and output
 addresses of a mixing transaction, as long as there are at least two honest
 participants in run of the protocol.

 (This is not a weakness: If there is only one honest participant,
 meaningful
 mixing is just impossible, no matter how it is organized. If all the other
 participants collude, they know all their input and output addresses and
 can
 immediately determine the output address of the honest participant.)

  - Security against thefts:
 As explained above, nobody can steal coins during the mixing because of the
 CoinJoin principle.
 Every participant can verify that his money will not be stolen. 

Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties

2014-08-11 Thread Chris Pacia
Actually getUTXO would probably work here as well. It isn't authenticated
but it should be good enough for this purpose. The worst that would happen
is the tx doesn't confirm.
On Aug 11, 2014 2:25 AM, Chris Pacia ctpa...@gmail.com wrote:

 One issue I do see is the protocol requires participants to check the
 inputs submitted by others are valid. Lite clients (at least of the p2p
 variety) cannot perform this check.

 You could skip the verification part and if the inputs turn out to be
 invalid then you'll find out when it doesn't confirm. This would problem
 open the protocol up to dos attacks and prevent part of the blame phase
 from working properly.

 Alternatively you can have the participants submit the merkle proof for
 the input. This would require inputs to have at least one confirmation,
 however.
 On Aug 6, 2014 6:42 PM, Tim Ruffing tim.ruff...@mmci.uni-saarland.de
 wrote:

 Hey,

 We (a group of researchers in Germany) propose a decentralized protocol
 for
 CoinJoin, a way to mix coins among users to improve anonymity. Our
 protocol is
 called CoinShuffle. We believe that CoinShuffle is a way to implement
 CoinJoin
 in the original spirit of Bitcoin, i.e., decentralized and without trusted
 third parties. (If you are not familiar with CoinJoin, the idea is
 explained
 here: https://bitcointalk.org/index.php?topic=279249.0 )

 The protocol is essentially a clever way to create a CoinJoin transaction.
 Recall that the idea of CoinJoin is mixing with one SINGLE transaction
 that
 has multiple input addresses and multiple fresh output addresses (i.e.,
 one
 pair of addresses per user). The advantage of CoinJoin over mixing with a
 server or trusted party is that nobody can steal coins. Each user can
 check if
 the single transaction sends enough coins to his fresh output address. If
 this
 is not the case, the user can just refuse to sign the transaction and
 nothing
 (bad) happens.

 The difficulty in CoinJoin is to let the participants announce their fresh
 output addresses without breaking anonymity: Of course, if a participant
 of
 the protocol just announces I have 1 BTC at address X now and I would
 like
 to have it back at address Y, then everybody can link X and Y and mixing
 is
 useless. A naive approach is to send these two messages via a secure
 channel
 to a server that organizes the whole mixing. While the server cannot steal
 coins, the server still has to be trusted for anonymity, because it knows
 which input addresses belong to which output addresses.

 We present the list of CoinShuffle's features at the end of this e-mail.
 An
 overview over the technical details can be found on the project page:
 http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/

 Moreover, for the full details, have a look at the research paper on
 CoinShuffle that can be found here:
 http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf

 The paper has been accepted at a major European academic conference on
 security (ESORICS). We will present the idea there.

 Our Proof-of-concept Implementation
 ---
 There is a proof-of-concept implementation (written in Python) available
 on
 our project page. It is really only a proof-of-concept and it implements
 only
 the announcement of the addresses, not the creation of the transaction.
 Moreover, the code is CERTAINLY INSECURE and not well-written; our only
 goal
 was to demonstrate feasibility and estimate the performance of our
 approach.


 Our Future Plans
 
 Now we are planning a full, open-source implementation of the protocol. Of
 course, we would like to build on top of an existing wide-spread client.
 Since
 we do not have much experience in the design of existing Bitcoin clients,
 we
 would appreciate any help in the process. In particular, we did not decide
 which of the existing clients we would like to extend. Any hints towards
 this
 decisions would very helpful. Help in design and coding would be great
 but we
 also would like to hear your comments, criticism, and improvements for the
 protocol itself.

 CoinShuffle Features
 
 CoinShuffle has the following features:

  - Decentralization / no third party:
 There is no (trusted or untrusted) third party in a run of the protocol.
 (Still, as in all mixing solutions, users need some way to gather together
 before they can run the protocol. This can be done via a P2P protocol if a
 decentralized solution is desired also for this step.)


  - Unlinkability of input and output addresses:
 Nobody, in particular no server (there is none!), can link input and
 output
 addresses of a mixing transaction, as long as there are at least two
 honest
 participants in run of the protocol.

 (This is not a weakness: If there is only one honest participant,
 meaningful
 mixing is just impossible, no matter how it is organized. If all the other
 participants collude, they know all their input and output addresses and
 can

Re: [Bitcoin-development] Paper Currency

2014-05-17 Thread Chris Pacia
Since these notes have to be redeemed immediately the number of use
cases seems limited. I can't really just hand someone the note and walk
away because they have to scan it to see if it is actually valid.
Otherwise someone could just pass fake notes if they felt the recipient
wouldn't redeem them on the spot. This doesn't seem like an improvement
over just sending the coins via phone.

The use case with poor internet connection wouldn't work as well since,
presumably, the recipient would also have poor reception and couldn't
verify the note was actually loaded with bitcoins.

Also, I REALLY don't like the name bit reserve.

-Chris

On 05/17/2014 11:31 AM, Jerry Felix wrote:
 It seems to me that there's a huge need for a paper currency that is
 counterfeit-resistant, inexpensive to print, internationally
 recognized (border-less), fits in a wallet, and machine readable.

 I pitched this idea at the Cincinnati Bitcoin meetup last week, and I
 didn't get thrown out, so I took the time to document a proposed
 standard to accomplish this.  I've put my ideas into BIP format, so
 that you can see what I have in mind, although I picked some
 BIP numbers myself that seem to be available.  Call them proposed
 proposals, or provisional BIPs.  I've numbered them provisionally
 BIP-80 to BIP-84.

 If you guys think that this idea has some merit, let's discuss.

 https://github.com/jerfelix/provisional_bips/blob/master/README.mediawiki

 Submitted with humility and some fear of getting laughed out of here...
 - Jerry




 --
 Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
 Instantly run your Selenium tests across 300+ browser/OS combos.
 Get unparalleled scalability from the best Selenium testing platform available
 Simple to use. Nothing to install. Get started now for free.
 http://p.sf.net/sfu/SauceLabs


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

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] ECDH in the payment protocol

2014-05-12 Thread Chris Pacia
Just a thought. Using the payment protocol for stealth would mean we
would likely have to return to backing up wallets all the time would it not?

The nonces cannot be derived from your wallet seed and, since they
aren't in the blockchain, would have to be stored in your wallet. I
suppose they could be stored on the server, but you would probably want
a backup for that anyway. So we would end up having to back up all the
time, something we're trying to get away from. Am I correct about this?

On 05/09/2014 02:38 PM, Pieter Wuille wrote:
 On Fri, May 9, 2014 at 8:13 PM, Peter Todd p...@petertodd.org wrote:
 I don't think we're going to find that's practical unfortunately due to
 change. Every payment I make ties up txouts, so if we try to base the
 atomicity of payments on whether or not the payee decides to broadcast
 the transaction the payor is stuck with txouts that they can't use until
 the payee makes up their mind. That leads to lots and lots of nasty edge
 cases.
 I haven't talked much about it except for on IRC, but my idea was this:
 * PaymentACK messages become signed (with the same key as the payment
 request, or using some delegation mechanism, so that the same key
 doesn't need to remain online).
 * Instead of a full Bitcoin transaction, a Payment message contains a
 scriptSig-less Bitcoin transaction + a limit on its byte size (and
 perhaps a limit on its sigop count).
 * The sender sends such a Payment to the receiver before actually
 signing the transaction (or at least, before revealing the signed
 form).
 * The receiver only ACKs if the transaction satisfies the request, is
 within time limits, isn't unlikely to confirm.
 * If the sender likes the ACK (the refund and memo fields are intact,
 the transaction isn't changed, the signature key is valid, ...), he
 either sends the full transaction (with receiver taking responsibility
 for broadcasting) or broadcasts it himself.

 Together, this means that a paymentACK + a confirmed matching Bitcoin
 transaction can count as proof of payment. Both parties have a chance
 to disagree with the transaction, and are certain all communicated
 data (apart from transaction signatures) in both directions happened
 correctly before committing. It would completely remove the chance
 that the Bitcoin transaction gets broadcast without the receiver
 liking it (for legitimate or illegitimate reasons), or without the
 backchannel functioning correctly.

 It's also compatible with doing multiple payments in one Bitcoin
 transaction - you can ask for ACKs from multiple parties before
 signing the transaction.

 Of course, the sender can still withhold the signed transaction (in
 which case nothing happened, but we probably need a second timeout),
 or the receiver can always claim to have never received the
 transaction. The sender can broadcast the transaction himself in order
 to prevent that, after obtaining an ACK.



--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bits: Unit of account

2014-05-03 Thread Chris Pacia
Absent a concerted effort to move to something else other than 'bits', I
would be willing to bet the nomenclature moves in that direction anyway.
'Bits' is just a shorten word for 'millibits' (or microbits, if you
will). It's easier to say and my guess is people would tend to use it
naturally own their own. Kind of like 'bucks' for dollars.

The other synergies are:
-bit is part of the word Bitcoin. The currency unit bit is part of a
whole bitcoin.
-bit symbolically represents the tech nature of the bitcoin.
-bit used to be a unit of money way back when. This largely reclaims it.
-when used as money bit when in references to a precession metal coin.
The name 'bitcoin' references that as well as the mimicking of the gold
standard in the protocol rules.

All around I don't think there is a better fit. I doubt people will get
confused by it. The context it's used in will distinguish it from other
uses of the word.

On 05/03/2014 12:27 PM, Mike Caldwell wrote:
 I agree with the sentiment that most people don't understand either computer 
 science or Bitcoin.  The goal of getting people to understand enough about 
 Bitcoin to use it is achievable and a goal that is in scope of our efforts. 
 Getting them to understand computer science at large at the same time, less 
 so.

 The fact that people routinely confuse RAM and hard drive sizes has much to 
 do with the fact that the average lay person has little need to prioritize 
 this as something to keep in the forefront.  They don't get horribly 
 confused, they just simply don't get worked up over what looks to them like a 
 rounding error, much to the dismay of anyone who believes that everyone 
 should be an expert at computer science.  The average joe may assess 
 (accurately from his perspective) that the distinction isn't important enough 
 to merit significant mental resources and he is justified in not expending 
 them that way even if someone else thinks he should.

 Poor understanding is precisely what a proper effort to name this would be to 
 avoid.  It is not frill or aesthetics, it is a planned targeting of language 
 to achieve the clearest communication to the widest possible target audience 
 using the language most likely to be understood by them in light of our 
 objectives.  It's marketing. 

 Mike

 Sent from my iPhone

 On May 3, 2014, at 9:49 AM, Christophe Biocca 
 christophe.bio...@gmail.com wrote:

 Context as a disambiguator works fine when the interlocutors
 understand the topics they're talking about.
 Not a day goes by without me seeing neurotypical people get horribly
 confused between RAM and Hard Drive sizes, because they share the same
 units (not that that can be helped, as the units are supposed to be
 the same, base 1000 vs 1024 notwithstanding).

 Bit (as a unit) is already really confusing for anyone who doesn't
 deal with it on a regular basis. I think people who don't see an issue
 are making an assumption based on their own lack of confusion. We
 understand computer science AND Bitcoin. Most people have zero
 understanding of either.

 Bitcoin already has a ton of issues with terrible names for things:

 - Mining (for transaction validation).
 - Addresses (which are meant to be one-time use, and don't even really
 exist at the network level).
 - Wallets (which don't hold your bitcoins, can be copied, and all
 backups can be stolen from equally).

 I end up having to make the distinctions obvious every time I explain
 Bitcoin to someone new to it. There's an acceptable tradeoff here,
 because there were arguably no better words to assign to these
 concepts (although I'd argue mining is a really awful metaphor, and is
 the one that prompts the most questions from people). Then add to the
 pile a bunch of third parties naming themselves after parts of the
 protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've
 definitiely seen average people get confused between the blockchain
 and blockchain.info (not so much Coinbase, because that name doesn't
 come up in beginner explanations).

 It seems downright masochistic to add
 yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile
 for no reason other than aesthetics. Are we actively trying to confuse
 people?
 --
 Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
 Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
 unparalleled scalability from the best Selenium testing platform available.
 Simple to use. Nothing to install. Get started now for free.
 http://p.sf.net/sfu/SauceLabs
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run 

Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Chris Pacia
This scheme would discourage people from attempting a Finney attack because
they would end up worse off if they did.

It would work but it's an ugly hack IMO. What do people do if they don't
have extra to pay when making a purchase? I have 200 mbtc and want to buy a
200 mbtc phone but I can't because I need 400 mbtc. Sucks for me.

I would much prefer the hassle of a green address notary than always having
to make sure I have double what I need to make a purchase.
On Apr 24, 2014 7:55 AM, Mike Hearn m...@plan99.net wrote:

 Am I missing something?


 The scheme you described does nothing about Finney attacks, which is the
 issue presently faced.


 --
 Start Your Social Network Today - Download eXo Platform
 Build your Enterprise Intranet with eXo Platform Software
 Java Based Open Source Intranet - Social, Extensible, Cloud Ready
 Get Started Now And Turn Your Intranet Into A Collaboration Platform
 http://p.sf.net/sfu/ExoPlatform
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Chris Pacia
What is the advantage of this proposal over just orphaning the block with
double spends?

There's currently a set of rules which government what constitutes a valid
block. Miners don't build on blocks that don't accord with those rules out
of fear that a major won't follow and they will waste hashing power.

If there was a rule supported by the majority that considered blocks with
double spends (defined in some fashion) as invalid miners wouldn't build on
them for the same reason they wouldn't build on a block with a coinbase
over 25 btc, say. It seems that would accomplish the same without the other
issues.
On Apr 23, 2014 12:04 PM, Christophe Biocca christophe.bio...@gmail.com
wrote:

 It's not necessary that this coinbase retribution be either
 profitable or risk-free for this scheme to work. I think we should
 separate out the different layers of the proposal:

 1. Attacking the coinbase instead of orphaning allows for 100 blocks'
 time for a consensus to be reached, rather than 10 minutes. This
 allows for human verification/intervention if needed (orphaning
 decisions would almost always need to be automated, due to the short
 timeframe). This is a useful insight, and I don't think it's been
 brought up before.

 2. The original specification of how it's done (redistribution, no
 cost to voting) does seem exploitable. This can be fixed by reducing
 the incentive (burning instead of redistributing) and/or adding a risk
 to the orphaning attempts (a vote that fails destroys X bitcoins'
 worth from each voting block's own coinbase). The incentives can be
 tailored to mirror those of orphaning a block, to reduce the risk of
 abuse. Then the only difference from orphaning are 1) More limited
 rewriting of history (only the coinbase, vs all transactions in the
 block), and 2) More time to coordinate a response.

 3. This proposal may be used for things other than punishing
 double-spend pools. In fact it might be used to punish miners for
 doing anything a significant percentage of hashpower dislikes (large
 OP_RETURNs, large blocks, gambling transactions, transactions banned
 by a government). But we can make the threshold higher than 51%, so
 that this doesn't turn into a significant risk (if 75% of hashpower is
 willing to enforce a rule, we're already likely to see it enforced
 through orphaning).

 On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi alex.mizr...@gmail.com
 wrote:
 
 
  And it still would. Non-collusive miners cast votes based on the outcome
  of their own attempts to double spend.
 
 
  Individually rational strategy is to vote for coinbase reallocation on
 every
  block.
 
  Yes, in that case nobody will get reward. It is similar to prisoner's
  dilemma: equilibrium has worst pay-off.
  In practice that would mean that simple game-theoretic models are no
 longer
  applicable, as they lead to absurd results.
 
 
  I'm using it in the same sense Satoshi used it. Honest miners work to
  prevent double spends. That's the entire justification for their
 existence.
  Miners that are deliberately trying to double spend are worse than
 useless.
 
 
  Miners work to get rewards.
  It absolutely doesn't matter whether they are deliberately trying to
  double-spend or not: they won't be able to double-spend without a
 collusion.
 
 
 --
  Start Your Social Network Today - Download eXo Platform
  Build your Enterprise Intranet with eXo Platform Software
  Java Based Open Source Intranet - Social, Extensible, Cloud Ready
  Get Started Now And Turn Your Intranet Into A Collaboration Platform
  http://p.sf.net/sfu/ExoPlatform
  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 


 --
 Start Your Social Network Today - Download eXo Platform
 Build your Enterprise Intranet with eXo Platform Software
 Java Based Open Source Intranet - Social, Extensible, Cloud Ready
 Get Started Now And Turn Your Intranet Into A Collaboration Platform
 http://p.sf.net/sfu/ExoPlatform
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bits: Unit of account

2014-04-20 Thread Chris Pacia
The term bit is really only overloaded for those who are techy. 95% of the
population never uses the term bit in their daily lives and I doubt most
could even name one use of the term.
Plus bit used to be a unit of money way back when, so this is kind of
reclaiming it. I think it's a great fit.
On Apr 20, 2014 11:52 AM, Alan Reiner etothe...@gmail.com wrote:

  I've been a staunch supporter of microbitcoin and would like to do
 anything I can to make sure that we jump directly to it if we're going to
 promote changing the default units.  And I'm happy to integrate it into
 Armory as a default (with appropriate explanations and settings/options).
 I'm not so convinced about the bits name though -- I do like it, but I do
 also think that word is too overloaded.  Though, I think we could get away
 with it.

 (Sadly, I still use microbes occasionally (as in *microb*itcoin) when
 I'm talking to coworkers, because it slips off the tongue and is actually a
 good combination of brevity and self-explanatory -- it just doesn't instill
 the right visuals...)

 We started integrating alternative units into Armory.  But, of course,
 there were a few more loose ends than I expected, which will require some
 work.   We want to put it in but not necessarily change the default right
 away.  I'd *prefer* we get some commitments from some other wallet
 developers, so we can make a unified push for it.  I'm happy to lead that
 and make it default as long as I'm not the only one in the world doing it.

 -Alan



 On 04/20/2014 11:05 AM, Tamas Blummer wrote:

 Here is an earlier reference to bits:


 https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04248.htmlhttps://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04248.html

  I forgot that Alan Reiner was also supporting a unit equals to bits :


 https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04264.htmlhttps://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04264.html

  and here the earlier going back to March 2013 and a poll at that time
 pushing for XBT being 1 bit


 https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04256.htmlhttps://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04256.html

  Regards,

 Tamas Blummer
 http://bitsofproof.com

  On 20.04.2014, at 16:53, Pieter Wuille pieter.wui...@gmail.com wrote:

 I told him specifically to bring it here (on a pull request for
 Bitcoin Core), as there is no point in making such convention changes
 to just one client.

 I wasn't aware of any discussion about the bits proposal here before.

 On Sun, Apr 20, 2014 at 4:28 PM, Tamas Blummer ta...@bitsofproof.com
 wrote:

 People on this list are mostly engineers who have no problem dealing with
 magnitudes and have rather limited empathy for people who have a problem
 with them.
 They also tend to think, that because they invented money 2.0 they would
 not
 need to care of finance's or people's current customs.

 The importance of their decisions in these questions will fade as people
 already use wallets other than the core.

 Bring this particular discussion elsewhere, to the wallet developer.

 BTW the topic was discussed here several times, you have my support and
 Jeff
 Garzik's.

 Regards,

 Tamas Blummer
 http://bitsofproof.com

 On 20.04.2014, at 15:15, Rob Golding 
 rob.gold...@astutium.comrob.gold...@astutium.comwrote:

 The average person is not going to be confident that the prefix they
 are using is the correct one,


 The use of any 'prefix' is one of choice and entirely unnecessary, and
 there
 are already established 'divisions' in u/mBTC for those that feel they need
 to use such things.

 people WILL send 1000x more or less than
 intended if we go down this road,


 Exceptionally unlikely - I deal every day with currencies with 0, 2 and 3
 dp's in amount ranging from 'under 1 whole unit' to tens of thousands - Not
 once in 20 years has anyone ever 'sent' more or less than intended - oh,
 they've 'intended' to underpay just fine, but never *unintended*.

 I propose that users are offered a preference to denominate the
 Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
 equals one million bits (bits) and one bit equals 100 satoshis.


 I propose that for people unable to understand what a bitcoin is, they can
 just use satoshi's and drop this entire proposal.

 Rob



 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/NeoTech
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 

Re: [Bitcoin-development] bits: Unit of account

2014-04-20 Thread Chris Pacia
You're correct, my impression of the term is based of what I experience in
the US. If it is more widely used in other cultures that should be a
consideration.
On Apr 20, 2014 12:27 PM, Wladimir laa...@gmail.com wrote:

 On Sun, Apr 20, 2014 at 6:19 PM, Chris Pacia ctpa...@gmail.com wrote:
  The term bit is really only overloaded for those who are techy. 95% of
 the
  population never uses the term bit in their daily lives and I doubt most
  could even name one use of the term.
  Plus bit used to be a unit of money way back when, so this is kind of
  reclaiming it. I think it's a great fit.

 That's a very anglocentric way of thinking.

 Here in the Netherlands, a bit is something you put in a horses's
 mouth. It's also used as imported word (in the information sense).
 We've never used the term for money.

 Wladimir

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development