On Thu, Jul 18, 2013 at 07:13:53AM -0400, Peter Todd wrote:
> Note that with OP_DEPTH we can remove the small chance of the payee
> vanishing and putting the funds in limbo:
>
> OP_DEPTH OP_LESSTHAN
> IF 2 PK1 PK2 CHECKMULTISIG
> ELSE PK1 CHECKSIG
> ENDIF
>
> Though that shows ho
On Thu, Jul 18, 2013 at 08:53:55AM -0400, Jeff Garzik wrote:
> On Thu, Jul 18, 2013 at 7:13 AM, Peter Todd wrote:
> > Note that with OP_DEPTH we can remove the small chance of the payee
> > vanishing and putting the funds in limbo:
>
> What are the costs, benefits, and risks associated with scrip
On Thu, Jul 18, 2013 at 7:13 AM, Peter Todd wrote:
> Note that with OP_DEPTH we can remove the small chance of the payee
> vanishing and putting the funds in limbo:
What are the costs, benefits, and risks associated with scripts no
longer being stateless, as OP_DEPTH would seem to introduce?
--
On Fri, Apr 19, 2013 at 06:48:11PM -0700, Jeremy Spilman wrote:
> 0. User and AP negotiate how much to escrow, who pays the fees, and how
> far in the future nLockTime will be set (how long user’s funds will be tied
> if AP doesn’t close the channel)
>
> 1. User creates an unsigned TX1 with 1 or
Sorry I don't have time to reply more in depth, but I wanted to say to
Jeremy (especially) and Peter I'm very impressed to see such a good
design be created so fast that does not depend on replacement at all.
This is a great example of how often the right approach to a problem
is to accept that the
Yes, this is an excellent observation. Thanks Jeremy and Peter. It's much
less general than full blown tx replacement+lock times, but for the case of
a channel between two people that only ever increases in one direction, it
can work. Thanks. I will try implementing this myself for testing on the
m
I was discussing this with petertodd a couple days ago and we were thinking
the sequence I sent yesterday was usable today. I tried getting it to work
on test-net but the final transaction closing the channel was not being
accepted into the mempool beacause "ERROR: CTxMemPool::accept() : inputs
al
I’m not sure I followed John’s proposal fully, why would a user sign TX1
committing funds to the MULTISIG they may never get back? I also don’t see
the problem with getting a signed TX2 back from the AP before releasing
TX1... see the sequence below. But more importantly, we only need exactly
one
On Fri, Apr 19, 2013 at 12:38 AM, John Dillon
wrote:
> I understand that Gavin has spent effort on security efforts against
> small-scale attackers. It's the fact that he is so dismissive of the
> threat that large attackers play that is what bothers me. But if I am
> being divisive I understand.
I understand that Gavin has spent effort on security efforts against
small-scale attackers. It's the fact that he is so dismissive of the
threat that large attackers play that is what bothers me. But if I am
being divisive I understand.
I posted a clarification of what the reward is for exactly on
> sure it's worth doing, at least immediately. Weakening the non-final ==
>>
> non-standard test to give a window of, say, 3 blocks, would be fine I
>> think.
>>
>
> Sure. I think Gavin wants some kind of wider memory pool limiter policy
> which would encompass such a thing already.
>
Yes.
I don'
Indeed, as I mentioned in my first mail, nodes can be told how much
bandwidth they're allowed to use and then prioritize within that, so I
don't see any way convergence can fail. And regardless, I used 10mbit for
the calculations, that isn't exactly unlimited. My home internet connection
is better
On Thu, Apr 18, 2013 at 11:28:48AM +0200, Mike Hearn wrote:
> Let's include bandwidth. Say the contract (multi-sig input + the outputs)
> is about 700 bytes. 43,200 transactions is then about 29 megabytes of data.
> On a fairly normal 10mbit connection that would take about 23 seconds to
> transfer
> ...and actually, that's not a problem if the defender is online, because
> they can just broadcast the highest sequence numbered tx, which blocks
> further broadcasts by the attacker.
Good point - transactions can be ordered by highest version seen before
they're signature checked. Even without
On Thu, Apr 18, 2013 at 11:28 AM, Mike Hearn wrote:
> With the sipaspeed patches it seems ECDSA can be processed on modern cores
> at something like 20,000 signatures per second. So it'd take a bit over 4
> seconds to process all of them (cpu time).
>
Sorry brainfart, s/cores/cpus/. I think the
> An attack still shuts down useful tx replacement though. For instance in
> the adjusting payments example an attacker sets up a legit adjusting
> payment channel, does a bunch of adjustments, and then launches their
> attack. They broadcast enough adjustments that their adjustment session
> looks
On Thu, Apr 18, 2013 at 05:04:44AM -0400, Peter Todd wrote:
> An attack still shuts down useful tx replacement though. For instance in
> the adjusting payments example an attacker sets up a legit adjusting
> payment channel, does a bunch of adjustments, and then launches their
> attack. They broadc
On Thu, Apr 18, 2013 at 10:32:24AM +0200, Mike Hearn wrote:
> RE: shutting down services dependent on replacement. No, good users of
> replacement would still end up taking priority over the constantly churning
> DoS replacements. The most you can shut down is one contract. Obviously, if
> there's
When did I say DoS was unimportant? I just wrote a giant email explaining
how it can be resolved.
I think it's worth pointing out that Bitcoin was launched with no DoS
protection at all, and it's still here. There are still obvious DoS bugs
being fixed with every release. So yes, it's important to
On Thu, Apr 18, 2013 at 06:07:23AM +, John Dillon wrote:
> Gavin do you actually agree with Mike on this stuff like he implies?
> Because if you do, I think people should know. Myself I wouldn't want
> to be contributing to your salary as a foundation member if you don't
> take Bitcoin security
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 17, 2013 at 9:48 AM, Mike Hearn wrote:
> So it'd be nice if this ended up not being necessary. Experience indicates
> that rational miners typically don't pursue a short-termist
> profit-at-any-cost agenda - free transactions have always
One of the big topics of recent past on IRC is "malleability" of
transactions: to what extent can someone /else /change your signed
transaction without affecting its validity? In the past I used to
consider this just annoying, but not so malicious. But in terms of HFT,
it sounds like malicious b
When this system was first being discussed, Gavin was concerned that miner
incentives were to ignore replacements because it meant extra work and the
replacement might have equal or lower fees than before (or indeed, no
fees). He proposed two solutions: one is to progressively raise the fee on
each
> Or are you talking about some sort of new decentralized high frequency
> trading system that is self-matching and self-clearing? (I'd be very
> interested in hearing more if this is the case).
>
I'm using the term "high frequency trading" because Satoshi did. Like the
way he used the word "contr
Post tge malicious miners and other bits so we can evaluate the system as a
whole.
Mike Hearn wrote:
>This was previously discussed on the forums a bunch of times, but in
>particular here:
>
> https://bitcointalk.org/index.php?topic=91732.0
>
>BTW, I don't think all this has to be solved to r
25 matches
Mail list logo
