, May 8, 2015 at 7:51 PM, Peter Todd p...@petertodd.org wrote:
On Fri, May 08, 2015 at 03:32:00PM +0300, Joel Joonatan Kaartinen wrote:
Matt,
It seems you missed my suggestion about basing the maximum block size on
the bitcoin days destroyed in transactions that are included in the
block
Matt,
It seems you missed my suggestion about basing the maximum block size on
the bitcoin days destroyed in transactions that are included in the block.
I think it has potential for both scaling as well as keeping up a constant
fee pressure. If tuned properly, it should both stop spamming and
Having observed the customer support nightmare it tends to cause for a
small exchange service when 100% full blocks happen, I've been thinking
that the limit really should be dynamic and respond to demand and the
amount of fees offered. It just doesn't feel right when it takes ages to
burn through
If the attacker has your desktop computer but not the mobile that's acting
as an independent second factor, how are you then supposed to be able to
tell you're not signing the correct transaction on the mobile? If the
address was replaced with the attacker's address, it'll look like
everything is
For script evaluation benchmarking, I don't think just a good
approximation of real-world traffic is enough. You really need to
benchmark the worst case scenarios, otherwise you could be creating a
DoS vulnerability.
- Joel
ke, 2012-10-03 kello 13:57 -0400, Ian Miers kirjoitti:
Script
I think the strong verification would go well if you add it along with an
optimization that avoids rechecking transactions that have already been
verified as valid. Any transactions it doesn't have to verify are from the
pool, of course :)
On Thu, May 24, 2012 at 7:33 PM, Jeff Garzik
Wouldn't it work to restrict the number of executions of OP_EVAL allowed
per transaction? That way it wouldn't allow for unlimited looping. If
there's too many OP_EVAL executions during the transaction evaluation,
just consider the transaction illegal. 3 would be enough for the
purposes people
It's propably best to create a separate p2p network for off-band
information like this. No need to involve the blockchain with it.
- Joel
On Wed, 2011-11-09 at 16:18 -0500, Gavin Andresen wrote:
One more thought on putting arbitrary stuff in the scriptSig:
Miners could decide to revolt and
On Tue, 2011-10-25 at 11:45 +0200, Jan Vornberger wrote:
1) Get something working reasonable fast to detect current green address
style transactions. It's fine if it is a little bit of a hack, as long as
it's safe, since I don't expect it to be merged with mainline anyway at
this point.
2)
Darn good question. If the protection fails, would it be better for it
to 'fail hard', leaving people complaining bitcoin won't stay
connected!
Or fail soft, so you at least have a couple of connections.
I think fail hard is better-- we'll immediately know about the
problem, and can fix
10 matches
Mail list logo
