enario 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
> 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:
>>
> 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
>
&
disruption to the
network.
- Eric Lombrozo
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development
> 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, Jor
> 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
> 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
>>>
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 Lombr
> 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
>> com
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
> --
&g
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 ins
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 w
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
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
e 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
--
he 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 s
mething 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
>
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
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
Descriptio
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
> 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
> 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
> 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 fac
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 Jun
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 - t
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:
>
&g
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,
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
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 a
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 ha
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
tps://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 sc
> 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 distract
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 b
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
> >poss
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 Sund
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 motiva
ly 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
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 a
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
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
n 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. Th
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
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
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 fairl
gning, 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 secp256k
tween 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
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
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.
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
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 th
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 d
ff990dae35,
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 supp
t 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 fo
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
hese 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 fo
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.
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 n
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 key
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
60 matches
Mail list logo
