-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Due to the previous post on this subject
( http://is.gd/x6g5q5 ) having fractured links
please see the following, with working implementation
(in BCN) shown at: http://abis.io
This is intended to be implemented in different currencies, and so far
h
As per request of Luke-jr I'm sending a copy of my post on reddit
https://www.reddit.com/r/Bitcoin/comments/3nh0s4/bitcoin_dev_irc_meeting_in_laymans_terms_or_an/
to the mailing list.
This was intended to be a simple explanation of the weekly dev meeting for
people to understand what you guys are
Putting aside stupid arguments about who is older or who starting using the
term SPV wallet first, let me try and make a better suggestion than what's
in the BIP. How about the following:
A new flag is introduced to Core, --scriptchecks=[all,standardonly,none].
The default is all. When set to "sta
- It is true that hard forks produce a much cleaner outcome, in terms of
well defined behavior across the entire network.
- Replacing an opcode should not result in undefined behavior. The
non-upgraded behavior is defined and deterministic.
- IsStandard remains an assistant. Miners may mine non
Well, let's agree to disagree on these two things:
- I define "working" for a full node as verifying everything; if a node
starts skipping bits then I'd say it's not really "working" according to
its original design goals
- Saying the pre-fork behaviour is defined and deterministic is true, but
o
Let’s do this.
On 04/10/15 18:24, Thomas Kerin wrote:
> Regards amending BIP45 - BIP's are not amended after the fact, however
> bad it may be
> in retrospect. It might be best to write a BIP specifying a
> "pseudorandom & deterministic
> path generation for HD/multi-signature accounts"
signatu
On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Well, let's agree to disagree on these two things:
>
> - I define "working" for a full node as verifying everything; if a node
starts skipping bits then I'd say it's not really "working" accordi
It will get correct results about :
- the existence every block
- the existence of every transaction
It will get incorrect results :
- about the *nature* of some transactions
- and therefore, about the balances of some wallets.
I fully agree with Mike here.
Le lun. 5 oct. 2015 à 14:04, Jorge Tim
Hi Jorge,
I'm glad we seem to be reaching agreement that hard forks aren't so bad
really and can even have advantages. It seems the remaining area of
disagreement is this rollout specifically.
> a non-upgraded full node and an upgraded full will converge on what they
> see: "the most-work valid c
On Oct 5, 2015 2:08 PM, "Clément Elbaz" wrote:
>
> It will get correct results about :
> - the existence every block
> - the existence of every transaction
>
> It will get incorrect results :
> - about the nature of some transactions
Given the assumptions above, only of transactions without enoug
When I talk about multisig account I mean an arrangement among a set of
cosigners to be signatories of multi-signature transactions requiring a
set number of signatures, as specified in BIP-45.
Example:
Juan: xpub123...
Pedro: xpub456...
José: xpub789...
They all agree to create a 2-of-3 multisi
I fail to see how the number of confirmations has anything to do with it.
With a non-upgraded Bitcoin software during a soft fork, you get the same
blocks as everyone else, and you get the same confirmed transactions as
everyone else. So you do have the exact same "writings" as everyone else to
ca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Perhaps Pedro wants to also participate in a 2-of-2 cosigning
> arrangement with a merchant that will deliver a laptop to him, so
> Pedro provides this merchant with the same extended public key
> derived from path m/45', and the merchant provides
"Consensus" it's a term we use for consensus critical code and we
refer to different machines (potentially with different software)
validating in exactly the same way.
I think also using the term for people agreeing on what those
consensus rules is confusing, so in BIP99 I used the term
"uncontrove
On Fri, Oct 2, 2015 at 4:12 AM, GC via bitcoin-dev
wrote:
> Or, you know, enter some discussions on what exactly are the issues that SPV
> clients face during soft forks and see if anything can be done (on all
> sides) to mitigate the risks.
This has already been discussed. The recommended risk m
On Mon, Oct 5, 2015 at 2:10 PM, Mike Hearn wrote:
> Hi Jorge,
>
> I'm glad we seem to be reaching agreement that hard forks aren't so bad
> really and can even have advantages. It seems the remaining area of
> disagreement is this rollout specifically.
>>
>> a non-upgraded full node and an upgrade
On Mon, Oct 5, 2015 at 2:29 PM, Clément Elbaz wrote:
> The problem is that some transactions that are meaningless to you are
> actually meaningful to people using an upgraded Bitcoin software.
>
> Therefore during a softfork, while you can not miss the existence of a
> transaction, you can miss it
Some of the people on this mailing list are blindly discussing the
technicalities of a soft/hard fork without realizing that is not Mike's
main intention. At least I perceive (and maybe others too) something else
is happening.
Let me try to clarify: the discussion has nothing to do with technical
>I just think Mike Hearn has won this battle.
Unless the Core camp isn't concerned with credibility because they see XT as a
disruptive attack.
So it's very easy to justify banning a single individual in the name of
"restoring peace and order". We've already seen such suggestion.
Peter R was b
>
> As Greg explained to you repeatedly, a softfork won't cause a
> non-upgraded full node to start accepting blocks that create more
> subsidy than is valid.
>
It was an example. Adam Back's extension blocks proposal would, in fact,
allow for a soft forking change that creates more subsidy than i
On Monday, October 05, 2015 3:56:33 PM Sergio Demian Lerner via bitcoin-dev
wrote:
> Some of the people on this mailing list are blindly discussing the
> technicalities of a soft/hard fork without realizing that is not Mike's
> main intention. At least I perceive (and maybe others too) something e
Hey Sergio,
To clarify: my *single* objection is that CLTV should be a hard fork. I
haven't been raising never-ending technical objections, there's only one.
I *have* been answering all the various reasons being brought up why I'm
wrong and soft forks are awesome and there do seem to be a li
On 10/5/2015 12:56 PM, Mike Hearn via bitcoin-dev wrote:
>
> As everyone in the Bitcoin community has been clearly told that
> controversial changes to the consensus rules must not happen, it's
> clear that CLTV cannot happen in its current form.
___
bit
You are absolutely right and this is something I have often unsuccessfully
tried to explain as "disruption strategies". The problem is that most
people in the technical community assume good faith at all times, which
plays right into the frame required for disruption.
However, I would like to chal
On Monday 5. October 2015 18.03.05 Btc Drak via bitcoin-dev wrote:
> However, I would like to challenge your assumption of point 1 that that by
> Mike making a rabble, it somehow makes CLTV deployment controversial. His
> arguments have been refuted.
Unsuccessfully.
> Simply making a noise does
Dear Bitcoin Development Community:
I would like to share my opinion that Mike is correct regarding the soft fork
versus hard fork debate. I agree that CLTV should be done with a hard fork for
the reasons that Mike has discussed several times in the past (mainly that a
hard forks requires activ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
First, this only makes reference to hard forks not to soft forks. This
is very important because we are trying to apply a hard fork
requirement to a soft fork procedure which obviously won't work.
Your statement that 'all objections coming f
On Mon, Oct 5, 2015 at 5:56 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> CLTV deployment is clearly controversial. Many developers other than me
> have noted that hard forks are cleaner, and have other desirable
> properties. I'm not the only one who sees a big
On Mon, Oct 5, 2015 at 6:26 PM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> History has shown that for many decision making processes this doesn't
> work,
> and this argument has been made to Core.
> Until today this was essentially a rule that hurt the things that
>Each implementation could have its own governance model
>and design objectives and use techniques like BIP101’s 750/1000
>signalling mechanism to activate changes that may be desirable to
>the community.
I was shushed here 3 months ago for the same suggestion :)
http://lists.linuxfoundation.o
On Mon, Oct 5, 2015 at 5:26 PM, Tom Zander via bitcoin-dev
wrote:
> On Monday 5. October 2015 18.03.05 Btc Drak via bitcoin-dev wrote:
>> However, I would like to challenge your assumption of point 1 that that by
>> Mike making a rabble, it somehow makes CLTV deployment controversial. His
>> argum
On Mon, Oct 5, 2015 at 9:18 AM, Jean-Pierre Rupp wrote:
>
> Perhaps Pedro wants to also participate in a 2-of-2 cosigning
> arrangement with a merchant that will deliver a laptop to him, so Pedro
> provides this merchant with the same extended public key derived from
> path m/45', and the merchant
On Mon, Oct 5, 2015 at 3:56 PM, Sergio Demian Lerner via bitcoin-dev
wrote:
> 1) ignores him, which is against the established criteria that all technical
> objections coming from anyone must be addressed until that person agrees, so
> that a change can be uncontroversial. If the group moves forwa
On Monday 5. October 2015 18.04.48 Gregory Maxwell wrote:
> > Unsuccessfully.
>
> I think rather successfully.
Arguing that BIP66 rollout was a full success is in the same park of
"successful" ?
Where for weeks people were told not to trust the longest chain until it was
30 blocks.
Lets put tha
I'd like to propose updates to the new policy limits on unconfirmed
transaction chains.
The existing limits in master and scheduled for release in 0.12 are:
Ancestor packages = 100 txs and 900kb total size
Descendant packages = 1000 txs and 2500kb total size
Before 0.12 is released I would like t
For soft forks, consensus is required. In fact, we (today) have miners who
individually choose to mine blocks that are completely empty, with no known
input from (or communication with) the outside world. This is a consensus
process. Users can switch back and forth all they like, and this only
happ
What does "package" mean here?
When you say 25 txs, does that mean maximum linked chain depth, or total
number of dependent transactions regardless of chain depth?
Thanks,
-Danny
On Mon, Oct 5, 2015 at 11:45 AM, Alex Morcos via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I'd
On Monday 5. October 2015 20.33.04 s7r via bitcoin-dev wrote:
> For example, I don't see this controversial nor a violation of the BIP
> requirements. Mike had some fair objections, they were explained by
> gmaxwell and Jorge, everybody understood. The explanation is clear,
> with plausible practic
Gregory,
you are good at language and its easy to write eloquent words.
Looking at this little dialog, for instance;
On Mon, Oct 5, 2015 at 3:56 PM, Sergio Demian Lerner wrote:
> > 1) ignores him, which is against the established criteria that all
> > technical objections coming from anyone must
Sure,
You always have these alternatives, but the problem is that it starts to
become harder to restore your wallet from the initial mnemonic if
something goes wrong.
Say you lose all your wallet information except for your mnemonic,
extended public keys from all people you established multi-sign
Even someone trying to disrupt the process and nothing
else can help us learn by acting as an adversary that causes us to
extend our minds and understanding.
Interesting use of terms for a decentralized system. Can these terms be
defined?
"the process"
"us" (is there also a "them"?)
Russ
On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
wrote:
> It is an eloquent change, but not really the topic we were discussing. It also
> makes you attack Mike (calling him out as having a strawman) without basis.
> For the second time in this thread.
> I would suggest arguing on the to
Yes, total number of dependent transactions regardless of chain depth.
A descendant package means all the transactions that can not be included in
a block before the transaction in question.
An ancestor package means all the transactions that are required to be
included in a block before the tran
It's pretty clear Mike has turned into concern troll and bully. He insults
people, mischaracterizes others, quibbles over words and definitions and
has stated numerous times in other forums he has no interest in building
consensus changes he doesn't agree with himself.
He's lost his integrity and
On 10/5/2015 4:05 PM, Steven Pine via bitcoin-dev wrote:
It's pretty clear Mike has turned into concern troll and bully.
"troll" and, even worse, "concern troll" are terms generally used by
teenagers on places like Reddit to complain about someone who doesn't
agree with them. It is not rally
While this isn't really the place to discuss it, I respectfully disagree. Mike
appears to be making a point concerning Bitcoin protocol authorship and on the
perceived value of soft-forks. It doesn't look like simple trolling to me. Mike
and Gregory are both extremely intelligent and well-versed
On Monday 5. October 2015 19.41.30 Gregory Maxwell wrote:
> On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
>
> wrote:
> > It is an eloquent change, but not really the topic we were discussing. It
> > also makes you attack Mike (calling him out as having a strawman) without
> > basis.
I prefer the hard fork because the complexity introduced by soft forks
scares me.
At
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011309.html
Gregory wrote: "Security requires a bit of vigilance, inherently." and
[A non-upgraded miner will end up] "*> producing invalid blo
On Mon, Oct 5, 2015 at 8:35 PM, Tom Zander via bitcoin-dev
wrote:
> Fortunately I can say that while we certainly value your opinion, when peoples
> opinions are hard to read, as you indicated they can be, we should look at
> their actions. The group has followed the consensus rule quite rigorousl
On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote:
> (In this case, I don't even believe we have any regulator
> contributors that disagree).
Regular contributor?
Please explain how for a fork in the protocol should you only listen to
regular Bitcoin Core contributors?
_
Regular contributor?
Please explain how for a fork in the protocol should you only listen to
regular Bitcoin Core contributors?
This is an artifact of a small centralized group of developers that
wants to hold on to power. This is why there is so much objection to
documenting some sort of pr
On Mon, Oct 5, 2015 at 9:08 PM, Tom Zander via bitcoin-dev
wrote:
> On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote:
>> (In this case, I don't even believe we have any regulator
>> contributors that disagree).
>
> Regular contributor?
>
> Please explain how for a fork in the protocol sho
> On Oct 5, 2015, at 2:08 PM, Tom Zander via bitcoin-dev
> wrote:
> On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote:
>> (In this case, I don't even believe we have any regulator
>> contributors that disagree).
>
> Regular contributor?
>
> Please explain how for a fork in the protocol s
On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev
wrote:
> Once again, let’s use the current gridlock
Allow me to state unequivocally-- since we've had problems with people
stating non-factuals as fact without getting adequately clear
correction--, there is no gridlock here and an effort to
> On Oct 5, 2015, at 2:30 PM, Gregory Maxwell wrote:
>
> On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev
> wrote:
>> Once again, let’s use the current gridlock
>
> Allow me to state unequivocally-- since we've had problems with people
> stating non-factuals as fact without getting adeq
On 10/5/2015 5:30 PM, Gregory Maxwell via bitcoin-dev wrote:
On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev
wrote:
Once again, let’s use the current gridlock
there is no gridlock here and an effort to manufacturer
one for political reasons will not be successful.
Worthless discu
Peter,
Your concern about whether this is the best way to use the nSequence field;
would that be addressed by providing more high order bits to signal
different uses of the field? At a certain point we're really not limiting
the future at all and there is something to be said for not letting the
On Mon, Oct 5, 2015 at 6:33 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I also agree with Mike that Core's requirement for unanimous consensus
> results in development grid lock and should be revisited.
>
There is no development gridlock. Look at the IRC logs for
On 10/5/2015 6:56 PM, Btc Drak via bitcoin-dev wrote:
There is no development gridlock. Look at the IRC logs for core-dev;
Please desist from this intellectual dishonesty and toxicity.
A system where anyone can veto a change promotes gridlock. Most people
not on the devlpoment team see the
I agree with you, Sergio, up until the part about someone having won a battle.
There's a difference between sincere technical objections and someone just
being a dick. I think in this case this line has been crossed (and I don't
think I'm alone here).
- Eric
On October 5, 2015 8:56:33 AM PDT,
Alex, decreasing granularity is a soft-fork, increasing is a hard-fork.
Therefore I've kept the highest possible precision (1 second, 1 block) with
the expectation that at some point in the future if we need more low-order
bits we can soft-fork them to other purposes, we can decrease granularity
at
Regarding the keeping nSequence for future expansion I believe this has
been covered in the specification section of BIP68[1]: For transaction
version >= 2, if the MSB of nSequence is unset, the field is interpreted as
relative locktime, otherwise no special consensus meaning is attached (and
thus
On 10/5/2015 1:56 PM, Gregory Maxwell via bitcoin-dev wrote:
> In this case, I don't even believe we have any regulator contributors
> that disagree.
Since Gavin Andresen chose you to be one of 4 people who decides whose
contributions are accepted to the Core project, shouldn't you recuse
yourself
Peter Todd via bitcoin-dev
writes:
> However I don't think we've done a good job showing why we need to
> implement this feature via nSequence.
It could be implemented in other ways, but nSequence is the neatest and
most straightforward I've seen.
- I'm not aware of any other (even vague) propos
> On Oct 5, 2015, at 6:37 PM, Tom Harding via bitcoin-dev
> wrote:
>
> On 10/5/2015 1:56 PM, Gregory Maxwell via bitcoin-dev wrote:
>> In this case, I don't even believe we have any regulator contributors
>> that disagree.
>
> Since Gavin Andresen chose you to be one of 4 people who decides wh
I believe we should work to deprecate the idea that Core is somehow the “core of
Bitcoin,"
I never did understand the terminology. There were "core developers"
which i understood to mean the primary developers of the Bitcoin
software. Then, suddenly, the software's name was changed from QT
On Tuesday, October 06, 2015 3:39:59 AM Milly Bitcoin via bitcoin-dev wrote:
> In any case if I could get a list of "Core Developers" as referenced in
> the copyright notice that would also be good since that is a legal notice.
The copyright notice refers to the fact that each contributor owns cop
>
>
> On Mon, Oct 5, 2015 at 11:20 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > On Oct 5, 2015, at 6:37 PM, Tom Harding via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > On 10/5/2015 1:56 PM, Gregory Maxwell via bitcoin-dev wrote:
> >> I
The copyright notice refers to the fact that each contributor owns copyright
to his own contributions. There is no legal group that owns copyright to the
entirety of the code.
No, that is not what such a notice means. The part after the "c" in the
circle is the legal owner. If the legal owne
> If we want decentralization (or even mere stability), we must impose a
> counterbalancing rule such that each past commit makes one *less* likely to
> get their next commit pulled. For example, a "one man one commit" policy.
Haha great stuff, NotMike!
Indeed, it’s not enough to keep the bloc
Maybe you are confused with a compilation notice that would say "All
Content Copyright and other rights reserved by its Respective Owners" or
something similar. That is not the same thing as claiming ownership
using the "c" inside the circle.
There is also a difference between claiming a copy
Copyright doesn't care how notices are written. They are merely informative
to humans reading them. Anyhow, this is not development related, so please
direct any further discussion of it to me directly (with any applicable CCs)
and NOT to the mailing list.
Thanks,
Luke
On Tuesday, October 06,
This list is about "Development discussion list for Bitcoin protocol and
its implementation" So legal notices placed on the software is relevant
to the list.
It is also relevant that you go around speaking with authority when you
have no idea what you are talking about. A copyright is a legal
On Mon, Oct 05, 2015 at 06:46:28PM +0200, Mike Hearn via bitcoin-dev wrote:
> The example is this: find someone that accepts 1-block confirmed
> transactions in return for something valuable. There are plenty of them out
> there. Once the soft fork starts, send a P2SH transaction that defines a
> n
74 matches
Mail list logo
