On Wednesday, September 14, 2011 9:57:00 PM Gavin Andresen wrote:
> I'm looking for review of this pull request:
> https://github.com/bitcoin/bitcoin/pull/517
"Non-standard" transactions, or those with "insufficient" fees should not be
penalised. These are properly relay/miner policy decisions,
I'm looking for review of this pull request:
https://github.com/bitcoin/bitcoin/pull/517
The big idea: if a peer is sending you obviously wrong information,
punish it by maybe dropping your connection to it, and ban it's IP
address so it cannot immediately re-connect.
The probability of droppin
On Wednesday, September 14, 2011 4:09:00 PM Gregory Maxwell wrote:
> Though I generally agree with Luke that we should just fix the root
> cause even though it forks the chain.
I don't support this, unless all other chain-forking-needed changes are made
at the same time. I do point out that chang
On Wednesday, September 14, 2011 5:51 PM, "Gregory Maxwell"
wrote:
> General network health and user security _requires_ periodic upgrades
> in any case, and will for the foreseeable future. The whole notion
> that old versions will _stop working_ would be a pretty good thing at
> this point in b
On Wed, Sep 14, 2011 at 5:36 PM, Alex Waters wrote:
> On Wed, Sep 14, 2011 at 4:28 PM, Gavin Andresen
> wrote:
>
>> What do other people think? I think it is too high risk for too
>> little benefit and shouldn't be done until we have a really compelling
>> reason to introduce a forking change.
A better retarget strategy might be to use the real average time
between all of the blocks in the interval so that no blocks are
treated specially in the calculation. I agree that this is not
important enough to fork the chain over, though. An attacker would
have to maintain control for a *very* lo
On Wed, Sep 14, 2011 at 4:28 PM, Gavin Andresen wrote:
> What do other people think? I think it is too high risk for too
> little benefit and shouldn't be done until we have a really compelling
> reason to introduce a forking change.
Could we bundle this and potential future blockchain-splittin
> Perhaps better thing to do is to also delay the _forwarding_ of these
> blocks _and_ blocks that extend them, until extended one more time.
Excellent idea, that gets the incentives right.
RE: fixing the root cause with a forking change:
What do other people think? I think it is too high risk
On Wed, Sep 14, 2011 at 3:52 PM, Aidan Thornton wrote:
> Of course, if only a small percentage of mining power adopts this
> scheme, everyone that does so will presumably be harming themselves by
> doing so since they're essentially increasing the odds that the next
> block they mine will become i
On Wed, Sep 14, 2011 at 3:45 PM, Gavin Andresen wrote:
> Modify the getwork code to build on the second-from-tip block if the
> first-on-tip block is on the discouraged list.
>
> Assuming a majority of pools/miners adopt the "discourage blocks with
> stale timestamps" rule, that should squash any
Am I the only one to think putting pools at a disadvantage is actually
desirable?
Back when pools started to appear we all had huge reservations about putting
so much control into the hands of a few pool operators, but nowadays it
seems that having pool operators control a vast majority of the
comp
On Wednesday, September 14, 2011 10:45:36 AM Gavin Andresen wrote:
> The block timestamp rules currently give HOURS of wiggle-room for
> timestamps. We can't change those rules without risking a chain split.
And those hours of wiggle-room are not enough to cause a problem.
The problem only comes i
> But that doesn't solve the whole problem, because the block timestamp
> checking is based on the assumption that the node is looking at the bitcoin
> clock rather than the, ahem, real clock. If we change the idea of network
> time to NTP, we will then need to write (and test!) new block timestam
13 matches
Mail list logo
