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
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 new
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,
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
[...]
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 getaddr.
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
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
On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak btcd...@gmail.com 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
On Mon, Dec 15, 2014 at 12:47 PM, Peter Todd p...@petertodd.org 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
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
On Mon, Dec 15, 2014 at 10:20 AM, Jeff Garzik jgar...@bitpay.com wrote:
On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak btcd...@gmail.com 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
On Mon, Dec 15, 2014 at 7:47 AM, Peter Todd p...@petertodd.org 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,
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
On Mon, Dec 15, 2014 at 2:35 PM, Jeff Garzik jgar...@bitpay.com wrote:
On Mon, Dec 15, 2014 at 1:42 PM, Cory Fields li...@coryfields.com wrote:
That's exactly what happened during the modularization process, with
the exception that the code movement and refactors happened in
parallel rather
14 matches
Mail list logo
