Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-20 Thread Eric Lombrozo

 On Jun 20, 2015, at 4:37 PM, justusranv...@riseup.net wrote:
 
 Signed PGP part
 On 2015-06-20 18:20, Jorge Timón wrote:
  On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo elombr...@gmail.com
  wrote:
  If we want a non-repudiation mechanism in the protocol, we should
  explicitly define one rather than relying on “prima facie”
  assumptions. Otherwise, I would recommend not relying on the existence
  of a signed transaction as proof of intent to pay…
 
  Non-repudiation can be built on top of the payment protocol layer.
 
 
 Non-repudiation is an intrinsic property of the ECDSA signatures which
 Bitcoin uses - it's not a feature that needs to be built.
 
 There's no way to accidentally sign a transaction and accidentally
 announce it publicly. There is no form of third-party error that can
 result in a payee receiving an erroneous contract.
 
 

Justus,

We don’t even have a concept of identity in the Bitcoin protocol, let alone 
non-repudiation. What good is non-repudiation if there’s no way to even 
associate a signature with a legal entity?

Sure, we could use the ECDSA signatures in transactions as part of a 
non-repudiation scheme - but the recipient would have to also have a means to 
establish the identity of the sender and associate it with the the transaction.


Furthermore, in light of the fact that there *are* fully legitimate use cases 
for sending conflicting transactions…and the fact that determination of intent 
isn’t always entirely clear…we should refrain from attaching any further 
significance transaction signatures other than that “the sender was willing to 
have it included in the blockchain if a miner were to have seen it and accepted 
it…but perhaps the sender would have changed their mind before it actually did 
get accepted.”

- Eric Lombrozo


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-20 Thread Eric Lombrozo

 On Jun 20, 2015, at 5:27 PM, justusranv...@riseup.net wrote:
 
 Signed PGP part
 On 2015-06-20 19:19, Eric Lombrozo wrote:
  On Jun 20, 2015, at 4:37 PM, justusranv...@riseup.net wrote:
 
  Signed PGP part
  On 2015-06-20 18:20, Jorge Timón wrote:
   On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo elombr...@gmail.com
   wrote:
   If we want a non-repudiation mechanism in the protocol, we should
   explicitly define one rather than relying on “prima facie”
   assumptions. Otherwise, I would recommend not relying on the existence
   of a signed transaction as proof of intent to pay…
  
   Non-repudiation can be built on top of the payment protocol layer.
 
 
  Non-repudiation is an intrinsic property of the ECDSA signatures which
  Bitcoin uses - it's not a feature that needs to be built.
 
  There's no way to accidentally sign a transaction and accidentally
  announce it publicly. There is no form of third-party error that can
  result in a payee receiving an erroneous contract.
 
 
 
  Justus,
 
  We don’t even have a concept of identity in the Bitcoin protocol, let
  alone non-repudiation. What good is non-repudiation if there’s no way
  to even associate a signature with a legal entity?
 
  Sure, we could use the ECDSA signatures in transactions as part of a
  non-repudiation scheme - but the recipient would have to also have a
  means to establish the identity of the sender and associate it with
  the the transaction.
 
 
  Furthermore, in light of the fact that there *are* fully legitimate
  use cases for sending conflicting transactions…and the fact that
  determination of intent isn’t always entirely clear…we should refrain
  from attaching any further significance transaction signatures other
  than that “the sender was willing to have it included in the
  blockchain if a miner were to have seen it and accepted it…but perhaps
  the sender would have changed their mind before it actually did get
  accepted.”
 
 Bitcoin has no concept of identity, but in any type of commercial
 transaction the parties involved must know some minimal amount of
 identity information in order to transact at all.
 
 Except for some identifiable special cases, I think a payee is perfectly
 justified in treating a double spend of a payment sent to them as part
 of a commercial transaction as a fraud attempt and employing whatever
 non-Bitcoin recourse mechanisms, if any, they have access to.
 
 From the perspective of the network, the obviously correct action for
 any node or miner is to relay the first version of any transaction they
 see. The primary purpose of mining is to resolve this
 otherwise-unresolvable problem of determining which transaction among a
 set of conflicting transactions happened first.
 
 If a node or miner wants to deviate from the obviously correct
 behaviour, and if they want to avoid harming the value of the network,
 they should be particularly careful to make sure their deviation from
 first seen doesn't introduce harmful unintended side effects, like
 making fraud easier.
 

The contract between the buyer and seller is actually outside the Bitcoin 
network. Yes, a merchant that gets cheated could seek some other recourse in 
such an event…but the behavior you’re claiming as “obviously correct” is NOT 
obviously correct.  In fact, there are arguments against this “obviously 
correct” way even if we were to accept the premise that the signature implies a 
promise to pay (which I think many reasonable individuals would also dispute). 
For instance, by relaying conflicting transactions it makes it potentially 
easier for others to discover the double-spend attempt (of course, this 
requires wallets to not be lazy about this…perhaps such relays could be flagged 
or placed in a special message type).

- Eric Lombrozo





signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-20 Thread Eric Lombrozo

 On Jun 20, 2015, at 4:47 PM, Eric Lombrozo elombr...@gmail.com wrote:
 
 
 On Jun 20, 2015, at 4:16 PM, Jorge Timón jti...@jtimon.cc wrote:
 
 On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo elombr...@gmail.com wrote:
 The Bitcoin network was designed (or should be designed) with the 
 requirement that it can withstand deliberate double-spend attacks that can 
 come from anywhere at any time…
 
 I disagree with this premise. Please, don't take this as an argument
 from authority fallacy, but I will cite Satoshi to express what I
 think the assumptions while using the system should be:
 
 As long as a majority of CPU power is controlled by nodes that are
 not cooperating to attack the network, they'll generate the longest
 chain and outpace attackers.
 
 I can't say for sure what was meant by attacking the network in this
 context but I personally mean trying to rewrite valid and
 proof-of-work-timestamped history.
 Unconfirmed transactions are simply not part of history yet. Ordering
 unconfirmed transactions in a consensus compatible way without a
 universal clock is impossible, that's why we're using proof of work in
 the first place.
 
 Alternative policies are NOT attacks on the network.
 
 Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions 
 are part of any sort of global consensus. In fact, they very much AREN’T. 
 Which is exactly why it is extremely dangerous to accept unconfirmed 
 transactions as final unless you clearly have assessed the risks and it makes 
 sense for the particular business use case.
 
 - Eric Lombrozo

I think the misunderstanding was in perhaps my earlier statement seemed like I 
was suggesting that it’s the protocol’s responsibility to protect merchants 
from double-spends. On the contrary - I think we agree - the protocol CANNOT 
make any guarantees to ANYONE until we do converge on a history. The “design” I 
speak of here is more on the merchant side.

- Eric Lombrozo


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Eric Lombrozo
It all comes down to managing risk. If you’ve got a decent risk model with 
capped losses and safe recovery mechanisms…and it’s still profitable…it’s fine. 
But most payment processors and merchants right now probably don’t have 
particularly good risk models and are making many dangerous assumptions…and 
probably would not be able to gracefully handle very many risk scenarios.

- Eric Lombrozo


 On Jun 19, 2015, at 6:23 PM, Aaron Voisine vois...@gmail.com wrote:
 
  What retail needs is escrowed microchannel hubs (what lightning provides, 
  for example), which enable untrusted instant payments. Not reliance on 
  single-signer zeroconf transactions that can never be made safe.
 
 They don't need to be made cryptographically safe, they just have to be safer 
 than, for instance, credit card payments that can be charged back. As long as 
 it's reasonably good in practice, that's fine.
 
 
 Aaron Voisine
 co-founder and CEO
 breadwallet.com http://breadwallet.com/
 On Fri, Jun 19, 2015 at 6:09 PM, Mark Friedenbach m...@friedenbach.org 
 mailto:m...@friedenbach.org wrote:
 What retail needs is escrowed microchannel hubs (what lightning provides, for 
 example), which enable untrusted instant payments. Not reliance on 
 single-signer zeroconf transactions that can never be made safe.
 
 On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson andr...@petersson.at 
 mailto:andr...@petersson.at wrote:
 I have some experience here. If you are seriously suggesting these
 measures, you might as well kill retail transactions altogether.
 
 In practice, if a retail place starts to accept bitcoin they have a
 similar situation as with cash, only that the fraud potential is much
 lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
 and the fraud frequency is also much lower.
 
 0-conf concerns were never a problem in practice. except for 2-way atms
 i have never heard of a problem that was caused by double spends.
 while adding these measures is generally positive, requiring them means
 excluding 99.9% of the potential users. so you might as well not do it.
 
 RBF as implemented by F2Pool just flat out lowers Bitcoins utility
 value. So it's a bad thing.
 
 for any online or automated system, waiting for a handful of
 confirmations was always recommended practice.
 
 Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
  Retail POS merchants probably should not be accepting vanilla Bitcoin
  payments, as Bitcoin alone does not (and cannot) guarantee the
  irreversibility of a transaction until it has been buried several
  blocks deep in the chain. Retail merchants should be requiring a
  co-signature from a mutually trusted co-signer that vows never to sign
  a double-spend.
 
 
 --
 
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net 
 mailto:Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 
 
 --
 
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net 
 mailto:Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development 
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-19 Thread Eric Lombrozo
I don’t think the issue is between larger blocks on the one hand and things 
like lightning on the other - these two ideas are quite orthogonal.

Larger blocks aren’t really about addressing basic scalability concerns - for 
that we’ll clearly need architectural and algorithmic improvements…and will 
likely need to move to a model where it isn’t necessary for everyone to 
validate everyone else’s latte purchases. Larger blocks might, at best, keep 
the current system chugging along temporarily - although I’m not sure that’s 
necessarily such a great thing…we need to create a fee market sooner or later, 
and until we do this, block size issues will continue to crop up again and 
again and economic incentives will continue to be misplaced. It would be nice 
to have more time to really develop a good infrastructure for this…but without 
real market pressures, I’m not sure it will happen at all. Necessity is the 
mother of invention, after all. The question is how to introduce a fee market 
smoothly and with the overwhelming consensus of the community - and that's 
where it starts to get tricky.

——

On a separate note, as several others have pointed out in this thread (but I 
wanted to add my voice to this as well), maintenance of source code 
repositories is NOT the real issue here. The bitcoin/bitcoin project on github 
is a reference implementation of the Satoshi protocol…but it is NOT the only 
implementation…and it wasn’t really meant to be. Anyone is free to fork it, 
extend it, improve upon it, or create an entirely new network with its own 
genesis block…a separate cryptoledger.

The real issue regarding XT is NOT the forking of source code nor issues 
surrounding commit access to repositories. The real issue is the *forking of a 
cryptoledger*.

Open source repositories are meant to be forked - in fact, it is often 
encouraged. It is also encouraged that improvements be submitted for review and 
possibly merged back into the parent repository…although this doesn’t always 
happen.

However, we currently have no mechanisms in place to support merging of forked 
cryptoledgers. Software, and most other forms of digital content, generally 
increases in value with more copies made. However, money is scarce…by design. 
The entire value of the assets of a decentralized cryptoledger rests on the 
assumption that nobody can just unilaterally fork it and change the rules. Yes, 
convincing other people to do things a certain way is HARD…yes, it can be 
frustratingly slow…I’ve tried to push for many changes to the Bitcoin 
network…and have only succeeded a very small number of times. And yes, it’s 
often been quite frustrating. But trying to unilaterally impose a change of 
consensus rules for an existing cryptoledger sets a horrendous precedent…this 
isn’t just about things like block size limits, which is a relatively petty 
issue by comparison.

It would be very nice to have a similar workflow with consensus rule evolution 
as we do with most other open source projects. You create a fork, demonstrate 
that your ideas are sound by implementing them and giving others something that 
works so they can review them, and then merge your contributions back in. 
However, the way Bitcoin is currently designed, this is unfortunately 
impossible to do this with consensus rules. Once a fork, always a fork - a.k.a. 
altcoins. Say what you will about how most altcoins are crap - at least most of 
them have the decency of starting with a clean ledger.


- Eric Lombrozo


 On Jun 18, 2015, at 5:57 PM, Chris Pacia ctpa...@gmail.com wrote:
 
 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

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

2015-06-19 Thread Eric Lombrozo
IPv4 came before IPv6…you pick up on things quickly :)

 On Jun 19, 2015, at 5:48 AM, Marcel Jamin mar...@jamin.net wrote:
 
  At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! 
  came before Google…MySpace came before Facebook…
 
 And TCP/IP came before... oh wait...
 
 2015-06-19 14:02 GMT+02:00 Eric Lombrozo elombr...@gmail.com 
 mailto:elombr...@gmail.com:
 
 On Jun 19, 2015, at 3:45 AM, Dr Adam Back a...@cypherspace.org 
 mailto:a...@cypherspace.org wrote:
 
 That wont be good for the companies either, but they may not see that
 until they've killed it, many companies operate on a1 or 2 year
 time-horizon.  They may say screw layer2, I have a runway and I need
 micropayments to the wazoo and I dont have the dev resources for that.
 
 Exactly, Adam.
 
 Except, I think the genie is out of the bottle - these ideas are too powerful 
 for them to be killed forever. They will probably survive even if this 
 scenario comes to pass…but in a different network under a different name…and 
 Bitcoin will be relegated to the history books and walls of museums.
 
 Most of the potential brainpower available on this Earth to make serious, 
 profound contributions to this movement haven’t even begun to touch it. Just 
 because you happen to run a Bitcoin startup right now…even if you’ve received 
 millions of dollars in funding…don’t think that the whole world has low 
 standards and is lazy! Someone WILL eventually build something better than we 
 can presently imagine.
 
 First mover advantage and the network effect are vastly overrated. At the 
 risk of stating cliches, the Mac came before the Windows PC…Yahoo! came 
 before Google…MySpace came before Facebook…Bitcoin came before we don’t know 
 yet.
 
 
 - Eric Lombrozo
 
 --
 
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net 
 mailto:Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-19 Thread Eric Lombrozo

 On Jun 19, 2015, at 2:37 AM, Mike Hearn m...@plan99.net wrote:
 
 Or alternatively, fix the reasons why users would have negative experiences 
 with full blocks
 
 It's impossible, Mark. By definition if Bitcoin does not have sufficient 
 capacity for everyone's transactions, some users who were using it will be 
 kicked out to make way for the others. Whether that happens in some kind of 
 stable organised way or (as with the current code) a fairly chaotic way 
 doesn't change the fundamental truth: some users will find their bitcoin 
 savings have become uneconomic to spend.
 
 Here's a recent user complaint that provides a preview of coming attractions:
 
 https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/
  
 https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/
 
 Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits) 
 onto a paper wallet. When I try to send it, a window pops up stating 
 insufficient funds for bitcoin network fee, reduce payment amount by 1,389 
 bits? This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.
 
 These sorts of complaints will get more frequent and more extreme in the 
 coming months. I realise that nobody at Blockstream is  in the position of 
 running an end user facing service, but many of us are  and we will be 
 the ones that face the full anger of ordinary users as Bitcoin hits the wall.

Mike,

With all due respect, many of us DO run end user facing services…and would 
rather see a fundamental problem *fixed* rather than merely covered up 
temporarily…hoping nobody notices.

The user experience of Bitcoin is already horrendous…unless you use a 
centralized validator web wallet. Even SPV is fundamentally broken (and I would 
have pegged you for being one of the people most directly aware of this fact). 
If we’re going for centralized validation, why even use a blockchain in the 
first place? We already have much faster, more efficient technology that can do 
that kind of stuff at a fraction of the cost. If you have well-established 
entities running banking services, we have other mechanisms in place that can 
help keep them honest…other far more efficient protocols. We’re basically 
defeating the very purpose of this invention.

Then there are a bunch of other “inconveniences” about the way Bitcoin 
currently works. For instance, have you ever received a bunch of small payments 
(i.e. a crowdsale) and then found yourself in the position of having to 
suddenly move a big chunk of that on the blockchain…only to discover all the 
txouts you were spending added up to hundreds of kB or more? Or have you ever 
had to send a small payment but only had one large output in your wallet…which 
meant that the entirety of those funds were tied up until the first transaction 
got signed and propagated? Yes, the protocol has MANY serious issues…of which 
the “send and forget” fee model as opposed to the “send and bid model” is just 
one.

Bitcoin was designed from the beginning with the idea that sooner or later fees 
would be a significant component of the network. The problem was never really 
fully addressed and solved - I’m glad to see that finally some good people in 
this space are starting to seriously think about solutions.

Mike, are you telling us you’d rather avoid user complaints at all costs even 
if that means building something shitty for them that doesn’t really serve its 
stated purpose? If those are your standards then no thanks, I don’t want to be 
part of your fork. And I don’t think I’m alone in this sentiment.


- Eric Lombrozo


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




signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-19 Thread Eric Lombrozo

 On Jun 19, 2015, at 3:45 AM, Dr Adam Back a...@cypherspace.org 
 mailto:a...@cypherspace.org wrote:
 
 That wont be good for the companies either, but they may not see that
 until they've killed it, many companies operate on a1 or 2 year
 time-horizon.  They may say screw layer2, I have a runway and I need
 micropayments to the wazoo and I dont have the dev resources for that.

Exactly, Adam.

Except, I think the genie is out of the bottle - these ideas are too powerful 
for them to be killed forever. They will probably survive even if this scenario 
comes to pass…but in a different network under a different name…and Bitcoin 
will be relegated to the history books and walls of museums.

Most of the potential brainpower available on this Earth to make serious, 
profound contributions to this movement haven’t even begun to touch it. Just 
because you happen to run a Bitcoin startup right now…even if you’ve received 
millions of dollars in funding…don’t think that the whole world has low 
standards and is lazy! Someone WILL eventually build something better than we 
can presently imagine.

First mover advantage and the network effect are vastly overrated. At the risk 
of stating cliches, the Mac came before the Windows PC…Yahoo! came before 
Google…MySpace came before Facebook…Bitcoin came before we don’t know yet.


- Eric Lombrozo


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Eric Lombrozo
OK, a few things here:

The Bitcoin network was designed (or should be designed) with the requirement 
that it can withstand deliberate double-spend attacks that can come from 
anywhere at any time…and relaxing this assumption without adequately assessing 
the risk (i.e. I’ve never been hacked before so I can assume it’s safe) is 
extremely dangerous at best and just horrid security practice at worst. Your 
users might not thank you for not getting hacked - but they surely will not 
like it when you DO get hacked…and lack a proper recovery plan.

Furthermore, the protocol itself makes no assumptions regarding the intentions 
behind someone signing two conflicting transactions. There are many potential 
use cases where doing so could make a lot of sense. Had the protocol been 
designed along the lines of, say, tendermint…where signing multiple conflicting 
blocks results in loss of one’s funds…then the protocol itself disincentivizes 
the behavior without requiring any sort of altruistic, moralistic assumptions. 
That would also mean we’d need a different mechanism for the use cases that 
things like RBF address.

Thirdly, taken to the extreme, the viewpoint of “signing a conflicting 
transaction is fraud and vandalism” means that if for whatever reason you 
attempt to propagate a transaction and nobody mines it for a very long time, 
you’re not entitled to immediately reclaim those funds…they must remain in 
limbo forever.


- Eric Lombrozo


 On Jun 19, 2015, at 8:11 AM, Peter Todd p...@petertodd.org wrote:
 
 On Fri, Jun 19, 2015 at 03:00:57PM +, justusranv...@riseup.net wrote:
 On 2015-06-19 10:39, Peter Todd wrote:
 
 Yesterday F2Pool, currently the largest pool with 21% of the hashing
 power, enabled full replace-by-fee (RBF) support after discussions
 with
 me. This means that transactions that F2Pool has will be replaced if
 a
 conflicting transaction pays a higher fee. There are no requirements
 for
 the replacement transaction to pay addresses that were paid by the
 previous transaction.
 
 
 Intentional fraud is a bad thing to add to a financial protocol.
 
 A user who creates conflicting transactions, one that pays someone else
 and another which does not pay them, and broadcasts both of them, has
 just self-incriminated themselves by producing prima facie evidence of
 fraud.
 
 Depends.
 
 If you ask me to pay you 1BTC at address A and I create tx1 that pays
 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
 that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
 defrauding you, I'm just reducing the value of my change address to pay
 a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
 tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.
 
 Yet from the point of view of an external observer they have no idea why
 the transaction outputs reduced in size, nor any way of knowing if fraud
 did or did not occur.
 
 Equally, maybe you tell me Actually, just give me 0.5BTC to cancel out
 that debt, in which case I'm not breaking any contract at all by giving
 you less money than I first promised - the contract has changed.
 
 Again, none of this can or should be observable to anyone other than the
 parties directly involved.
 
 It may be the case that since Bitcoin spans multiple legal jurisdictions
 and can be use anonymously that the victims of such fraud can not rely
 on legal recourse, and it may also be the case that proof of work is how
 Bitcoin deals with the aforementioned factors, but regardless
 un-prosecutable fraud is still fraud and anyone who encourages it should
 be recognied as a bad actors.
 
 Committing vandalism and encouraging fraud to prove a point may be
 something the network can't stop on a technical level, but there's no
 reason not to call it out for what it is.
 
 What do you think of Bitcoin XT then? It relays double-spends, which
 makes it much easier to get double-spends to miners than before. In
 particular you see a lot of zero-fee transactions being replaced by
 fee-paying transactions, relayed through Bitcoin XT nodes and then
 mined. Is that encouraging fraud?
 
 --
 'peter'[:-1]@petertodd.org
 03932458055c68d4ee2b6d68441c4764efbdf6b0b1683717
 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Eric Lombrozo
If we want a non-repudiation mechanism in the protocol, we should explicitly 
define one rather than relying on “prima facie” assumptions. Otherwise, I would 
recommend not relying on the existence of a signed transaction as proof of 
intent to pay…


 On Jun 19, 2015, at 9:36 AM, Matt Whitlock b...@mattwhitlock.name wrote:
 
 On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote:
 I'd also like to note that prima facie doesn't mean always, it means
 that the default assumption, unless proven otherwise.
 
 Why would you automatically assume fraud by default? Shouldn't the null 
 hypothesis be the default? Without any information one way or another, you 
 ought to make *no assumption* about the fraudulence or non-fraudulence of any 
 given double-spend.



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] comments on BIP 100

2015-06-15 Thread Eric Lombrozo
OK. O() notation normally refers to computational complexity, but ... I
still don't get it - the vast majority of users don't run relaying nodes
that take part in gossiping. They run web or SPV wallets. And the nodes
that do take part don't connect to every other node.

It's a little scary, IMO, that the fact that the majority of nodes don't
relay and only perform the most rudimtentary level of validation if any is
considered an acceptable feature of the protocol.

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


Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork

2015-06-15 Thread Eric Lombrozo

 On Jun 15, 2015, at 3:54 PM, odinn odinn.cyberguerri...@riseup.net wrote:
 
 I also disagree with the notion that everybody's just ok with what
 Mike and Gavin are doing specifically, this statement by Mike
 
  The consensus you seek does exist. All wallet developers (except
  Lawrence), all the major exchanges, all the major payment
  processors and many of the major mining pools want to see the limit
  lifted


This is certainly twisting words!

We all agree that the limit needs to eventually be lifted - but some of us 
certainly disagree with the means being used to do so by Mike and Gavin.

Most news publications keep the discussion rather shallow and like to keep the 
controversy pretty black and white - some of us have far more nuanced views!

- Eric Lombrozo


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Eric Lombrozo
I definitely think we need some voting system for metaconsensus…but if we’re 
going to seriously consider this we should look at the problem much more 
generally. Using false choices doesn’t really help, though ;)

- Eric Lombrozo


 On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote:
 
 On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com 
 mailto:elombr...@gmail.com wrote:
 2) BIP100 has direct economic consequences…and particularly for miners. It 
 lends itself to much greater corruptibility.
 
 
 What is the alternative?  Have a Chief Scientist or Technical Advisory Board 
 choose what is a proper fee, what is a proper level of decentralization, a 
 proper growth factor?



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Eric Lombrozo
Chun,

With all due respect, there are a couple major differences between BIP34 and 
BIP66 on the one hand and BIP100 on the other.

1) BIP34 and BIP66 are soft forks. Miners choosing to switch to them will not 
seriously impact validation rules for non-mining users that do not make the 
switch. With BIP66, the worst that can happen to them is noncompliant 
transactions will no longer be accepted by the network…but even nodes that do 
not switch over will continue to remain synched with the network.

2) BIP100 has direct economic consequences…and particularly for miners. It 
lends itself to much greater corruptibility.

- Eric Lombrozo

 On Jun 13, 2015, at 9:55 PM, Chun Wang 1240...@gmail.com wrote:
 
 To tell you the truth. It is only because most miners are not located
 in the West. If Slush, Eligius and BTC Guild still on top 3, the core
 developers, including brain-dead Mike Hearn, would be very happy to do
 BIP100 just like they did BIP34 and BIP66. Shame on you!
 
 On Sun, Jun 14, 2015 at 6:20 AM, Danny Thorpe danny.tho...@gmail.com wrote:
 Please forgive my ignorance, but why should Bitcoin users have a say in
 block size limits?  It's the miners and Bitcoin node operators that bear the
 burden of managing large blocks, no?
 
 Users voting on network parameters sounds like neighbors voting on how deep
 my swimming pool should be.
 
 Thanks,
 -Danny
 
 On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd p...@petertodd.org wrote:
 
 Jeff Garzik recently proposed that the upper blocksize limit be removed
 entirely, with a soft limit being enforced via miner vote, recorded by
 hashing power.
 
 This mechanism within the protocol for users to have any influence over
 the miner vote. We can add that back by providing a way for transactions
 themselves to set a flag determining whether or not they can be included
 in a block casting a specific vote.
 
 We can simplify Garzik's vote to say that one of the nVersion bits
 either votes for the blocksize to be increased, or decreased, by some
 fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
 nVersion bit in transactions themselves, also voting for an increase or
 decrease. Transactions may only be included in blocks with an
 indentical vote, thus providing miners with a monetary incentive via
 fees to vote according to user wishes.
 
 Of course, to cast a don't care vote we can either define an
 additional bit, or sign the transaction with both versions. Equally we
 can even have different versions with different fees, broadcast via a
 mechanism such as replace-by-fee.
 
 
 See also John Dillon's proposal for proof-of-stake blocksize voting:
 
 
 https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
 
 --
 'peter'[:-1]@petertodd.org
 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
 
 
 --
 
 ___
 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
 
 
 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Eric Lombrozo
That’s exactly the problem with Bitcoin - it was supposed to be the case that 
users ARE the miners and node operators…but…alas…

 On Jun 13, 2015, at 3:20 PM, Danny Thorpe danny.tho...@gmail.com wrote:
 
 Please forgive my ignorance, but why should Bitcoin users have a say in block 
 size limits?  It's the miners and Bitcoin node operators that bear the burden 
 of managing large blocks, no?
 
 Users voting on network parameters sounds like neighbors voting on how deep 
 my swimming pool should be.
 
 Thanks,
 -Danny
 
 On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd p...@petertodd.org 
 mailto:p...@petertodd.org wrote:
 Jeff Garzik recently proposed that the upper blocksize limit be removed
 entirely, with a soft limit being enforced via miner vote, recorded by
 hashing power.
 
 This mechanism within the protocol for users to have any influence over
 the miner vote. We can add that back by providing a way for transactions
 themselves to set a flag determining whether or not they can be included
 in a block casting a specific vote.
 
 We can simplify Garzik's vote to say that one of the nVersion bits
 either votes for the blocksize to be increased, or decreased, by some
 fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
 nVersion bit in transactions themselves, also voting for an increase or
 decrease. Transactions may only be included in blocks with an
 indentical vote, thus providing miners with a monetary incentive via
 fees to vote according to user wishes.
 
 Of course, to cast a don't care vote we can either define an
 additional bit, or sign the transaction with both versions. Equally we
 can even have different versions with different fees, broadcast via a
 mechanism such as replace-by-fee.
 
 
 See also John Dillon's proposal for proof-of-stake blocksize voting:
 
 https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
  
 https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
 
 --
 'peter'[:-1]@petertodd.org http://petertodd.org/
 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
 
 --
 
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net 
 mailto:Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development 
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses

2015-05-23 Thread Eric Lombrozo
A few months back, William Swanson and I had worked on a more general script 
template format. Unfortunately, other work has prevented us from being able to 
fully complete it - but here’s the start:

https://docs.google.com/document/d/1nGF6LjGwhzuiJ9AQwKAhN1a1SXvGGHWxoKmDSkiIsPI 
https://docs.google.com/document/d/1nGF6LjGwhzuiJ9AQwKAhN1a1SXvGGHWxoKmDSkiIsPI/

- Eric Lombrozo

 On Feb 12, 2015, at 11:53 PM, Peter Todd p...@petertodd.org wrote:
 
 On Thu, Feb 12, 2015 at 10:13:33PM +, Luke Dashjr wrote:
 Where is the Specification section?? Does this support arbitrary scripts, or
 only the simplest CHECKMULTISIG case?
 
 It might be enough to rewrite this BIP to basically say all pubkeys
 executed by all CHECKMULTISIG opcodes will be in the following canonical
 order, followed by some explanatory examples of how to apply this
 simple rule.
 
 OTOH we don't yet have a standard way of even talking about arbitrary
 scripts, so it may very well turn out to be the case that the above rule
 is too restrictive in many cases - I certainly would not want to do a
 soft-fork to enforce this, or even make it an IsStandard() rule.
 
 --
 'peter'[:-1]@petertodd.org
 13cf8270118ba2efce8b304f8de359599fef95c3ab43dcb1
 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. 
 http://goparallel.sourceforge.net/___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Eric Lombrozo

 On May 7, 2015, at 4:20 AM, Wladimir J. van der Laan laa...@gmail.com wrote:
 
 For sake of brevity, this ignores the inherent practical and political issues 
 in scheduling a hardfork.

IMHO, these issues are the elephant in the room and the talk of block size 
increases is just a distraction.

- Eric Lombrozo


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread Eric Lombrozo
I don’t really have a strong opinion on block size either…but if we’re going to 
do a hard fork, let’s use this as an opportunity to create a good process for 
hard forks (which we’ll inevitably need to do again in the future). The change 
in block size is a very simple change that still allows us to explore all the 
complexities involved with deployment of hard forks. Let’s not just do a 
one-off ad-hoc thing.

- Eric Lombrozo

 On May 6, 2015, at 3:30 PM, slush sl...@centrum.cz wrote:
 
 I don't have strong opinion @ block size topic.
 
 But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE 
 (https://bitcointalk.org/index.php?topic=181734.0 
 https://bitcointalk.org/index.php?topic=181734.0) or its alternative. All 
 developers of lightweight (blockchain-less) clients will adore you!
 
 slush
 
 On Thu, May 7, 2015 at 12:12 AM, Matt Corallo bitcoin-l...@bluematt.me 
 mailto:bitcoin-l...@bluematt.me wrote:
 Recently there has been a flurry of posts by Gavin at
 http://gavinandresen.svbtle.com/ http://gavinandresen.svbtle.com/ which 
 advocate strongly for increasing
 the maximum block size. However, there hasnt been any discussion on this
 mailing list in several years as far as I can tell.
 
 Block size is a question to which there is no answer, but which
 certainly has a LOT of technical tradeoffs to consider. I know a lot of
 people here have varying levels of strong or very strong opinions about
 this, and the fact that it is not being discussed in a technical
 community publicly anywhere is rather disappointing.
 
 So, at the risk of starting a flamewar, I'll provide a little bait to
 get some responses and hope the discussion opens up into an honest
 comparison of the tradeoffs here. Certainly a consensus in this kind of
 technical community should be a basic requirement for any serious
 commitment to blocksize increase.
 
 Personally, I'm rather strongly against any commitment to a block size
 increase in the near future. Long-term incentive compatibility requires
 that there be some fee pressure, and that blocks be relatively
 consistently full or very nearly full. What we see today are
 transactions enjoying next-block confirmations with nearly zero pressure
 to include any fee at all (though many do because it makes wallet code
 simpler).
 
 This allows the well-funded Bitcoin ecosystem to continue building
 systems which rely on transactions moving quickly into blocks while
 pretending these systems scale. Thus, instead of working on technologies
 which bring Bitcoin's trustlessness to systems which scale beyond a
 blockchain's necessarily slow and (compared to updating numbers in a
 database) expensive settlement, the ecosystem as a whole continues to
 focus on building centralized platforms and advocate for changes to
 Bitcoin which allow them to maintain the status quo[1].
 
 Matt
 
 [1] https://twitter.com/coinbase/status/595741967759335426 
 https://twitter.com/coinbase/status/595741967759335426
 
 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y 
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net 
 mailto:Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-22 Thread Eric Lombrozo
I should note that my proposal does require a change to the consensus
rules...but getting bitcoin to scale will require this no matter what.

- Eric Lombrozo
On Feb 22, 2015 3:41 AM, Eric Lombrozo elombr...@gmail.com wrote:

 It seems to me we're confusing two completely different motivations for
 double-spending. One is the ability to replace a fee, the other is the
 ability to replace outputs.

 If the double-spend were to merely add or remove inputs (but keep at least
 one input in common, of course), it seems fairly safe to assume it's the
 former, a genuine fee replacement. Even allowing for things like coinjoin,
 none of the payees would really care either way.

 Conversely, if at least one of the inputs were kept but none of the
 outputs were, we can be confident it's the the latter.

 It is possible to build a wallet that always does the former when doing
 fee replacement by using another transaction to create an output with
 exactly the additional desired fee.

 If we can clearly distinguish these two cases then the fee replacement
 case can be handled by relaying both and letting miners pick one or the
 other while the output replacement case could be handled by rewarding
 everything to a miner (essentially all outputs are voided...made
 unredeemable...and all inputs are added to coinbase) if the miner includes
 the two conflicting transactions in the same block.

 Wouldn't this essentially solve the problem?

 - Eric Lombrozo
 On Feb 21, 2015 8:09 PM, Jeff Garzik jgar...@bitpay.com wrote:

 On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote:
  On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com
 wrote:
  This isn't some theoretical exercise.  Like it or not many use
  insecure 0-conf transactions for rapid payments.  Deploying something
  that makes 0-conf transactions unusable would have a wide, negative
  impact on present day bitcoin payments, thus scorched earth

  And maybe by maintaining first seen policies we're harming the system
  in the long term by encouraging people to widely deploy systems based
  on extremely weak assumptions.

 Lacking a coded, reviewed alternative, that's only a platitude.
 Widely used 0-conf payments are where we're at today.  Simply ceasing
 the maintaining [of] first seen policies alone is simply not a
 realistic option.  The negative impact to today's userbase would be
 huge.

 Instant payments need a security upgrade, yes.

 --
 Jeff Garzik
 Bitcoin core developer and open source evangelist
 BitPay, Inc.  https://bitpay.com/


 --
 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] replace-by-fee v0.10.0rc4

2015-02-22 Thread Eric Lombrozo
It seems to me we're confusing two completely different motivations for
double-spending. One is the ability to replace a fee, the other is the
ability to replace outputs.

If the double-spend were to merely add or remove inputs (but keep at least
one input in common, of course), it seems fairly safe to assume it's the
former, a genuine fee replacement. Even allowing for things like coinjoin,
none of the payees would really care either way.

Conversely, if at least one of the inputs were kept but none of the outputs
were, we can be confident it's the the latter.

It is possible to build a wallet that always does the former when doing fee
replacement by using another transaction to create an output with exactly
the additional desired fee.

If we can clearly distinguish these two cases then the fee replacement case
can be handled by relaying both and letting miners pick one or the other
while the output replacement case could be handled by rewarding everything
to a miner (essentially all outputs are voided...made unredeemable...and
all inputs are added to coinbase) if the miner includes the two conflicting
transactions in the same block.

Wouldn't this essentially solve the problem?

- Eric Lombrozo
On Feb 21, 2015 8:09 PM, Jeff Garzik jgar...@bitpay.com wrote:

 On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote:
  On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com
 wrote:
  This isn't some theoretical exercise.  Like it or not many use
  insecure 0-conf transactions for rapid payments.  Deploying something
  that makes 0-conf transactions unusable would have a wide, negative
  impact on present day bitcoin payments, thus scorched earth

  And maybe by maintaining first seen policies we're harming the system
  in the long term by encouraging people to widely deploy systems based
  on extremely weak assumptions.

 Lacking a coded, reviewed alternative, that's only a platitude.
 Widely used 0-conf payments are where we're at today.  Simply ceasing
 the maintaining [of] first seen policies alone is simply not a
 realistic option.  The negative impact to today's userbase would be
 huge.

 Instant payments need a security upgrade, yes.

 --
 Jeff Garzik
 Bitcoin core developer and open source evangelist
 BitPay, Inc.  https://bitpay.com/


 --
 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] replace-by-fee v0.10.0rc4

2015-02-22 Thread Eric Lombrozo
On Sunday, February 22, 2015, Peter Todd p...@petertodd.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256



 On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo elombr...@gmail.com
 javascript:; wrote:
 In case it wasn't clear in my earlier post, there's of course a third
 possibility - namely, some outputs are kept but not all. Here, it is
 generally impossible to tell whether the motivation was fee
 replacement,
 output replacement, or both. My proposal is to always treat these
 instances
 as output replacement and punish the sender. The sender needs to make
 it
 unambiguously clear it's only a fee replacement by creating a new
 transaction that produces an output with the desired extra fee and then
 adding an input that spends it to the original transaction.

 That's a really old idea - I proposed it about two years ago. The optimal
 way is to allow any txout to be replaced with one with an equal or greater
 nValue and same scriptPubKey, as well as additional txouts added.
 (obviously so long as none are removed)


That won't work because in general it is impossible to know which
transaction is the original. Did we add outputs to transaction A? Or remove
outputs from transaction B?


 Alas, there's lots of situations where this restricts you from doing
 useful things, for instance collapsing multiple payments into one by
 repeated updating to reduce tx size. Equally the benefit is marginal at
 best given how insecure unconfirmed transactions are - breaking what is
 already broken isn't a negative.


I think you're unnecessarily complicating use cases.

As for 0-conf security, there are instances where 0-conf transactions make
a lot of sense - i.e. paying for utilities, ISP, web hosting, or other such
services which could be immediately shut off upon detection of a
double-spend.


 -BEGIN PGP SIGNATURE-

 iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6d9O
 AAoJEMCF8hzn9LncUOUH/3yY4wDyFSkL9o6GsntphAmJSN35wVAlxPxBmNTk0KR3
 YfVhY1cTBIXKqsfqz/n1Sqn264aMzW48xUTtDF2xLzJc1FY5qTBw7zbVrZgYIvvr
 GEakZW1SxLXsfSs2Onutl0WQWi8EMfxEXEPQIiiWy9mq4EtwxMOcDviETycu6Wmn
 pmHY00Lo8jhLUyuIkzIZrZetEtWz1VtovbJO5l7WfmLgPWzW+zERPY/pGGioqdiJ
 NOEaocQ+2+OZjyx3MJ4YAch5ZtfB45g+NBm8WyeGpBgxzK3ZIpmyZIQ6HqZr0gpl
 NMUQh6Sbi8WaTEp6hoYTiEfZcEy4IDPg6f0DEW71BPs=
 =1vbN
 -END PGP SIGNATURE-


--
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] convention/standard for sorting public keys for p2sh multisig transactions

2015-01-14 Thread Eric Lombrozo
I would highly recommend NOT using Base58 for anything except stuff that is
to be copy/pasted by the enduser.

Internally, pubkeys are DER-encoded integers.

- Eric
On Jan 14, 2015 2:54 PM, Jeffrey Paul j...@eeqj.com wrote:


  On 20150114, at 09:39, devrandom c1.sf-bitc...@niftybox.net wrote:
 
  At CryptoCorp we recommend to our customers that they sort
  lexicographically by the public key bytes of the leaf public keys.  i.e.
  the same as BitPay.

 To clarify: the raw bytes of the public key itself, not the ascii base58
 representation of the pubkey hash - right?

 -jp

 --
 Jeffrey Paul  EEQJ
 j...@eeqj.com   https://eeqj.com
 +1-800-403-1126 (America)  +1-312-361-0355 (Worldwide)
 5539 AD00 DE4C 42F3 AFE1  1575 0524 43F4 DF2A 55C2



 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions

2015-01-14 Thread Eric Lombrozo
I think everyone is pretty much following this standard now.

- Eric
On Jan 14, 2015 12:58 PM, devrandom c1.sf-bitc...@niftybox.net wrote:

 At CryptoCorp we recommend to our customers that they sort
 lexicographically by the public key bytes of the leaf public keys.  i.e.
 the same as BitPay.

 On Wed, 2015-01-14 at 17:37 +0100, Ruben de Vries wrote:
  For p2sh multisig TXs the order of the public keys affect the hash and
  there doesn't seem to be an agreed upon way of sorting the public
  keys.
 
 
  If there would be a standard (recommended) way of sorting the public
  keys that would make it easier for services that implement some form
  of multisig to be compatible with each other without much hassle and
  making it possible to import keys from one service to another.
 
 
  I'm not suggesting forcing the order, just setting a standard to
  recommend, there doesn't seem to be much reason for (new) services to
  not follow that recommendation.
 
 
  Ryan from BitPay broad this up before
  (https://sourceforge.net/p/bitcoin/mailman/message/32092958/) and in
  bitcore they've implemented lexicographical sorting on the hex of the
  public key.
  In a short search I can't find any other library that has a sorting
  function, let alone using it by default, so bitcore is currently my
  only reference.
 
 
 
 
  ​Ruben de Vries
  ​CTO, BlockTrail
 
 --
  New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
  GigeNET is offering a free month of service with a new server in Ashburn.
  Choose from 2 high performing configs, both with 100TB of bandwidth.
  Higher redundancy.Lower latency.Increased capacity.Completely compliant.
  http://p.sf.net/sfu/gigenet
  ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

 --
 Miron / devrandom





 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP32 - invalidation

2014-08-09 Thread Eric Lombrozo
Does bitcoin properly handle the case of a hash collision? no - because it is 
considered too unlikely. The case of I_L = n is also astronomically unlikely, 
so it's more a matter of improved performance and simpler data structures under 
expected circumstances and taking that less than 1 in 2^127 chance that it will 
fail, in which case we can recover by moving everything over to a new tree.

-Eric Lombrozo



On Aug 9, 2014, at 5:34 PM, second isogeny secondisog...@gmail.com wrote:

  Does anyone see any concerns when it comes to security of the proposed
  change?
 
 Yes.  This proposal is less secure.
 
 It is incompatible in theory with existing implementations of the
 specification.  The incompatibility is also a potentially a security
 problem because it may cause users to believe a key is worthless when
 it is not or to lose funds when they are unable to spend them.
 
 It is also an untimely proposal and would be inconsiderate other parties
 who have done the work to produce correct and compatible implementations.
 
  In case I_L = n assign I_L := I_L mod n.
 
 This will make the selection of private keys uneven.
 
 The unevenness is small and it is unlikely to very matter much but it
 is objectively less secure.  Future advances in cryptography may make
 the distinction more important.  The change would eliminate any hope of
 the specification ever having provable security equal to random keys.
 
 The bignum modulo operation also requires complex additional logic and is
 just as likely to remain untested in implementations, though unit-testing
 can test these cases by replacing the hash function.
 
 Because of layering no suitable modulo may be available and an incorrect
 implementation could create a devastating weakness, like reflecting a
 large class of keys to a small number of values.  A similar error would
 be unlikely for an incorrect implementation of skipping and someone who
 managed to still fail would likely have failed either way.
 
  most of the implementations don't do the checking at all, because tjen
  it's rather hard at application level to implement skipping logic. OTOH
 
 There are many corner cases which must be handled in cryptographic
 software.
 
 You must handle the point at infinity cases, you must handle the signature
 having a value of zero (or you leak the private key), in the point
 arithemetics you must handle the special case of adding colinear points.
 
 If someone is unprepared to deal with these and many other complications
 they may want to leave writing this kind of software for other people.
 
 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Multisign payment protocol?

2014-03-11 Thread Eric Lombrozo
Ciphrex CoinVault (https://ciphrex.com) is currently using parallel trees with 
lexicographic sorting of keys.

CoinVault is also using a partially signed transaction format whereby 0-length 
placeholders are used for missing signatures in the transaction scripts. Once 
all the required signatures to satisfy the policy are present, the remaining 
zero-length placeholders are removed so the transaction can be broadcast to the 
network. These partially signed transactions can be shared with other parties 
to an account or other signing devices for the purpose of requesting additional 
signatures.

-Eric


On Mar 11, 2014, at 7:35 PM, Alan Reiner etothe...@gmail.com wrote:

 I might as well throw in a word about Armory.  After our next release in a 
 couple weeks, we will be going full-speed at new wallets and BIP32 
 integration.  Just like Jean-Pierre mentioned, we'll be using parallel trees 
 to generate P2SH addresses after sorting the keys lexicographically.  We plan 
 to introduce the concept of a wallet bundle (that name is far from 
 concrete... I'd love a better word).  All wallets in a bundle are protected 
 by the same backup, and stored in the same file.  The default behavior will 
 be use new branches in the same BIP32 tree when a user creates a new 
 wallet, though we will allow multiple bundles in advanced and expert 
 usermode (which is needed to have watching-only wallets from a different seed 
 created from an offline computer).
 
 However, we do plan to allow separate parties to create multisig-intended 
 wallets with public parts that can be exported and combined with other users. 
  We feel this is critical, as it allows for linked wallets in which there was 
 never a single-point of failure from key-generation to signing.  This is 
 especially important for contexts where employees may be handling a company's 
 Bitcoins wallets.
 
 On this topic, I have gotten a lot of inquiries into BIP 38 and 39.  I was 
 not clear whether those BIPs were worth prioritizing ... i.e. is there a 
 general consensus from a variety of wallet developers that they should be 
 supported?  Rather, I'm happy to start prioritizing them if others do too, 
 but I haven't spent much time trying to understand them to even know if 
 they're mature, yet.
 
 -Alan
 
 
 On 03/11/2014 08:29 PM, Jean-Pierre Rupp wrote:
 Hello people,
 
 We are working on some of this stuff. We had some very early draft on
 how we envisioned multisig happening. It is all implemented in Haskoin
 available as multiple repositories in Github. I am happy to see this
 gathering momentum.
 
 Our multisig system uses BIP-0032 HD wallets, and there will soon be
 BIP-0039 support for keys compatibility.
 
 Our wallet uses synced trees rooted at the extended pubkeys of the
 participants. Currently we are sorting public keys in the scripts to
 avoid ambiguity.
 
 Download haskoin-wallet:
 
 cabal install haskoin-wallet
 
 Check out the hw command (installed in ~/.cabal/bin/hw). Use importtx to
 bring transactions into the wallet. You must initialize first with a
 seed and create an account. It supports both regular and multisig accounts.
 
 Perhaps this can lead to interesting discussions on key exchange, and
 the appropriate handling of wallet metadata. I’d love to work on a
 proper standard that could lead us to compatible implementations.
 
 This document explains how we do it now:
 
 http://haskoin.com/~xeno/hd-multisig-wallet.html
 
 Cheers!
 
 
 
 --
 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/13534_NeoTech
 
 
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 --
 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/13534_NeoTech___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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 

Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys

2014-03-05 Thread Eric Lombrozo
If we don't mind sacrificing some performance when signing, there's a fairly 
simple way to implement a constant-time constant-cache-access-pattern secp256k1.
It is based on the idea of branchless implementations of the field and group 
operations.

Multiprecision arithmetic can be implemented branch-free by assuming fixed 
sized limbs and always performing dummy carry operations even when they aren't 
needed.

The most critical field operation that could potentially leak data is the 
modular inverse. Again, if we don't mind a slow implementation, a simple 
constant-time implementation involves exponentiation by the field modulus minus 
two - which is a known constant.

As for group operations in secp256k1, the main sources of leaks are the 
branchings that exist in typical implementations as well as optimizations for 
special inputs,
i.e. http://en.wikibooks.org/wiki/Cryptography/Prime_Curve/Jacobian_Coordinates
To avoid leaking any information, we can use the most general operation, Point 
Addition, in the following way:

Always carry through the full point addition algorithm even if we get 
POINT_AT_INFINITY. Also, always carry through the POINT_DOUBLE operation even 
on unequal inputs. Store the three possible results (POINT_ADDITION, 
POINT_AT_INFINITY, and POINT_DOUBLE) and then do a branchless conditional swap 
with the output location as a final step.

Branchless swaps can be performed using bitwise operations such as the examples 
here: https://github.com/CodeShark/cmp/blob/master/src/constant-time.h

--

In the case of bitcoin, signature verification is where performance 
optimization is really helpful - and here there are no risks of sidechannel 
leaks, so we can go ahead and use the most optimal implementations. But for 
signing, the amount of throughput required is generally not that large and 
constant-time implementations will be more than adequate on typical hardware.

-Eric Lombrozo

On Mar 5, 2014, at 4:49 AM, Mike Hearn m...@plan99.net wrote:

 A new practical technique has been published that can recover secp256k1 
 private keys after observing OpenSSL calculate as little as 200 signatures:
 
 http://eprint.iacr.org/2014/161.pdf
 
 This attack is based on the FLUSH+RELOAD technique published last year. It 
 works by observing L3 CPU cache timings and forcing cache line flushes using 
 the clflush opcode. As a result, it is applicable to any x86 environment 
 where an attacker may be able to run on the same hardware i.e. virtualised 
 hosting environments where keys are being reused.
 
 I am not currently aware of any efforts to make OpenSSL's secp256k1 
 implementation completely side channel free in all aspects. Also, 
 unfortunately many people have reimplemented ECDSA themselves and even if 
 OpenSSL gets fixed, the custom implementations probably won't. 
 
 So, IMHO this is a sign for hot wallet users to start walking (but not 
 running) towards the exits of these shared cloud services:  it doesn't feel 
 safe to sign transactions on these platforms, so hot wallets should be 
 managed by dedicated hardware. Of course other parts of the service, like the 
 website, are less sensitive and can still run in the cloud. I doubt the 
 researchers will release their code to do the side channel attack and it's 
 rather complex to reimplement, so this gives some time for mitigation. 
 Unfortunately the huge sums being held in some bitbank style hot wallets 
 mean that attackers are well motivated to pull off even quite complex attacks.
 --
 Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
 With Perforce, you get hassle-free workflows. Merge that actually works. 
 Faster operations. Version large binaries.  Built-in WAN optimization and the
 freedom to use Git, Perforce or both. Make the move to Perforce.
 http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys

2014-03-05 Thread Eric Lombrozo
Everything you say is true.

However, branchless does reduce the attack surface considerably - if nothing 
else, it significantly ups the difficulty of an attack for a relatively low 
cost in program complexity, and that might still make it worth doing.

As for uniform memory access, if we avoided any kind of heap allocation, 
wouldn't we avoid such issues?

Anyhow, without having gone into the full details of this particular attack, it 
seems the main attack point is differences in how squaring and multiplication 
(in the case of field exponentiation) or doubling and point addition (in the 
case of ECDSA) are performed. I believe using a branchless implementation where 
each phase of the operation executes the exact same code and accesses the exact 
same stack frames would not be vulnerable to FLUSH+RELOAD.

To be able to recover the sequence of point additions and doublings, the spy 
program should distinguish
between consecutive doubling operations and must be able to order them with 
respect to point additions.
Our spy program achieves this by setting the time slot to less than half the 
length of the group operations.
With the selected curve, group add operations take 7,928 cycles on average, 
while group double operation
take 7,601 cycles. Setting the time slot to 3,000 cycles ensures that there is 
an empty time slot within any
group operation, allowing our spy to correctly distinguish consecutive doubles

The approach I've suggested makes doubling operations indistinguishable from 
point additions from the perspective of cache access.

On Mar 5, 2014, at 1:44 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

 On Wed, Mar 5, 2014 at 1:31 PM, Eric Lombrozo elombr...@gmail.com wrote:
 If we don't mind sacrificing some performance when signing, there's a fairly
 simple way to implement a constant-time constant-cache-access-pattern
 secp256k1.
 It is based on the idea of branchless implementations of the field and group
 operations.
 
 Do take care that branchless doesn't mean side-channel free: On
 non-trivial hardware you must have uniform memory accesses too.
 
 (and that itself isn't enough for sidechannel freeness against an
 attacker that can do power analysis... then you star worrying about
 the internal structure your primitive adders and the hamming weight of
 your numbers, and needing to build hardware that uses differential
 logic, and yuck yuck yuck:  This is why you still shouldn't reuse
 addresses, and why a blinding approach may still be sensible, even if
 you believe your implementation is hardened against side-channels)



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys

2014-03-05 Thread Eric Lombrozo
Oh, I absolutely agree that this type of attack is NOT the weakest link in 
security. There are MANY far easier targets in bitcoind and typical use 
scenarios of it. If we want to dramatically improve the security of a typical 
bitcoin wallet, the FLUSH+RELOAD attack is probably not where our efforts would 
be best rewarded trying to prevent.

However, this thread IS about this particular attack vector - and my suggestion 
IS specific to this thread.

-Eric Lombrozo


On Mar 5, 2014, at 2:17 PM, James Hartig fastest...@gmail.com wrote:

 On Wed, Mar 5, 2014 at 2:39 PM, Peter Todd p...@petertodd.org wrote:
  More important though is you shouldn't be using single factor Bitcoin
  addresses. Use n-of-m multisig instead and architect your system such
  that that every transaction that happens in your service has to be
  authorized by both the online server(s) that host your website as well
  as a second hardened server with an extremely limited interface
  between it and the online server.
 
 This adds a very minor amount of security, if any, if someone manages to hack 
 into your hot wallet server they can just initiate a non-multisig 
 transaction and still steal all your bitcoins in that wallet. You can't give 
 the argument that the RPC API is password protected because the password is 
 stored in plain-text in the config so all someone has to do is first grep for 
 the file. There doesn't appear to be a way to force ALL outgoing transactions 
 to be multisig and even if there was one, would you be able to force one of 
 the addresses to be the hardened server? That still wouldn't prevent anyone 
 from just stopping bitcoind, changing the config, then restarting it.
 
 Unless you're using your own custom wallet software there doesn't seem to be 
 any sufficient way to prevent someone from stealing all your money once they 
 have access to your server. Other software, like MySQL has access controls so 
 I can prevent ALTERs, DROPs, DELETEs, etc for all live accounts limiting 
 the scope of any attack if they manage to get into the server. Maybe this is 
 beyond the scope of bitcoind, not sure.
 
 Thanks,
 --
 James Hartig
 Software Engineer @ Grooveshark.com
 http://twitter.com/jameshartig
 --
 Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
 With Perforce, you get hassle-free workflows. Merge that actually works. 
 Faster operations. Version large binaries.  Built-in WAN optimization and the
 freedom to use Git, Perforce or both. Make the move to Perforce.
 http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Making the H in HD keychains useful

2014-03-01 Thread Eric Lombrozo
I've been trying to find ways to make HD keychain wallets (BIP0032) really 
usable from an application development perspective. I think we all know a 
number of solid use cases and possible applications for the D in HD, but nobody 
seems to have really found a way to make use of the H in a way that is actually 
manageable from a usability standpoint.

After pondering it a bit more, I think I've stumbled upon at least a couple 
issues that seem to give hints as to how we can change this.

Hierarchical organizations do not generally tend to be designed up front, cast 
in stone. In the real world, hierarchies tend to evolve organically, growing 
new branches as entities differentiate themselves to different purposes. 
Organizations grow over time. Sometimes branches merge, sometimes branches die. 
This means that for HD keychains to be truly useful, they too need to be 
sufficiently flexible to adapt to the needs of a growing and evolving 
organization. It needs to be simple to create and move branches around as the 
need for them arises without having to plan the structure a priori.

A significant problem I'm runnign into in trying to build applications around 
the BIP0032 standard is the lack of a clear separation between signing keys and 
hierarchical nodes. That's to say, a child of a node can either be used as a 
signing key or as a parent for new branches to the tree. From a usability 
standpoint, what this means is that one must be very careful in how one 
allocates keys from the very beginning - if one mixes signing keys with new 
branching nodes in the same generation, the whole thing becomes a horrendous 
mess. Moreover, it is impossible to generally distinguish these two 
fundamentally different types of objects (at least from a use model 
perspective) just from the extended key representation, something that is 
certain to create significant confusion as we try to design applications that 
can share these types of objects.

An organization might begin as a single individual who just wants to generate 
signing keys for him/herself. Later on, this individual might bring on another 
individual or two and create new branches for them. With the current HD 
keychain structure, unless this individual made sure to set aside these new 
branches from the start, the individual is now forced to mix the new branches 
in at the same level of the hierarchy as the signing keys. Instead, it should 
be possible to branch off any node without having to worry at all about whether 
or not that node has been used to generate signing keys at all.

A possible workaround to this issue is to always allocate a specific child for 
hierarchical derivation and the rest of the children for signing keys. Then to 
create subbranches, the specific child would be used as the new parent, 
effectively alternating generations between signing keys and organizational 
nodes. However, this solution seems pretty ugly.

A better solution, IMO, is to only use BIP0032 for organizational hierarchy and 
have a different mechanism for generating a sequence of signing keys from a 
given node. This different mechanism could be used standalone by those not 
needing the full set of hierarchical features. For those who do want to use the 
hierarchical features, it could be seeded by the keys in the BIP0032 hierarchy. 
These individual signing keys would NEVER be represented in the same format as 
the organizational hierarchy nodes, thus ensuring applications can share these 
structures without risk of confusion.

Until we make this clear distinction between organizational hierarchy (which 
parallels real-world organizations) and signing keys (which are merely 
cryptographic primitives, preferably never even shown directly to most 
endusers), I think we'll fail to find good ways to make the H in HD keychains 
useful.

-Eric Lombrozo


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Testnet block explorer

2013-12-27 Thread Eric Lombrozo
I've built a shell around the bitcoind JSON-RPC, along with a websockets server 
that provides realtime transaction and block feeds which can be used with 
bitcoin mainnet and testnet as well as any of the alt chains and formats it 
similar to blockchain.info with the bootstrap look-and-feel, i.e. 
http://altcoins.ws/dogecoin/

A goal of this project was simplicity in deployment to a new server.

The JSON-RPC is missing address indexing and an unspent API, so these things 
are still missing from this shell.

-Eric

On Dec 27, 2013, at 11:23 AM, Melvin Carvalho melvincarva...@gmail.com wrote:

 
 
 
 On 27 December 2013 19:08, Mike Belshe m...@belshe.com wrote:
 Great!
 
 There is another one at http://testnet.btclook.com/ which provides a 
 different view as well.
 
 And another at:
 
 http://test.webbtc.com/
 
 Testnet does not currently fully function with for creating transactions:
 
 http://test.webbtc.com/
 
 Because there's no unspent API for getting the unspent values for an 
 address.  If there existed a testnet explorer which would send out those 
 values (as blockchain.info does with the main net), that would be awesome.
 
 I'm also working on a testnet explorer with semantic web markup so that it's 
 both human and machine readable.
  
 
 Mike
 
 
 
 On Fri, Dec 27, 2013 at 10:05 AM, Mike Hearn m...@plan99.net wrote:
 For a long time the only block explorer for testnet has been the original 
 blockexplorer.com, which is unfortunately often broken / behind / slow and 
 not really maintained any more.
 
 There is now a new one, here:
 
 https://www.biteasy.com/testnet/blocks
 
 There's also a REST/JSON API for it.
 
 Please note one curiosity of this block explorer is that the coinbase tx 
 doesn't necessarily come first in the listing (it's sorted by time 
 received, see).
 
 Other interesting thing to note: this site is built using bitcoinj. The 
 author can be contacted on IRC sometimes using the nick damethos.
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Testnet block explorer

2013-12-27 Thread Eric Lombrozo
I'll add testnet to it as well - sorry, Ben, for lifting the css (I'm a 
programmer, not a graphic designer) - if anyone would like to help me make the 
styling original, I would be more than happy to collaborate.

-Eric

On Dec 27, 2013, at 1:36 PM, Eric Lombrozo elombr...@gmail.com wrote:

 I've built a shell around the bitcoind JSON-RPC, along with a websockets 
 server that provides realtime transaction and block feeds which can be used 
 with bitcoin mainnet and testnet as well as any of the alt chains and formats 
 it similar to blockchain.info with the bootstrap look-and-feel, i.e. 
 http://altcoins.ws/dogecoin/
 
 A goal of this project was simplicity in deployment to a new server.
 
 The JSON-RPC is missing address indexing and an unspent API, so these 
 things are still missing from this shell.
 
 -Eric
 
 On Dec 27, 2013, at 11:23 AM, Melvin Carvalho melvincarva...@gmail.com 
 wrote:
 
 
 
 
 On 27 December 2013 19:08, Mike Belshe m...@belshe.com wrote:
 Great!
 
 There is another one at http://testnet.btclook.com/ which provides a 
 different view as well.
 
 And another at:
 
 http://test.webbtc.com/
 
 Testnet does not currently fully function with for creating transactions:
 
 http://test.webbtc.com/
 
 Because there's no unspent API for getting the unspent values for an 
 address.  If there existed a testnet explorer which would send out those 
 values (as blockchain.info does with the main net), that would be awesome.
 
 I'm also working on a testnet explorer with semantic web markup so that it's 
 both human and machine readable.
  
 
 Mike
 
 
 
 On Fri, Dec 27, 2013 at 10:05 AM, Mike Hearn m...@plan99.net wrote:
 For a long time the only block explorer for testnet has been the original 
 blockexplorer.com, which is unfortunately often broken / behind / slow and 
 not really maintained any more.
 
 There is now a new one, here:
 
 https://www.biteasy.com/testnet/blocks
 
 There's also a REST/JSON API for it.
 
 Please note one curiosity of this block explorer is that the coinbase tx 
 doesn't necessarily come first in the listing (it's sorted by time 
 received, see).
 
 Other interesting thing to note: this site is built using bitcoinj. The 
 author can be contacted on IRC sometimes using the nick damethos.
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics 
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics 
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics 
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))

2013-09-06 Thread Eric Lombrozo
Why not just use the transaction hash itself for the lookup? Also, presumably 
you'd want to encrypt the data so that only the recipient of the transaction 
can do this lookup.

-Eric

On Sep 6, 2013, at 8:07 AM, Wendell w...@grabhive.com wrote:

 Hi all,
 
 We're thinking about ways of automatically exchanging contact details between 
 wallets, in order to encourage the proliferation of identifiable names and 
 photos rather than long and hard-to-verify addresses.
 
 The simplest version goes like this:
 
 2 BTC Bitcoin is sent to someone, and a data lookup hash is inserted into the 
 transaction. When it arrives on the other end, it is indeed looked up, and 
 instead of being presented with a dialogue that says you received 2 BTC from 
 13Y94z43Nbbb6wevRyk82CeDoYQ5S28zmA, it's You received 2 BTC from Frank 
 Jones including a nice photo.
 
 Now. We can simply delete this data in reference to the transaction ID after 
 it happens (or delete it after a time), but is there any more decentralized 
 way to do it? I would prefer us to run no dedicated servers that would ever 
 put us in a position of being coerced into giving data, or otherwise altering 
 our system to store it.
 
 Any thoughts about this?
 
 -wendell
 
 grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
 
 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Zero-length scripts

2012-12-12 Thread Eric Lombrozo
I've noticed a few transactions that have zero-length input and/or output 
scripts. There's a couple examples in block 
0159a27442ee8b7f9ffad0cd799b003eafe007de9fbb47bd6ce7:

Txs: cdb553214a51ef8d4393b96a185ebbbc2c84b7014e9497fea8aec1ff990dae35, 
af32bb06f12f2ae5fdb7face7cd272be67c923e86b7a66a76ded02d954c2f94d


Is there ever a legitimate reason to create a transaction with a zero-length 
script? Should the protocol even allow it?

-Eric Lombrozo

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Adding callback hooks to the satoshi client

2012-03-24 Thread Eric Lombrozo
I'd also like to be able to get detailed information of message format
errors for debugging other nodes that connect to bitcoind. For
instance, if a transaction is rejected because the signature is
invalid, I want to know this. If it's because the amount is out of
range or because the output couldn't be connected, I want to know
this, too. I especially want to know if it was because the transaction
is claiming an output that has already been claimed by another
transaction.

For now, I've had to resort to sticking tracers and stubs into
bitcoind. It would be really nice to not only be able to write an
error log but to also let the connecting node know what went wrong.
Obviously these types of messages should *not* be part of the bitcoin
protocol itself since it invites all kinds of attacks. But it would be
wonderful to have a side channel for this type of data, and it could
also be done using callbacks.

The callback mechanism could be configurable in a similar fashion to
the RPC in the bitcoin.conf file.

-Eric Lombrozo

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Adding callback hooks to the satoshi client

2012-03-22 Thread Eric Lombrozo
The callback architecture could be such that other code would never
need to enter into the wallet-handling process/memory space. For
instance, client applications could subscribe a particular URL to get
sent an HTTP POST.

For the apps I've been working on, there really isn't any need to
access the wallet space. I was talking more about events like A new
transaction was just seen or A new block was just seen, like what
libcoin seems to support (sorry, Michael, I haven't really had a
chance to look at it in depth but I will). Then there are other types
of events for other bitcoin messages could also be useful: new addr,
new node connected, node disconnected, bitcoin alert, etc...

Then there are events for dealing with potential attacks: DoS attempt,
double-spend attempts (two transactions seen with valid signatures
claiming the same output), node sending malformed messages, etc...

And then there are alerts pertaining to the status of the bitcoind
process itself: bitcoind started, bitcoind ready to accept
connections, bitcoind stopping, etc...

None of these events require the callback subscriber to have any
access to the bitcoind process/memory space and all the I/O could be
done via IPC or over network sockets.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Adding callback hooks to the satoshi client

2012-03-21 Thread Eric Lombrozo
Hey, guys.

I've been writing a number of apps that require realtime event
notifications, where the JSON-RPC API clearly doesn't suffice.

There are two approaches I've been taking to this end:

1) Writing my own library for dealing with raw bitcoin structures and
connecting to bitcoin nodes via the bitcoin protocol.
2) Making custom builds of the satoshi client putting callback hooks
in key points.

Neither of these two approaches is ideal. (1) involves a lot of code
duplication, (2) involves patching the satoshi client source
each time I grab a later version, with the everpresent risk of
something breaking and the need to continue maintaining these patches.
Moreover, unfortunately many of these key points happen to be in files
like main.cpp which see frequent changes.

I would like to propose adding these callback hooks to the main
branch. I am willing to help locate these key points, reorganize the
code
to place these methods in separate source files, define a callback
mechanism, and contribute source code.

-Eric Lombrozo

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development