On Wed, Oct 15, 2014 at 4:54 PM, Adam Back wrote:
> please not google groups *, I'd vote for sourceforge or other simple
> open list software over google groups.
>
Please not sourceforge.
> * Google lists are somehow a little proprietary or gmail lockin
> focused eg it makes things extra hard
On Sun, Oct 19, 2014 at 8:17 AM, xor wrote:
> I joined the list when Bitcoin was already in the 10-billions of market
> capitalization, and it actually really surprised me how low the traffic is
> here
> given the importance of Bitcoin.
>
> So as a random stranger to the project, I would vote aga
On Mon, Nov 17, 2014 at 11:43 AM, Flavien Charlon <
flavien.char...@coinprism.com> wrote:
> > My main concern with OP_RETURN is that it seems to encourage people to
> use the blockchain as a convenient transport channel
>
> The number one user of the blockchain as a storage and transport mechanism
On Fri, Nov 28, 2014 at 5:22 PM, Oliver Egginger wrote:
> Sorry for the off-topic but while reading this I like to ask you for
> picocoin, see:
>
> https://github.com/jgarzik/picocoin
>
> For a research project I'm looking for a C library to operate some block
> chain analysis (parsing raw blocks
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)
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
Would someone also clarify the use of "nit" for nitpicking and how it plays
in the role of consensus?
It seems like it's used for minor complaints/preferences.
Drak
On Wed, Dec 10, 2014 at 3:52 PM, Jeff Garzik wrote:
>
> On Wed, Dec 10, 2014 at 1:47 AM, Wladimir wrote:
>
>> Concept ACK -> agree
Mike,
In all seriousness, are you on the payroll of the NSA or similar to
repeatedly attempt to introduce privacy leaks[1] and weaknesses[2] into the
ecosystem not to mention logical fallacies like ad hominem attacks;
disruption[3] and FUD[4]?
Why do you answer objections by hand waving and misdi
On Thu, Feb 12, 2015 at 3:15 PM, Mike Hearn wrote:
> Peter argues that this is stable and makes unconfirmed transactions safe
>> because a fraudster can buy something, walk out of the shop, and broadcast
>> a double spend with a higher fee. But then the merchant can re-spend the
>> original payme
On Mon, May 4, 2015 at 12:24 PM, Jorge Timón wrote:
> What I was describing was an attempt to fix a similar proposal by Mark
> Friedenbach, but it didn't needed fixing: I was simply
> misunderstanding it.
> Mark's RCLTV is completely reorg safe, so there's no need for the 100
> block restriction.
On Mon, May 4, 2015 at 6:07 AM, Peter Todd wrote:
> Matt Corallo brought up¹ the issue of OP_NOP scarcity on the mempool
> only CLTV pull-req²:
>
> "I like merging this, but doing both CLTV things in one swoop would be
> really nice. Certainly if we're gonna use one of the precious few
>
On Thu, May 7, 2015 at 10:25 AM, Mike Hearn wrote:
> What I don't see from you yet is a *specific and credible plan* that fits
> within the next 12 months and which allows Bitcoin to keep growing. Not
> some vague handwave like "let's all use the Lightning network" (which does
> not exist), or "l
On Thu, May 7, 2015 at 3:05 PM, Mike Hearn wrote:
>
> Maybe you dislike that idea. It's so centralised. So let's say Gavin
> commits his patch, because his authority is equal to all other committers.
> Someone else rolls it back. Gavin sets up a cron job to keep committing the
> patch. Game o
On Thu, May 7, 2015 at 6:43 PM, Mike Hearn wrote:
>
> And I'll ask again. Do you have a *specific, credible alternative*?
> Because so far I'm not seeing one.
>
I think you are rubbing against your own presupposition that people must
find and alternative right now. Quite a lot here do not believe
On Thu, May 7, 2015 at 7:40 PM, Gavin Costin
wrote:
> Can anyone opposed to this proposal articulate in plain english the worst
> case scenario(s) if it goes ahead?
>
> Some people in the conversation appear to be uncomfortable, perturbed,
> defensive etc about the proposal …. But I am not seeing
On Thu, May 7, 2015 at 5:11 PM, Mike Hearn wrote:
> Right now there is this nice warm fuzzy notion that decisions in Bitcoin
>> Core are made by consensus. "Controversial" changes are avoided. I am
>> trying to show you that this is just marketing.
>
>
Consensus is arrived when the people who are
blocking this.
>
> On Sat, May 9, 2015 at 11:12 AM, Peter Todd wrote:
> > On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote:
> >> > That said, if people have strong feelings about this, I would be
> willing
> >> > to make OP_CLTV work as follows:
&
On Sun, May 31, 2015 at 1:29 AM, Matt Whitlock
wrote:
> 3. What *is* clear at this point is that Gavin will move ahead with his
> proposal, regardless of whether the remainder of the Bitcoin Core
> committers agree with him. If he has to commit his changes to Bitcoin XT
> and then rally the miner
I did wonder what the post actually meant, I recommend appending /s after
sarcasm so it's clear. Lots gets lost in text. But I agree with you btw his
response was not particularly tactful.
On Mon, Jun 1, 2015 at 7:19 PM, Warren Togami Jr. wrote:
> By reversing Mike's language to the reality of t
On Mon, Jun 8, 2015 at 11:01 PM, Raystonn . wrote:
> No, with no blocksize limit, a spammer would would flood the network with
> transactions until they ran out of money.
I think you are forgetting even if you remove the blocksize limit, there is
still a hard message size limit imposed by the p
Eric,
BitPay clearly do understand the risks of 0-conf. In case you were not
aware BitPay does not particularly "accept zero confirm transactions". When
a payment is seen on the network the payment screen reports the invoice has
been paid, but that's front-end user facing. On the back end it's mar
21 matches
Mail list logo
