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
On Thu, Jul 18, 2013 at 7:13 AM, Peter Todd p...@petertodd.org 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
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
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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 17, 2013 at 9:48 AM, Mike Hearn m...@plan99.net 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
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
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 no
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 broadcast
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 11:28 AM, Mike Hearn m...@plan99.net 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/.
...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: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.
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
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't want to
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 Fri, Apr 19, 2013 at 12:38 AM, John Dillon
john.dillon...@googlemail.com 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
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 contract it
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
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 re-activate replacement on
testnet. It's useful for people to be able to develop apps that use this
feature,
21 matches
Mail list logo
