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

[Eric Lombrozo]

> On Jun 21, 2015, at 1:41 AM, Btc Drak  wrote:
> 
> Eric,
> 
> BitPay clearly do understand the risks of 0-conf. In case you were not aware 
> BitPay does not particularly "accept zero confirm transactions". When a 
> payment is seen on the network the payment screen reports the invoice has 
> been paid, but that's front-end user facing. On the back end it's marked as 
> paid but the API exposes the the confirmation status allowing the merchant to 
> make business decisions about when to progress to fulfilment. A good example 
> of this is Neteller (a sort of paypal variant) which allows one to fund the 
> account with fiat using Bitcoin, via Bitpay. When you pay the bitpay invoice, 
> your account is marked as payment pending until there are some confirmations.
> 

I am glad to hear that. Yes, it absolutely makes sense to let the merchant to 
make business decisions still pending confirmation (i.e. should I actually 
ship?)

> Coinbase does not expose the confirmation status and from what I understand 
> (not checked myself) they guarantee payment to merchants for 0-confirm, 
> regardless of whether they confirm or not.

Then Coinbase is essentially taking on the role of an insurer…are they taking 
the appropriate precautions to limit potential losses? Can they make up for 
these losses with fees? And if not (or if they don’t really have a quantifiable 
risk model) could they survive a worst-case scenario with at most a surface 
wound? (i.e. a systemic attack involving many machines in many different places 
all attacking at once).

It would be absolutely the height of idiocy to guarantee payment on merchandise 
that has yet to ship, i.e. So I hope these reports are wrong :)


- 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

[Eric Lombrozo]

> On Jun 21, 2015, at 12:42 AM, Eric Lombrozo  wrote:
> 
> 
>> On Jun 20, 2015, at 11:45 PM, Jeff Garzik > <mailto:jgar...@bitpay.com>> wrote:
>> 
>> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo > <mailto:elombr...@gmail.com>> wrote:
>>  but we NEED to be applying some kind of pressure on the merchant end to 
>> upgrade their stuff to be more resilient
>> 
>> Can you be specific?  What precise technical steps would you have BitPay and 
>> Coinbase do?  We upgrade our stuff to... what exactly?
>> 
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc.  https://bitpay.com/ <https://bitpay.com/>
> Thanks for asking *the* question, Jeff. We often get caught up in these 
> philosophical debates…but at the end of the day we need something concrete.
> 
> Even more important than the specific software you’re using is the security 
> policy.
> 
> If you must accept zero confirmation transactions, there are a few concrete 
> things you can do to reduce your exposure:
> 
> 1) limit the transaction amounts for zero confirmation transactions - do not 
> accept them for very high priced goods…especially if they require physical 
> shipping.
> 2) limit the total amount of unconfirmed revenue you’ll tolerate at any given 
> moment - if the amount is exceeded, require confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, etc…) the 
> ability to shut the user out if a double-spend is detected.
> 4) collect legal information on purchasers (or have the merchants collect 
> this information) so you have someone to go after if they try to screw you
> 5) create a risk profile for users…and flag suspicious behavior (i.e. someone 
> trying to purchase a bunch of stuff that totally doesn’t fit into their 
> purchasing habits).
> 6) get insurance (although right now reasonably-priced insurance is probably 
> pretty hard to obtain since statistics are generally of little use…we’re 
> entering uncharted territory).
> 7) set up a warning system and a “panic” button so that if you start to see 
> an attack you can immediately disable all zero confirmation transactions 
> system-wide.
> 8) independently verify all inbound transactions and connect to multiple 
> network nodes…check them against one another.
> 
> 
> As for software tools to accomplish these things, we can talk about that 
> offline :)
> 
> 
> - Eric Lombrozo
> 
> 
> 
> 

I should also point out that pretty much all of these suggestions (except for 
maybe 8) would apply to ANY payment system…they are NOT specific to Bitcoin 
whatsoever. Any serious payment processor should have these sorts of policies 
engrained as part of company culture…or else one day (probably not too long 
from now) you’ll be out of business. The mere suggestion that changing relay 
policy would pose significant threats to the bottom line of a payment processor 
is about the height of amateurishness, IMHO.


- 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

[Eric Lombrozo]

> On Jun 20, 2015, at 11:45 PM, Jeff Garzik  wrote:
> 
> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo  <mailto:elombr...@gmail.com>> wrote:
>  but we NEED to be applying some kind of pressure on the merchant end to 
> upgrade their stuff to be more resilient
> 
> Can you be specific?  What precise technical steps would you have BitPay and 
> Coinbase do?  We upgrade our stuff to... what exactly?
> 
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/ <https://bitpay.com/>
Thanks for asking *the* question, Jeff. We often get caught up in these 
philosophical debates…but at the end of the day we need something concrete.

Even more important than the specific software you’re using is the security 
policy.

If you must accept zero confirmation transactions, there are a few concrete 
things you can do to reduce your exposure:

1) limit the transaction amounts for zero confirmation transactions - do not 
accept them for very high priced goods…especially if they require physical 
shipping.
2) limit the total amount of unconfirmed revenue you’ll tolerate at any given 
moment - if the amount is exceeded, require confirmations.
3) give merchants of subscription services (i.e. servers, hosting, etc…) the 
ability to shut the user out if a double-spend is detected.
4) collect legal information on purchasers (or have the merchants collect this 
information) so you have someone to go after if they try to screw you
5) create a risk profile for users…and flag suspicious behavior (i.e. someone 
trying to purchase a bunch of stuff that totally doesn’t fit into their 
purchasing habits).
6) get insurance (although right now reasonably-priced insurance is probably 
pretty hard to obtain since statistics are generally of little use…we’re 
entering uncharted territory).
7) set up a warning system and a “panic” button so that if you start to see an 
attack you can immediately disable all zero confirmation transactions 
system-wide.
8) independently verify all inbound transactions and connect to multiple 
network nodes…check them against one another.


As for software tools to accomplish these things, we can talk about that 
offline :)


- 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

[Eric Lombrozo]

One more thing I would like to add to this thread: I want to make it 
unequivocally clear that I believe what is making double-spends easier has 
relatively little to do with the protocol and almost everything to do with poor 
software and poor security policy on the merchant end. Perhaps it isn’t prudent 
to push out changes to the relay policy that make these exploits even easier 
right now - but we NEED to be applying some kind of pressure on the merchant 
end to upgrade their stuff to be more resilient so that we have more room for 
changes on things like relay policy without significant disruption to the 
network.

- 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

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

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

[Eric Lombrozo]

> On Jun 20, 2015, at 4:47 PM, Eric Lombrozo  wrote:
> 
> 
>> On Jun 20, 2015, at 4:16 PM, Jorge Timón  wrote:
>> 
>> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo  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

[Eric Lombrozo]

I should also add that I think many in this space believe they have assessed 
the risk as acceptable but haven’t really considered how to cap potential 
losses nor made contingency plans for when the inevitable attacks *do* come.

- Eric Lombrozo

> On Jun 20, 2015, at 4:47 PM, Eric Lombrozo  wrote:
> 
> 
>> On Jun 20, 2015, at 4:16 PM, Jorge Timón  wrote:
>> 
>> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo  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



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

[Eric Lombrozo]

> On Jun 20, 2015, at 4:16 PM, Jorge Timón  wrote:
> 
> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo  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


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

[Eric Lombrozo]

> On Jun 19, 2015, at 8:48 PM, Luke Dashjr  wrote:
> 
> On Saturday, June 20, 2015 1:23:03 AM Aaron Voisine wrote:
>> 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.
> 
> They never will be. You can get a decent rate of success merely by making one
> transaction propagate fast (eg, 1 input, 1 output) and the other slow (eg,
> 1000 inputs, 1000 outputs) and choosing your peers carefully. The only reason
> unconfirmed transactions aren't double spent today is because nobody is
> seriously *trying*.
> 
> Luke
> 


Newspapers are often sold in vending machines that make it possible for anyone 
to just pay the price of one and take them all…and most of the time they are 
not that carefully monitored. Why? Because most people have better things to do 
than try to steal a few newspapers. They probably were much more closely 
monitored earlier in their history…but once it became clear that despite the 
obvious attack vector very few people actually try to game it, vendors figured 
it wasn’t really that big a risk. Same thing applies to people trying to steal 
a piece of bubble gum at the cash register at a convenience store by 
double-spending.

- 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] F2Pool has enabled full replace-by-fee

[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  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  <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  <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] F2Pool has enabled full replace-by-fee

[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  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] F2Pool has enabled full replace-by-fee

[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  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] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Eric Lombrozo]

IPv4 came before IPv6…you pick up on things quickly :)

> On Jun 19, 2015, at 5:48 AM, Marcel Jamin  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  <mailto:elombr...@gmail.com>>:
> 
>> On Jun 19, 2015, at 3:45 AM, Dr Adam Back > <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  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] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Eric Lombrozo]

> On Jun 19, 2015, at 3:45 AM, Dr Adam Back  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 .


- 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] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Eric Lombrozo]

> On Jun 19, 2015, at 3:45 AM, Dr Adam Back  <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 .


- 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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Eric Lombrozo]

> On Jun 19, 2015, at 2:37 AM, Mike Hearn  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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[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  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 opport

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

[Eric Lombrozo]

> On Jun 15, 2015, at 3:54 PM, odinn  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] comments on BIP 100

[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] comments on BIP 100

[Eric Lombrozo]

> On Jun 14, 2015, at 9:11 PM, Peter Todd  wrote:
> 
> On Sun, Jun 14, 2015 at 05:53:05PM -0700, Eric Lombrozo wrote:
>> I think the whole complexity talk is missing the bigger issue.
>> 
>> Sure, per block validation scales linearly (or quasilinearly…there’s an 
>> O(log n) term in there somewhere but it’s probably dominated by linear 
>> factors at current levels…asymptotic limits don’t always apply very well to 
>> finite systems). And there’s an O(n^2) bandwidth issue.
>> 
>> The real issue, though, is validation cost. The n in O(n) here does not 
>> represent block size - it represents the size of the entire block chain for 
>> every new validator that must be synchronized! It means we have no way to 
>> construct short proofs (or at least arguments that are computationally 
>> *hard* to forge) without requiring the validator to maintain the complete 
>> system state. And currently, there is no mechanism for directly compensating 
>> validators.
> 
> ...and can there be? The goal of validation after all is finding if a
> mistake has been made, and current production cryptography doesn't have
> any way to prove you have done that honestly. You need "moon math" like
> recursive SNARKS to do that, and it's unknown when they'll be available
> for production usage.
> 

While things like zero-knowledge and homomorphic encryption would be awesome, 
they are not really needed to achieve the objective of an efficient proof that 
is hard to forge with at least a decently thought out security model (i.e. we 
can make information withholding far more difficult)…and we can dramatically 
improve search times and local storage requirements by doing some of the things 
that you’ve actually proposed, Peter, like shifting the responsibility of 
maintaining and constructing proofs over to transaction senders and committing 
proof hashes to the global state. At least the incentives would be far better 
aligned in such a scenario.

How do we deal with things like the discovery of an invalid proof a couple 
weeks after it’s already been committed? This is a tricky issue I’ve been 
giving a lot of thought to recently - but we’ll deal with this topic in a 
separate thread. :)

> When we say "compensating validators", if we're being honest with
> outselves what we really mean is the much more boring task of
> compensating servers who are giving us blockchain data. That has nothing
> to do with validation.

If we were to shift responsibility of constructing proofs over to transaction 
senders, today's “validators” would indeed become nothing more than compensated 
servers. Clients would be able to query for proofs and verify them for 
themselves efficiently.

> A useful task would be to make an SPV archival node implementation that
> did no validation at all, while distributing the blockchain data linked
> to the longest chain. Such an implementation can and should serve SPV
> clients, as this is what their actual security model usually is given
> the lack of authentication of the identity of the server they're
> connecting too. Actually implementing this would be a simple matter of
> patching Bitcoin Core to turn off block validation.
> 
>> A full validator that goes offline even for a short period of time takes a 
>> while to fully catch up to the rest of the network - and starting up a new 
>> validator from scratch will continue to be painful…even for those of us 
>> who’ve turned this into routine by now, let alone new nontechnical users.
> 
> Concretely, 20MB blocks lead to 20GB/week of blocks. On my 1MB/second
> down internet, turning on my node after a week away would take five
> hours; starting up a new node after two years of 20MB blocks would take
> 23 days - likely longer in practice.
> 
> There's serious unsolved and undiscussed devops and development issues
> with this. For instance, after changes to the validation code, it's
> routine to resync/reindex Bitcoin Core to ensure starting up a new node
> actually works. Even now we haven't really come to grips with what
> consistent 1MB blocks looks like from this point of view after a few
> years of usage, let another order of magnitude longer sync times.
> 

It’s a disaster. Even with 1MB blocks this is already the principal 
centralization pressure on Bitcoin.

>> Satoshi’s SPV is not a real solution - it’s a mere suggestion that wasn’t 
>> fully thought out at the time of the Bitcoin white paper. Besides lacking a 
>> good validation security model, practical implementations of it weaken 
>> privacy and complicate client implementations substantially…and the worst 
>> part, it still doesn’t scale all that well. The validator still has to query 
>> e

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

[Eric Lombrozo]

> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo  <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?


> On Jun 13, 2015, at 10:36 PM, Jeff Garzik  wrote:
> 
> The choice is very real and on-point.  What should the block size limit be?  
> Why?
> 
> There is a large consensus that it needs increasing.  To what?  By what 
> factor?

To be clear, Jeff, I am 100% in agreement with you that a mechanism like what 
you’re proposing is a million times better than having high priests that ram 
hard forks without proper consensus. And perhaps given the present 
circumstances it seems like the only alternative. However, in my mind this 
block size limit controversy is actually a fairly superficial aspect - a mere 
symptom, a manifestation of the real problem...

What I find somewhat irksome is that we’ve had six years to figure out a 
mechanism to enable hard forks (which we knew from the start would be 
inevitable) - and more to the point, we’ve known about this block size issue 
from the start as well…and only suddenly it becomes an issue of major urgency 
that we must bump up this parameter 20x…

- 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] comments on BIP 100

[Eric Lombrozo]

> On Jun 14, 2015, at 5:53 PM, Eric Lombrozo  wrote:
> 
> I think the whole complexity talk is missing the bigger issue.
> 
> Sure, per block validation scales linearly (or quasilinearly…there’s an O(log 
> n) term in there somewhere but it’s probably dominated by linear factors at 
> current levels…asymptotic limits don’t always apply very well to finite 
> systems). And there’s an O(n^2) bandwidth issue.

For accuracy’s sake, I meant to say O(n log n).

> 
> The real issue, though, is validation cost. The n in O(n) here does not 
> represent block size - it represents the size of the entire block chain for 
> every new validator that must be synchronized! It means we have no way to 
> construct short proofs (or at least arguments that are computationally *hard* 
> to forge) without requiring the validator to maintain the complete system 
> state. And currently, there is no mechanism for directly compensating 
> validators.
> 
> A full validator that goes offline even for a short period of time takes a 
> while to fully catch up to the rest of the network - and starting up a new 
> validator from scratch will continue to be painful…even for those of us 
> who’ve turned this into routine by now, let alone new nontechnical users.
> 
> Satoshi’s SPV is not a real solution - it’s a mere suggestion that wasn’t 
> fully thought out at the time of the Bitcoin white paper. Besides lacking a 
> good validation security model, practical implementations of it weaken 
> privacy and complicate client implementations substantially…and the worst 
> part, it still doesn’t scale all that well. The validator still has to query 
> every single block (even if filtered) back to the first transaction (which 
> cannot be determined without doing a blockchain scan anyway).
> 
> So yes, we will most certainly need algorithmic improvements!
> 
> - Eric Lombrozo
> 
> 
>> On Jun 14, 2015, at 4:58 PM, Adam Back  wrote:
>> 
>> Hi Mike
>> 
>> On 15 June 2015 at 00:23, Mike Hearn  wrote:
>>>> One thing that is concerning is that few in industry seem inclined to
>>>> take any development initiatives or even integrate a library.
>>> 
>>> Um, you mean except all the people who have built more scalable wallets over
>>> the past few years, which is the only reason anyone can even use Bitcoin
>>> from their phone?
>> 
>> No slight intended obviously to people who do write actual client code.
>> 
>> That was probably insufficiently specific, let me rephrase: I am
>> referring to the trend that much of the industry is built on web2.0
>> technology using bitcoin via a library in a web scripting language,
>> often with consensus bugs, and even outsourcing and not even running
>> their own full node, so that the service itself offered to their users
>> isn't even SPV secure to the operator.  As well as being heavily based
>> on a third-party custody model that is the root cause of the repeated
>> wallet breaches.  Some of these companies have a noted tendency not to
>> upgrade or fix code.
>> 
>> So I mean this not to call out specific companies, but in the sense
>> that if we're technologists we should be trying to move the technology
>> forward, not just changing parameters which run into an O(n^2) scaling
>> wall or break decentralisation security.  And we shouldnt take the
>> above state of affairs as an immutable reality.  It can not persist
>> for bitcoin to reach maturity on scale nor security.
>> 
>>> I still think you guys don't recognise what you are actually asking for here
>>> - scrapping virtually the entire existing investment in software, wallets
>>> and tools.
>> 
>> As I said I dont think we can expect Bitcoin to scale with no further
>> algorithmic improvements.  Algorithmic improvements take code.  There
>> is reasonable scope to build in an incrementally deployable way,
>> there's plenty of time for people to code, test and opt-in to things,
>> the sky is not falling.  Companies do care about scaling, and can
>> invest in the integration and coding implied to improve their products
>> scalability, they have an economic incentive to do it and there is no
>> scalable and safe way todo it without this work.
>> 
>>> Computational complexity for the entire network is O(nm) where
>>> n=transactions and m=fully validating nodes. There is no fixed relationships
>>> between those two variables.
>> 
>> I am referring to global bandwidth O(n^2) with n=users, or O(n) per
>> user bandwidth cost to the system, while O(nm) is accurate nodes is an
>> internal system conc

Re: [Bitcoin-development] comments on BIP 100

[Eric Lombrozo]

I think the whole complexity talk is missing the bigger issue.

Sure, per block validation scales linearly (or quasilinearly…there’s an O(log 
n) term in there somewhere but it’s probably dominated by linear factors at 
current levels…asymptotic limits don’t always apply very well to finite 
systems). And there’s an O(n^2) bandwidth issue.

The real issue, though, is validation cost. The n in O(n) here does not 
represent block size - it represents the size of the entire block chain for 
every new validator that must be synchronized! It means we have no way to 
construct short proofs (or at least arguments that are computationally *hard* 
to forge) without requiring the validator to maintain the complete system 
state. And currently, there is no mechanism for directly compensating 
validators.

A full validator that goes offline even for a short period of time takes a 
while to fully catch up to the rest of the network - and starting up a new 
validator from scratch will continue to be painful…even for those of us who’ve 
turned this into routine by now, let alone new nontechnical users.

Satoshi’s SPV is not a real solution - it’s a mere suggestion that wasn’t fully 
thought out at the time of the Bitcoin white paper. Besides lacking a good 
validation security model, practical implementations of it weaken privacy and 
complicate client implementations substantially…and the worst part, it still 
doesn’t scale all that well. The validator still has to query every single 
block (even if filtered) back to the first transaction (which cannot be 
determined without doing a blockchain scan anyway).

So yes, we will most certainly need algorithmic improvements!

- Eric Lombrozo


> On Jun 14, 2015, at 4:58 PM, Adam Back  wrote:
> 
> Hi Mike
> 
> On 15 June 2015 at 00:23, Mike Hearn  wrote:
>>> One thing that is concerning is that few in industry seem inclined to
>>> take any development initiatives or even integrate a library.
>> 
>> Um, you mean except all the people who have built more scalable wallets over
>> the past few years, which is the only reason anyone can even use Bitcoin
>> from their phone?
> 
> No slight intended obviously to people who do write actual client code.
> 
> That was probably insufficiently specific, let me rephrase: I am
> referring to the trend that much of the industry is built on web2.0
> technology using bitcoin via a library in a web scripting language,
> often with consensus bugs, and even outsourcing and not even running
> their own full node, so that the service itself offered to their users
> isn't even SPV secure to the operator.  As well as being heavily based
> on a third-party custody model that is the root cause of the repeated
> wallet breaches.  Some of these companies have a noted tendency not to
> upgrade or fix code.
> 
> So I mean this not to call out specific companies, but in the sense
> that if we're technologists we should be trying to move the technology
> forward, not just changing parameters which run into an O(n^2) scaling
> wall or break decentralisation security.  And we shouldnt take the
> above state of affairs as an immutable reality.  It can not persist
> for bitcoin to reach maturity on scale nor security.
> 
>> I still think you guys don't recognise what you are actually asking for here
>> - scrapping virtually the entire existing investment in software, wallets
>> and tools.
> 
> As I said I dont think we can expect Bitcoin to scale with no further
> algorithmic improvements.  Algorithmic improvements take code.  There
> is reasonable scope to build in an incrementally deployable way,
> there's plenty of time for people to code, test and opt-in to things,
> the sky is not falling.  Companies do care about scaling, and can
> invest in the integration and coding implied to improve their products
> scalability, they have an economic incentive to do it and there is no
> scalable and safe way todo it without this work.
> 
>> Computational complexity for the entire network is O(nm) where
>> n=transactions and m=fully validating nodes. There is no fixed relationships
>> between those two variables.
> 
> I am referring to global bandwidth O(n^2) with n=users, or O(n) per
> user bandwidth cost to the system, while O(nm) is accurate nodes is an
> internal system concept.  Anyway suffice to say the network does not
> scale O(1) in per user cost.
> 
>> "Exposing the companies to back-pressure" sounds quite nice and gentle. Let
>> me rephrase it to be equivalent but perhaps more direct: you mean "breaking
>> the current software ecosystem to force people into a new, fictional system
>> that bears little resemblance to the Bitcoin we use today, whether they want
>> that or not".
>> 
>&g

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

[Eric Lombrozo]

> On Jun 14, 2015, at 3:34 AM, Benjamin  wrote:
> 
> "The size limit is an economic policy lever that needs to be
> transitioned -away- from software and software developers, to the free
> market."
> 
> Exactly right. Bitcoin does not have a free market for fee though, and
> literally all the discussion so far has neglected some fundamental
> aspect of this, as you described. It's not at all a "technical" or
> "engineering" decision. It's the question of how to potentially
> re-design a fundamental part of Bitcoin, and the proposals so far
> don't address this. What is the price of the scarce resource of the
> blockchain and the mechanism to decide on price, once the subsidy runs
> out?
> 

In addition, fees are complicated by the fact that they are used as an 
anti-spam measure for relay nodes…who don’t see ANY direct compensation 
whatsoever for providing that service. So we really have two different fees 
being tacked on…but the miners get to keep all of it…and the relay fee is being 
hard coded into the software.

Fee calculation heuristics for wallets are already far from trivial - this is 
another issue that needs to be addressed.

- Eric Lombrozo

> On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson  wrote:
>> Jeff,
>> 
>> with all due respect, but I've seen you saying this a few times
>> now, that this decision is oh so difficult and important.
>> 
>> But this is not helpful. We all know that. Even I.
>> 
>> Make a suggestion, or stay out of the debate!
>> 
>> Mats
>> 
>> On 06/14/2015 07:36 AM, Jeff Garzik wrote:
>>> The choice is very real and on-point.  What should the block size limit
>>> be?  Why?
>>> 
>>> There is a large consensus that it needs increasing.  To what?  By what
>>> factor?
>>> 
>>> The size limit literally defines the fee market, the whole damn thing.  If
>>> software high priests choose a size limit of 300k, space is scarce, fees
>>> are bid high.  If software high priests choose a size limit of 32mb, space
>>> is plentiful, fees are near zero.  Market actors take their signals
>>> accordingly.  Some business models boom, some business models fail, as a
>>> direct result of changing this unintentionally-added speedbump.  Different
>>> users value adoption, decentralization etc. differently.
>>> 
>>> The size limit is an economic policy lever that needs to be transitioned
>>> -away- from software and software developers, to the free market.
>>> 
>>> A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance
>>> problems associated with actors lobbying developers, even if a cloistered
>>> and vetted Technical Advisory Board as has been proposed.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo  wrote:
>>> 
>>>> 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  wrote:
>>>> 
>>>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo 
>>>> 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?
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> 
>>> 
>>> 
>>> ___
>>> 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

[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  wrote:
> 
> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo  <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

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

[Eric Lombrozo]

What Stephen said is very much along the same lines of my earlier critique. 
This voting mechanism would be all but unusable to most endusers without some 
pretty elaborate tools…and unless users are willing to pay substantially higher 
fees than they’re currently paying, their votes will not really count all that 
much. And it’s not all that clear that most users would really be able to make 
very rational economic decisions even having elaborate tools. More likely, a 
small group would figure out ways to exploit this for their own benefit - at 
everyone else’s expense.

- Eric Lombrozo


> On Jun 13, 2015, at 9:16 PM, Stephen  wrote:
> 
> While this idea is theoretically interesting because it involves many 
> stakeholders, rather than just miners, I think in practice this would not 
> work very well. Users don't want to worry about this kind of technicality, 
> they just want to be able to make a transaction and have it be processed.
> 
> In addition, while this gives stakeholders some weight with the fees they 
> supply, these fees are marginal compared to the block size subsidy. If this 
> proposal were actually implemented, I think miners would vote for whatever 
> they think is best, and users would not contradict them with their votes to 
> ensure a fast confirmation time. Users are incentivized to be in agreement 
> with miners because the miners provide them with the confirmations they need, 
> but fees do not provide a great incentive for miners to be in agreement with 
> users, and likely won't for some time.
> 
> Best,
> Stephen
> 
> 
> 
> 
>> On Jun 12, 2015, at 2:11 PM, Peter Todd  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



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

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



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

[Eric Lombrozo]

Miners currently only collect an almost negligible portion of their revenue
from fees. While I certainly welcome any proposals that move us in the
direction of defining a smooth metaconsensus process, I think with the
curent economics, miners (and especially those with significant hashing
power) have more of an incentive to block txs/spam their votes than to
adapt to tx sender preferences...unless people increase their tx fees
significantly. But without wallets that can make decent suggestions in this
regard, this feature will be almost inaccessible to most regular users. And
the economics still aren't entirely clear.

- Eric Lombrozo
On Jun 12, 2015 12:30 PM, "Jannes Faber"  wrote:

I'm imagining in Peter's proposal it's not the transaction votes that are
counted but only the votes in the blocks? So miners get to vote but they
risk losing money by having to exclude counter voting transactions. But
garbage transactions are no problem at all.

Note that users that want to cast a vote "pay" for that by increased
confirmation time (on average, hopefully slightly depending on the trend).

On Fri, Jun 12, 2015, 20:27 Matt Whitlock  wrote:

> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
> > Peter it's not clear to me that your described protocol is free of miner
> > influence over the vote, by artificially generating transactions which
> they
> > claim in their own blocks
>
> Miners could fill their blocks with garbage transactions that agree with
> their vote, but this wouldn't bring them any real income, as they'd be
> paying their own money as fees to themselves. To get real income, miners
> would have to vote in accordance with real users.
>
>
> --
> ___
> 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

Re: [Bitcoin-development] Proposal: A measured response to save Bitcoin Core

[Eric Lombrozo]

Drak,

I mostly agree with your assessment...except for your last claim.

Not that I wouldn't like to find a way to avoid politics, but like I've
argued before, it is inevitable that sooner or later any consensus protocol
that seeks dynamism will encounter politics.

The block size discussion, while ultimately necessary, for now is in the
best case merely serving as an example of the kind of political issues we
*really* need to be finding some solution for...and in the worst case is a
distraction and evasion.

Some protocol updates will be merely technical optimizations or feature
enhancements that are fairly uncontroversial...but some will inevitably be
highly controversial with real-world economic consequences, winners and
losers. We lack a process for deciding these issues. No matter how
sophistocated we make the protocol, somethings will inevitably require
external input to make these issues decidable...it is a Goedelian
implication. This external input could be some sort of vote (of which
hashing power is a particular kind) or perhaps something else.

There's something to be said for building the dynamics of hard forks *into*
our model rather than avoiding it at all costs.  However, forks are the
easy part. The difficulty is in merging different branches. Perhaps we
should learn a thing or two from git. Perhaps the question we should be
asking is not "how do we avoid hard forks" but "how can we design the
network to allow for merging?"

- Eric Lombrozo
--
___
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

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

[Eric Lombrozo]

> On May 7, 2015, at 4:20 AM, Wladimir J. van der Laan  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

[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  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  <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 wit

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

[Eric Lombrozo]

On Sunday, February 22, 2015, Peter Todd  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo  > 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=190641631&iu=/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

[Eric Lombrozo]

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

On Sunday, February 22, 2015, Eric Lombrozo  wrote:

> 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"  > 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" > > wrote:
>>
>>> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón  wrote:
>>> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik >> > 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=190641631&iu=/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=190641631&iu=/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

[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"  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"  wrote:
>
>> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón  wrote:
>> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik 
>> 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=190641631&iu=/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=190641631&iu=/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

[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"  wrote:

> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón  wrote:
> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik 
> 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=190641631&iu=/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=190641631&iu=/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

[Eric Lombrozo]

Ciphrex was using this convention well before BitPay...and BitPay's BIP32
implementation was at least partly taken from ours.

- Eric
On Jan 14, 2015 8:03 PM, "Andy Alness"  wrote:

> Doing same (BitPay convention) for our multisig support.
>
> On Wed, Jan 14, 2015 at 3:53 PM, Eric Lombrozo 
> wrote:
> > 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"  wrote:
> >>
> >>
> >> > On 20150114, at 09:39, devrandom  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
> >
>
>
>
> --
> Andy Alness
> Software Engineer
> Coinbase
> San Francisco, CA
>
--
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

[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"  wrote:

>
> > On 20150114, at 09:39, devrandom  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

[Eric Lombrozo]

I think everyone is pretty much following this standard now.

- Eric
On Jan 14, 2015 12:58 PM, "devrandom"  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

[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  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?

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

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

[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  wrote:

> On Wed, Mar 5, 2014 at 2:39 PM, Peter Todd  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=122218951&iu=/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=122218951&iu=/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

[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  wrote:

> On Wed, Mar 5, 2014 at 1:31 PM, Eric Lombrozo  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=122218951&iu=/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

[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  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=122218951&iu=/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=122218951&iu=/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

[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=126839071&iu=/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

[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  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  
> wrote:
> 
>> 
>> 
>> 
>> On 27 December 2013 19:08, Mike Belshe  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  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=84349831&iu=/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=84349831&iu=/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=84349831&iu=/4140/ostg.clktrk___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net

Re: [Bitcoin-development] Testnet block explorer

[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  wrote:

> 
> 
> 
> On 27 December 2013 19:08, Mike Belshe  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  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=84349831&iu=/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=84349831&iu=/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=84349831&iu=/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=84349831&iu=/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))

[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  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=58041391&iu=/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=58041391&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Multiwallet support

[Eric Lombrozo]

I like that idea. I'm close to having something working along those lines. 
Hopefully I'll be able to push something by tonight.

> 
> How about a rpc like "usewallet  "  that simply
> generalizes all the rpcs?
> 
> And instead of explicitly deactivating rpcs that don't make sense,
> simply have them return an error.  Or, for example,  sendtoaddress on
> a watching wallet should actually return an unsigned raw transaction
> and a wallet specific message that tells you where to find the private
> key.
> 
> I think it's desirable to not break compatibility but for this kind of
> feature compatibility should not get in the way of doing it right.


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

[Bitcoin-development] Multiwallet support

[Eric Lombrozo]

I started working on a new feature to allow for watch-only addresses in 
wallets. https://github.com/bitcoin/bitcoin/pull/2121

In order to integrate this feature nicely into bitcoin / bitcoin, it will be 
necessary to disable signing and privkey export operations for watch-only 
addresses. Since disabling these things for only some of the keys in a wallet 
but not others is an API nightmare and complicates CreateTransaction logic, I 
propose adding multiple wallet capabilities and specifying upon creation 
whether a wallet is a:

1)  full signing wallet
- importaddress is disabled.

2) watch-only wallet
- signing and privkey export operations are disabled.
- importprivkey only saves the associated address but not the private 
key. (behaves like importaddress )

In order to do the above, it will be necessary to add multiple wallet support. 
Anyhow, that was my initial motivation for multiple wallets - but obviously, 
there are a number of other reasons why people might want multiple wallet 
support.

--

Adding the ability to specify multiple wallets with associated names and 
passphrases in the config file should be fairly straightforward. However, 
exposing multiple wallets via RPC will be tricky as the existing RPC is not 
designed to support multiple wallets.

As to not break compatibility with the existing RPC calls, we can have a main 
wallet which is always used as the default wallet. If the user wants to use a 
different wallet, the name of the wallet would have to be specified in the 
call. Unfortunately, it doesn't look like we can use many of the existing RPC 
calls (sendfrom, sendmany,sendtoaddress, etc...) since they all have optional 
parameters already and it would be awkward to just tack on the wallet name 
parameter at the end. Also, walletpassphrase is problematic as it is not 
stateless. So it looks like we need a whole separate set of calls which require 
a wallet name and passphrase (if the wallet is encrypted).

For instance,
walletsendtoaddress 
[comment] [comment-to]

I welcome any proposals or suggestions as to how this should be done.


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

[Bitcoin-development] Zero-length scripts

[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

[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

[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

[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

[Bitcoin-development] Why are my posts being put in new threads?

[Eric Lombrozo]

I've made a couple recent posts that were intended for the Protocol
extensions thread but have been put in new threads. What part of the
email message is used to identify the thread to which it belongs? I
would have thought the subject, but apparently it isn't.

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Protocol extensions

[Eric Lombrozo]

Is it just me or does it seem inevitable that at some point supernodes
will emerge that other nodes trust to validate transactions for them?
Supernodes needn't even store the entire block chain and transaction
pool...it would be sufficient that they keep lists of IP addresses of
other trustworthy nodes and partition them into a hashspace.

Anonymous peers have no reputation to defend...but a trusted supernode
would, which could provide just enough incentive for the supernode to
do its best to ensure the nodes it vouches for are indeed legit. Of
course, unless the supernode is validating the entire block chain and
transaction pool itself, it could only assess the trustworthiness of
other nodes by performing random sampling.

Michael, I really like your ideas and the clarity you bring to the
issue. Regarding the potential attack vector you mention, would it be
possible to partition the hashspace to minimize the risk that an
attacker can manage to disproportionately gain control over a part of
the hashspace?

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Protocol extensions

[Eric Lombrozo]

There are other issues besides IP address anonymization that would
need to be addressed. I'm sure at least a good number of you have read
http://arxiv.org/abs/1107.4524 and have seen Dan Kaminsky's
slideshows.

i.e. all fund aggregations (transactions with multiple inputs using
different public keys) make it easy to associate all the public keys
to a single entity. Large movements of bitcoin to addresses that
haven't been seen before are often interesting events. Then you can
correlate transactions with trades on exchanges or with other data
sources for time and amount.

However, going back to what had been said earlier, the bitcoin
protocol itself is not really designed to address these issues. It is
designed with the goal of rapidly propagating transactions over a
network and getting a bunch of peers to be able to independently
verify that they occurred in a particular order and that the
signatures are valid.

The subject of how to anonymize cryptocurrencies is a separate one,
IMHO...and one which needs to address not only how to hide the
identity of those who relay transactions but also how to organize and
manipulate wallets as to thwart attempts at block chain analysis. And
these topics, although interesting in and of themselves, was not what
this thread was intended to address. This thread was intended to
address the issue of extending the protocol to allow for independently
running thin or specialized services that can all interface via the
bitcoin protocol without requiring one to step outside the protocol
with special gateway access.

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Protocol extensions

[Eric Lombrozo]

Hey, guys.

I haven't posted here before so I'll introduce myself. My name's Eric,
I've been developing cryptocurrency-related
software for several months now, I've implemented some libraries for
dealing with core bitcoin datastructures, made
some custom builds of bitcoind and interfaced it with a few apps I've written.

In doing so, I've come to appreciate just how little of the potential
for the bitcoin protocol is being exploited right now...
not only in terms of the script features but in terms of the potential
commands and node types that could exist.

For instance, the protocol spec at
https://en.bitcoin.it/wiki/Protocol_specification only has 16 commands
listed and
only one service type...despite having a full 12 bytes for a command
code and a full eight bytes for a services
type.

The fact that only one node service type is specified is probably due
to the fact that the satoshi client was written
to be a standalone monolithic app that took care of all the essential
needs for a network of peers.
i.e. block chain storage/management, transaction signing/verification,
key generation/wallet management, block mining, etc...
However, I think there's an urgent need for breaking up all these
different tasks into separate components that can run as independent
services on different types of devices.

One of the big issues I'm dealing with now pertains to block chain
storage. As of right now, it is implemented as sequential
disk files using Berkeley DB in the satoshi client. Then you have
other projects that have been using SQL tables, etc...
But I believe the direction this really needs to move towards is some
sort of distributed hash table...and the database queries
should be performed using the bitcoin protocol itself. Perhaps adding
a few more commands. As things stand right now,
the only way to query for transactions or blocks is by their hash. And
once a transaction gets incorporated into a block and
removed from the transaction pool, one can no longer query it by the
transaction hash without stepping outside the bitcoin protocol.
We need access to the disk file that stores the blocks whether it be
via Berkeley DB or SQL or whatever.

I propose an extension to the bitcoin protocol to provide methods for
performing more sophisticated queries, such as "Give me
an inventory of transactions involving this particular public key" or
"Give me an inventory all transactions in the last n blocks with
unredeemed outputs." This could be done by adding a few more commands.

Furthermore, I propose a new network services type for nodes that
serve as block chain/transaction pool storage.

Of couse, any peer that wishes to verify the integrity of the block
chain would still have to download at the very least
all the block headers...and to be completely sure, also all the blocks
themselves...and verify everything. But it would be
very nice to be able to run thin services that can rely on other
network peers to do this work. It is still possible to attain
a high level of confidence in the integrity by querying multiple peers
for similar objects and comparing. It is also possible
to run your own dedicated block chain storage servers which you trust.

There are other ideas I have for other types of services, too.

Anyhow, I'm just throwing this out there...if anyone's interested I'd
love to develop these ideas further and help put together some
specs.

-Eric Lombrozo

--
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development