Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-07 Thread Gavin Andresen
On Sat, Oct 4, 2014 at 8:58 AM, Mike Hearn m...@plan99.net wrote:


 Meanwhile, what I said *is* correct. New version numbers result in only
 a log print. Being hard forked off results in both log prints *and* the
 -alertnotify being run:


That is easy to change; I'll submit a pull request. It is a good idea to
get an -alertnotify sooner rather than later for EITHER a hard fork or a
soft-fork. Better to be told you have to upgrade while the block.version is
on its way to being a super-majority than after you are either hard-forked
off the main chain (or soft-forked).

I don't have any opinion on the hard- versus soft- fork debate. I think
either can work.

-- 
--
Gavin Andresen
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-07 Thread Mike Hearn

 That is easy to change; I'll submit a pull request.


That's certainly a useful improvement. It won't help the existing userbase
though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major
release. If there's going to be an intermediate release (6 months?) which
lays the groundwork for future rule changes, it helps more.

It would be good if getblocktemplate was updated at the same time to serve
errors if the fork warning is active. I'd hope miners have some way to
automatically handle IBD/getting forked off the chain, but I guess some
(newer) pools might not, and refusing to serve work should be the safest
option that shuts them down.

I don't have any opinion on the hard- versus soft- fork debate. I think
 either can work.


P2SH was a soft fork and the sky did not fall, but miners did lose money
and waste electricity mining blocks on the wrong side of the chain:

https://bitcointalk.org/index.php?topic=75294.0

Presumably they didn't notice for longer because it looked like a run of
unusually bad orphaning luck. It seems safer to have a clean fork, with
alerts telling people during the lockin period before new rule enforcement
starts (and possibly automated termination if there's no upgrade by the
flag day?). Miners who ignore it would still risk losing money, but
merchants who wait for a block at least would not be at risk.

One open question is how can you actually trigger a hard fork? Coinbase
scriptSigs are not executed, so putting some ignored but failing opcode
sequence there wouldn't work. One possibility would be to have a special
invalid tx in the block that marks the start of new rule enforcement. New
nodes would know to ignore it. But this risks corrupting block explorers.
Alternatively the coinbase outpoint structure could have its hash set to 1
instead of 0.
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Partial wallet rescan

2014-10-07 Thread Jérémie Dubois-Lacoste
Hi all,

Before starting to implement a patch for a specific need, I would like
to be sure that it was not written already and available somewhere.
This list is probably my best chance.

I would like to add an optional parameter block_heigh to -rescan,
from which the rescan would then start. When performing the wallet
rescan, everything before the block number block_heigh would be
ignored.
Thus, it would do pretty much the same thing as the wallet birthday
mechanism (which relies on nTimeFirstKey), the difference being that
the point in time where to start would be *explicitly* given by the
user, at launch time, on the command line. Another possiblity is to
provide as parameter a time stamp instead of a block height; the
interesting part for me is that anyway that information is explicitly
provided by the user.

Regards,

Jeremie

--
Jeremie Dubois-Lacoste, PhD.
Belgian Bitcoin Association, Director.
Université Libre de Bruxelles, Post-Doctoral Researcher.

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-07 Thread Sergio Lerner


On 06/10/2014 08:43 p.m., Tom Harding wrote:
 On 10/5/2014 4:00 PM, Sergio Lerner wrote:
 If everyone acts rationally in his own interest, then the best choice
 for the remaining miners is to try to mine a competing block at the
 same height n including the high-fee transaction, to collect the fee
 for themselves.

 Sergio --

 Just some thoughts on your interesting problem.


 Since everybody but M10 is on equal footing, I would expect M10 to
 have some fixed advantage depending on assumptions, and the bigger the
 advantage, the shorter the freeze time.


Yes, that's how simulation works. The problem is that the existence of
high-fee delays the decision to switch to M10. Since the network is
moving slower (because of fragmentation) the effect of the high-fee is
twofold: it delays the convergence because it promotes selfishness and
it delays convergence because it promotes fragmentation.

During that time window where the network is frozen, any other high-fee
transaction only makes things worse.  This is a very rare example where
a well distributed network (100 miners having 1% each) is much much
worse than 3 miners having 33% each.

Using the my previous terminology, automatic fee-sharing (ORBS) is a
solution to the freeze problem (FRONT) but opens the windows to
CHAKIDO double-spending. and CHAKIDO double-spending is a much worse
problem than FRONT.
But as Tamas pointed out, sooner or later someone will implement
something like ORBS, get over the critical mass of miner adoption, and
then the CHAKIDO problem will be inevitable.

The only clean solution to this problem is the DECOR+ protocol, which
shares block-rewards by including uncles (as GHOST does) and splitting
the reward between all miners at the same height until coinbase maturity
is over. This way the best choice is always cooperative.

PS: Using so many acronyms makes arguments much more concise, but
suggest we should have all the attack terminology described in a single
Bitcoin Security Wiki...














--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-07 Thread Gregory Maxwell
On Tue, Oct 7, 2014 at 7:04 PM, Sergio Lerner sergioler...@certimix.com wrote:
 Using the my previous terminology, automatic fee-sharing (ORBS) is a
 solution to the freeze problem (FRONT) but opens the windows to
 CHAKIDO double-spending. and CHAKIDO double-spending is a much worse
 problem than FRONT.

I'm not following this. Perhaps I'm getting lost in terminology here.

It's already to provide double spending bounties to greedy-rational
miners, via a simple approach that has been known since at least early
in 2011.I pay someone then create a later fraudulent doublespend
which is nlocked at the height the original payment occurred, paying
large fees. Then I spend the output of the fraudulent spend nlocked
one block higher, and spend the output of that one again, nlocked one
block higher, and so on... each step paying fees.

A hypothetical purely greedy miner which considers all sequences of
acceptable forks and transactions would see that they have higher
expected returns assisting the theft (assuming the honest party
doesn't fight back by also adopting a similar strategy), at least if
the population of greedy miners is large relative to altruistic ones.

I don't see how miners being able to roll forward fees makes anything
worse, since the transactions themselves can also roll forward fees.

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-07 Thread Sergio Lerner

On 07/10/2014 04:16 p.m., Gregory Maxwell wrote:
 Then I spend the output of the fraudulent spend nlocked
 one block higher, and spend the output of that one again, nlocked one
 block higher, and so on... each step paying fees.
Yes, you're right. I didn't consider that case. But the problem is that
this is not automatic. Currently there is a clear division between
miners how will not take the kickback (irrrational) and miners who will
(rational).
If somebody modifies the bitcoind to make this choice automatic, then
DECOR+ is the only solution I know about to avoid people doing anonymous
double-spends (with chained kickbacks, as you mention).
The  locktime on normal transactions you proposed does not solve the
problem, just diminishes it in a constant value (which currently is very
low)




--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-07 Thread Tom Harding
On 10/7/2014 8:50 AM, Gavin Andresen wrote:

 I don't have any opinion on the hard- versus soft- fork debate. I 
 think either can work.


Opinion: if a soft work works, it should be preferred, if for no other 
reason than once a hard-fork is planned, the discussion begins about 
what else to throw in.  To minimize the frequency of hard-forks, the 
time for that is when the change being considered actually requires one.

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development