On Mon, Dec 15, 2014 at 2:35 PM, Jeff Garzik wrote:
> On Mon, Dec 15, 2014 at 1:42 PM, Cory Fields wrote:
>>
>> That's exactly what happened during the modularization process, with
>> the exception that the code movement and refactors happened in
>> parallel rather than in series. But they _were_
On Mon, Dec 15, 2014 at 1:47 PM, Peter Todd wrote:
> BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a few
> days ago and found a fairly large design change that makes merging it
> currently
> impossible. Pull-req #4890², specifically commit c7829ea7, changed the
> EvalSc
If code movement is not compressed into a tight time window, code movement
becomes a constant stream during development. A constant stream of code
movement is a constant stream of patch breakage, for any patch or project
not yet in-tree. The result is to increase the work and cost on any
contribu
On Mon, Dec 15, 2014 at 7:35 PM, Jeff Garzik wrote:
>
> At a macro level, that cycle was repeated many times, leading to the
> opposite end result: a lot of tiny movement/refactor/movement/refactor
> producing the review and patch annoyances described.
>
> It produces a blizzard of new files and
On Mon, Dec 15, 2014 at 1:42 PM, Cory Fields wrote:
> That's exactly what happened during the modularization process, with
> the exception that the code movement and refactors happened in
> parallel rather than in series. But they _were_ done in separate
> logical chunks for the sake of easier re
On Mon, Dec 15, 2014 at 7:47 AM, Peter Todd wrote:
> BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a few
> days ago and found a fairly large design change that makes merging it
> currently
> impossible. Pull-req #4890², specifically commit c7829ea7, changed the
> EvalScr
On Mon, Dec 15, 2014 at 10:20 AM, Jeff Garzik wrote:
> On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak wrote:
>>
>> We all want to see more modular code, but the first steps should just be
>> to relocate blocks of code so everything is more logically organised in
>> smaller files (especially for consen
> While it would be nice to have a library encapsulating the consensus code,
> this
> shouldn't come at the cost of safety, especially when the actual users of that
> library or their needs is still uncertain.
While I agree that it shouldn't come at unreasonable risk, my whole
reason for prioriti
On Mon, Dec 15, 2014 at 12:47 PM, Peter Todd wrote:
[snip]
> Pull-req #4890², specifically commit c7829ea7, changed the
This change was authored more than three months ago and merged more
than two months ago.
[And also, AFAICT, prior to you authoring BIP65]
I didn't participate in that pull-req,
On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak wrote:
> We all want to see more modular code, but the first steps should just be
> to relocate blocks of code so everything is more logically organised in
> smaller files (especially for consensus critical code). Refactoring should
> come in a second wav
This is a pretty good example about refactoring discipline as well as
premature/over optimisation.
We all want to see more modular code, but the first steps should just be to
relocate blocks of code so everything is more logically organised in
smaller files (especially for consensus critical code)
> The goal is to have an opportunity cost to breaking the rules.
>
> Proof of Burn is a real cost for following the rules.
>
For every participant who could try to decide about the adequateness
of the cost, no direct effect comes from the difference between Proof
of Burn, and approaches which keep
[...]
> > I'm confused by this, I run quite a few nodes exclusively on tor and
> > chart their connectivity and have seen no such connection dropping
> > behaviour.
>
> In my experience the problem has always been getting bootstrapped.
> Most nodes hardly give any hidden service nodes in their geta
Peter,
Thanks for the research, I am glad that the idea, that proof-of-burn can
“transfer" proof-of-work
was discussed earlier, as those discussions give some attack vectors that I can
reevaluate in
a new context, that is side chains.
I think that the lottery component I suggested, makes it
BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a few
days ago and found a fairly large design change that makes merging it currently
impossible. Pull-req #4890², specifically commit c7829ea7, changed the
EvalScript() function to take an abstract SignatureChecker object, rem
On Mon, Dec 15, 2014 at 11:21:01AM +0100, Tamas Blummer wrote:
> Burn mining side chains might be one of the foundation ideas for that
> ecosystem, enabling permission-less merge mining for
> anyone with interest in a side chain.
>
> I am puzzled by the lack of feedback on the idea.
It's not a n
Burn mining side chains might be one of the foundation ideas for that
ecosystem, enabling permission-less merge mining for
anyone with interest in a side chain.
I am puzzled by the lack of feedback on the idea.
Tamas Blummer
Bits of Proof
signature.asc
Description: Message signed with OpenPGP
17 matches
Mail list logo
