Dear Paul,
> In point of fact, he is wrong, because nodes do the counting. When miners
> find a block, they can choose to move the counter up, down, or not at all.
> But nodes do the counting.
I may very well have confused who counts what, but for this discussion on
*theft* it's irrelevant, so
Well, 40 bytes reduction per input is excessive too :)
But 30 bytes reduction will do fine.
On Thu, Jul 13, 2017 at 12:10 AM, Sergio Demian Lerner <
sergio.d.ler...@gmail.com> wrote:
> Some responses..
>
>>
>> The proposal adds another gratuitous limit to the system: A maximum
>> transaction size
Some responses..
>
> The proposal adds another gratuitous limit to the system: A maximum
> transaction size where none existed before, yet this limit is almost
> certainly too small to prevent actual DOS attacks while it is also
> technically larger than any transaction that can be included today
I will repeat that Drivechain can sometimes be confusing because it is
different things to different people.
Here is my attempt to break it down into different modes:
[DC#0] -- Someone who does not upgrade their Bitcoin software (and is
running, say, 0.13). However, they experience the effects of
On Tue, Jul 11, 2017 at 11:17:24PM -0700, Dan Libby via bitcoin-dev wrote:
> At this time, I would like to have some of the more recent features, but
> without the possibility that my node will activate segwit, until I
> choose to.
I think that terminology isn't quite precise. I think your options
On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev
wrote:
> Hi!
>
> Up to now, I have purposefully been running bitcoin releases prior to
> 0.13.1 as a way to avoid the (possible) segwit activation, at least
> until such time as I personally am comfortable with it.
It is not simple to do
-- Forwarded message --
From: Rusty Russell
Date: Wed, Jul 12, 2017 at 6:27 PM
Subject: [Lightning-dev] Lightning Developers Biweekly Meeting Announce
To: lightning-...@lists.linuxfoundation.org
Hi all!
Every two weeks we've been running an informal Google Hangout
for im
Paul,
> The confusion below stems from his conflation of several different ideas.
I'm right here, are you having a conversation with me or are you on a stage
talking to an audience?
> FYI that document is nearly two years old, and although it is still
> overwhelmingly accurate, new optimizatio
Hi!
Up to now, I have purposefully been running bitcoin releases prior to
0.13.1 as a way to avoid the (possible) segwit activation, at least
until such time as I personally am comfortable with it.
At this time, I would like to have some of the more recent features, but
without the possibility th
The confusion below stems from his conflation of several different ideas.
I will try to explicitly clarify a distinction between several types of
user (or, "modes" of use if you prefer):
[DC#0] -- Someone who does not upgrade their Bitcoin software (and is
running, say, 0.13). However, they exper
In case anyone wants to do this, I added the CSidechainAddress class to the
mainchainBMM branch of the Drivechain project a long time ago. The only
purpose it serves right now is to show that sidechain deposit addresses can
start with a '4'. We could simply add the sha256 hash described by Paul to
I still think it may be more inefficient, in equilibrium. (In other
words, in the future steady state of Bitcoin that includes LN or
something LN-like).
Assume there are N sidechains.
In the coinbase version:
1. There is some single event, per N, that causes nodes to notice that a
new sidechain h
On 7/12/2017 4:50 AM, ZmnSCPxj wrote:
>
> >>In my scheme, if you read carefully through the pseudocode, a block
> list node is valid only if its block is valid.
> >
> >It seems this is a contradiction against the "blind" part of blind
> merge mining. How can a bitcoin blockchain node enforce this w
Paul,
I'm assuming it's OK with you that I pick up from where we left off in the
"Scaling Roadmap" thread [1], so as to be on-topic per your request. (For
others reading, part of my reply to the previous email in this thread is here
[2]).
For reference, I said:
> Isn't it different in the cas
That's a fair point, I confused anyone-can-spend with anyone-can-pay [1].
Isn't it different in the case of P2SH and SegWit, don't full nodes validate
the script?
In other words, miners don't have complete control over the coins, full nodes
keep a check on them.
At least that was my understand
You guys are both right that it is a different security model, with the
important distinction that it is opt-in. What I disagree with about what
you said is only that we are encouraging more risky behavior by adding
consensus rules via softfork. There are additional risks with
drivechains, but not
Are we just pulling numbers out of thin air now? https://p2sh.info/
BIP16 for example is widely used. It would be difficult to find a single
wallet that doesn't support BIP16 I have no idea what you are talking about.
On 07/12/2017 12:42 PM, Tao Effect via bitcoin-dev wrote:
> ...
> In the presen
> I think Paul has been pretty upfront about the risks of his model.
I think he has been rather misleading in his presentation of the risks.
He outlines them in a very technical manner, yes, but then goes on to promote
them to lay people as if they're no big deal, which is completely misleading.
Hi Greg,
The safest way to ensure everyone's protection to make sure *no one can do
anything*. Then we will ALL be safe ;).
>If so, please leave, you are compromising Bitcoin's security.
Ok, let's calm down.
>If I design a car that has a button that randomly causes the brakes to
give out if pre
Dear Chris,
> I think this is an unfair characterization. You have to opt into using
> drivechains.
I have heard this nonsense repeated countless times in order to justify
adopting Drivechain.
This is not how security works.
A child can "opt-in" to using a loaded gun, but is it a good idea to
Hi Greg,
>Here, you admit that the security of the sidechains allows miners to steal
bitcoins, something they cannot do currently.
If I put my coins in an anyone can spend output, a miner will take them.
They can do this today. I suggest you try it if you don't believe me :-).
You have to be more
Hi Russell/ZmnSCPxj,
I think you guys are right. The only problem I can see with it is
replaceability of the bribe transaction. If the 'Bribe' is the fee on the
transaction it isn't clear to me what the best way to replace/remove it is.
If we have the amount in the output (instead of the fee) we
On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
> I think anything less than 1 year after release of tested code by some
> implementation would be irresponsible for any har
Le 12/07/2017 à 03:06, Luke Dashjr via bitcoin-dev a écrit :
> Even with Core's support, many people would oppose the hardfork
> attempt, and it would fail.
Why with or without Core support are you sure that it will fail, what
can those that are opposing the hardfork attempt do (with or without
> Code to support 2x (the hard fork part of the proposal) has been out and
> tested for much longer than that.
Tested? Where?
However, the hardfork part may be out there for a long time but _is still
broken_.
/jonas
signature.asc
Description: Message signed with OpenPGP
_
On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
In any case, let me propose actual improvements to the OP_BRIBEVERIFY
> proposal:
>
> 1. Remove the necessity of coinbase commitments. The miner commits to
> the sidechain_id and h* in the t
On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
> I think anything less than 1 year after release of tested code by some
> implementation would be irresponsible for any hardfork, even a very
> simple one.
Good news!
Code to support 2x (the hard fork part of the proposal)
On Wednesday, 12 July 2017 03:22:59 CEST Karl Johan Alm via bitcoin-dev
wrote:
> Bitcoin development differs from Linux kernel development in a number
> of obvious ways, such as the fact Bitcoin is being "patched in
> flight".
I've heard this before and it doesn't make any sense to me. Just like
On Tuesday, 11 July 2017 23:11:38 CEST Gregory Maxwell via bitcoin-dev
wrote:
> I think it's great that people want to experiment with things like
> drivechains/sidechains and what not, but their security model is very
> distinct from Bitcoin's and, given the current highly centralized
> mining ec
Just a quick note in favor of an updated roadmap (some may object to that
label, but I think it's fine). When you and your friends are planning your
weekly movie outing, it's very helpful to have someone who knows the group,
knows what films are playing, checks people's preferences, mails around
p
>>In my scheme, if you read carefully through the pseudocode, a block list node
>>is valid only if its block is valid.
>
>It seems this is a contradiction against the "blind" part of blind merge
>mining. How can a bitcoin blockchain node enforce this without tracking the
>sidechain?
From:
https
Good morning mailinglist,
I am saddened at the lack of attention to this BIP proposal. I know that it is
not as interesting as the debates on where Bitcoin will go in the future and
what needs to be prepared for even greater mainstream adoption, but I think my
BIP proposal does have at least som
32 matches
Mail list logo
