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
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
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
Extending blocksize now would be nothing more than a political move. I have
no idea what will be decided in the end, but I do know that in order for
bitcoin to survive, changes must be based on well thought out and discussed
technical merits and not the result of political pressure. Politics and
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 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
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 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 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 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
n't too big
> of a deal.
Adding a parameter to OP_CLTV makes it much more flexible and is the most
economic use of precious NOPs.
The extra time required is ok and it would be good to make this change to
the PR in time for the feature freeze.
Drak
---
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 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
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
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 wr
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
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 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
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 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 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 23 August 2014 12:38, Pieter Wuille wrote:
> That allows using github as easy-access mechanism for people to
> contribute and inspect, while having a higher security standard for
> the actual changes done to master.
I'd also like to point out the obvious: git uses the previous hash as part
o
Related to Russia's Tor bounty?
http://www.theguardian.com/world/2014/jul/25/russia-research-identify-users-tor
On 28 Jul 2014 04:45, "Gregory Maxwell" wrote:
> On Sun, Jul 27, 2014 at 7:54 PM, m...@bitwatch.co
> wrote:
> > These website list Tor nodes by bandwidth:
> >
> > http://torstatus.blut
*watches the tumble weed blow by*
I think it's pretty safe to remove it...
On 4 July 2014 08:15, Wladimir wrote:
> On Wed, Jun 11, 2014 at 5:39 PM, Wladimir wrote:
>
> > If no one screams fire, we plan on removing support for it in the next
> > major release, for two reasons:
> >
> > - It wou
Seems like a nice idea.
On 24 June 2014 14:27, Mike Hearn wrote:
> Coinbase have started allowing merchants to set discounts for purchasing
> with Bitcoin. Seeing an individual discount is not very motivating as they
> tend to be small. Seeing them stack up over time can be more motivating
> be
I am sure the failure here is probably more mundane like a a service not
restarted, or not on auto restart when server is rebooted and such like.
The dns seeder works pretty efficiently in my experience. Maybe we need
more seeders and to include the ability for zone transfers so existing
seeders ca
+1
On 4 May 2014 02:06, "Chris Pacia" wrote:
> Absent a concerted effort to move to something else other than 'bits', I
> would be willing to bet the nomenclature moves in that direction anyway.
> 'Bits' is just a shorten word for 'millibits' (or microbits, if you
> will). It's easier to say and
Cut it out with the ad hominem attacks please. If you cant be civil, please
go away until you learn some manners.
I think the issue being discussed is do you orphan an entire block causing
distress to users as well, or try to just cause distress just to the evil
miner? This discussion is about exp
I would like to set up my own bitcoin pull-tester on Jenkins. Are there any
instructions or guidance written anywhere?
Drak
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
For what it's worth, the number of nodes rose dramatically during the China
bullrun (I recall 45k in China alone) and dropped as dramatically as the
price after the first PBOC announcement designed to cool down bitcoin
trading in China.
On 7 April 2014 12:34, Mike Hearn wrote:
> At the start of
rture community contributions around the project which is really
important.
Drak
On 15 March 2014 17:22, Peter Todd wrote:
> On Sat, Mar 15, 2014 at 05:12:42PM +0000, Drak wrote:
> > Would it make sense to pull that stuff in and add Peter with commit
> access
> > since your
Would it make sense to pull that stuff in and add Peter with commit access
since your repo is top of the fork tree.
Drak
On 15 March 2014 16:47, Jeff Garzik wrote:
> Sounds great. I'm glad to see this with a more active maintainer.
> Maintaining -three- client libs was a bit
consensus among themselves to accept and merge a PR to that
effect. That will send a message, more than anything else that can be done.
My two satoshi.
Drak
On 13 March 2014 16:29, Jeff Garzik wrote:
> On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner wrote:
> > Of course, as Mike said, this
d in advance knowing the initial transaction size and
the number of signatures required? Should be quite easy to make an
estimation from that? It's probably more of an implementation detail
though...
Drak
--
Learn Gr
make wide-spread use much more likely
and possible.
Drak
On 11 March 2014 01:15, Gavin Andresen wrote:
> Multisig is orthogonal to the payment protocol (but payment protocol is
> needed first).
>
> There need to be protocols for:
>
> a) Establishing multisig wallets of
terface at coinb.in/multisig but it
still lacks the kind of ease with created by the payment protocol. If there
was a BIP then it would go a long way to aiding future usability of
multisig wallet implementations.
What are your thoug
ng
SHA-1 from the specification.
Drak
--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version larg
n even update
by visiting your fork (it creates this automatically and a topic branch)
and make more edits and it will add to your PR. There is basically no
barrier for non techy people to contribute.
Drak
--
Flow-based real
Not true, PHP does support sha2
http://php.net/manual/en/mhash.constants.php
http://php.net/manual/en/function.hash-algos.php#refsect1-function.hash-algos-examples
On 2 Mar 2014 08:44, "Mike Hearn" wrote:
> SHA-1 support is there for PHP developers. Apparently it can't do SHA-2.
> On 2 Mar 2014
t into bitcoin if
submitted?
Drak
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic
arly):
and you can drop quarterly since it's just expressed as per 3*monthly.
Drak
On 25 February 2014 16:29, Mike Hearn wrote:
> Hey there,
>
> So the essence of this protocol is as follows:
>
> enum PaymentFrequencyType {
>
> WEEKLY = 1;
>
>
are issues, but MtGox should have worked around it.
Also thanks to Gregory for also writing[2] about the matter.
Drak
[1] https://bitcoinfoundation.org/blog/?p=418
[2]
http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds
What is the official response from the Bitcoin Core developers about
MtGox's assertion that their problems are due to a fault of bitcoin, as
opposed to a fault of their own?
The technical analysis preluding this mess, was that MtGox was at fault for
their faulty wallet implementation.
ight:
>
>https://www.google.com/search?tbm=isch&q=stealth
>
> But everyone loves privacy.
>
>
> On Fri, Jan 17, 2014 at 8:49 AM, Drak wrote:
>
>> Peter I agree with you about "reusable addresses", but aren't we also
>> trying to get away
Peter I agree with you about "reusable addresses", but aren't we also
trying to get away from the word "address" entirely? How about calling it
a "payment key" or "reusable payment key" instead? using "stealth" is just
asking for bad press imo.
On 16 January 2014 21:28, Peter Todd wrote:
> On
oblem is all addresses are reusable and to an average user, addresses
are already reusable so there is little to distinguish the address format.
It might be better to call it a "public address" in common terminology.
Drak
-
Sorry this is possibly OT, but someone posted this thread to r/bitcoin and
it's gone straight to position 1. People are really enthusiastic about this
feature.
Drak
--
CenturyLink Cloud: The Leader in Enterprise
On 13 January 2014 19:40, Roy Badami wrote:
> At the moment, I can give them a business card with a Bitcoin address.
> Being able to give out a business card with a stealth address would be
> a major advance.
My thoughts exact
of-m multisig. (n>=2) Interestingly that also means you
> can give a third-party that key and out-source the effort of scanning
> the blockchain for you.
That seems pretty exciting to me. What is the chance of
On 3 January 2014 05:45, Troy Benjegerdes wrote:
> On Tue, Dec 31, 2013 at 05:48:06AM -0800, Gregory Maxwell wrote:
> > On Tue, Dec 31, 2013 at 5:39 AM, Drak wrote:
> > > The NSA has the ability, right now to change every download of
> bitcoin-qt,
> > > o
g the bitcoin crypto-currency client
in the clear.
For anyone who has not seen the video. You will be shocked by what is
actually in the wild being used today. It goes way beyond anything
imaginable even in science fiction.
https://www.youtube.com/watch
someone hacked github and changed the history of the tree, the next time
you tried to push his code up it would fail because the history had changed
- tampering is immediately obvious in git.
Regards,
Drak
On 19 December 2013 17:44, Peter Todd wrote:
> On Thu, Dec 19, 2013 at 04:04:17PM -
it tag -s` should
probably be incorporated into the spec as a MUST.
Drak
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application perfor
age, you
might be better using the word RECOMMENDED or MAY over SHOULD here.
Additionally, at the beginning of the spec I would put :
"The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "
figured in preferences. Sanity checking is sensible where a user
can override the calculated fee. Some wallets don't allow the fee to be
adjusted at all, but quite a few do.
Drak
On 16 December 2013 10:46, Jim wrote:
> Yes I saw that on reddit too.
>
> I think it applies mainl
with what looks
like an unusually large fee according to the going rate.
Drak
[1]
http://www.reddit.com/r/Bitcoin/comments/1syu3h/i_lost_all_my_bitcoins_in_an_erroneous/
--
Rapidly troubleshoot problems before they affect
On 9 December 2013 15:35, Wladimir wrote:
>
> On Mon, Dec 9, 2013 at 4:19 PM, Drak wrote:
>
>>
>> IMO, to avoid that, no files should be placed online unless they are the
>> official release.
>>
>
> They *are* the official release as soon as they're u
On 9 December 2013 15:07, Gregory Maxwell wrote:
> On Mon, Dec 9, 2013 at 6:55 AM, Drak wrote:
> > It was released and it's all over bitcointalk/reddit
>
> It has not been released. It's queued for announcement. We were
> waiting for another independant gitian
On 9 December 2013 13:52, Roy Badami wrote:
>
> On Mon, Dec 09, 2013 at 01:39:51PM +, Drak wrote:
> > Someone needs to update the bitcoin.org website, it still points
> downloads
> > to 0.8.5
>
> Perhaps because 0.8.6 hasn't been released yet? Or did I miss
Someone needs to update the bitcoin.org website, it still points downloads
to 0.8.5
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubad
On 8 December 2013 21:01, Luke-Jr wrote:
> On Sunday, December 08, 2013 8:51:07 PM Drak wrote:
> > Otherwise, who has admin rights to the code projects
> > (github/sourceforge/this mailing list)? Those people have proven they can
> > be trusted so far.
>
> Can som
pped it's inclusion in the bitcoin payment protocol.
Anyway, I take your points, but this is an area I am quite passionate about
so it's important for me to be clear.
Regards,
Drak
--
Sponsored by Intel(R) XDK
Develo
meone (even in a group
each person can act autonomously).
The only thing I can suggest would be to hand the keys to the bitcoin
project lead.
Otherwise, who has admin rights to the code projects
(github/sourceforge/this mailing list)? Those people hav
On 8 December 2013 19:25, Gregory Maxwell wrote:
> On Sun, Dec 8, 2013 at 11:16 AM, Drak wrote:
> > BGP redirection is a reality and can be exploited without much
>
> You're managing to argue against SSL. Because it actually provides
> basically protection against an at
SL
only*according to recent discussions at the W3C (
http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0625.html).
Drak
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single
ease (see
https://github.com/blog/1547-release-your-software). There are also no
adverts (another privacy leak at the least) and many feel are more
trustworthy than Sourceforge: it also makes sense to have the downloads
where the source is developed.
Regards,
Drak
On 8 December 2013 03:38, Odinn
On 3 December 2013 11:46, Mike Hearn wrote:
> On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen
> wrote:
>>
>> If users want to pay with a huge transaction then it seems to me the user
>> should cover that cost. Allowing users to pay merchants with 100K
>> transactions full of dust and expecting t
On 3 December 2013 11:03, Peter Todd wrote:
> UI once both are implemented is to not show anything in the default
> case, and explain to the user why they have to pay extra in the unusual
> case where they are spending a whole bunch of dust.
Yes, that's the other problem with a merchant setting
On 3 December 2013 10:45, Mike Hearn wrote:
> On Tue, Dec 3, 2013 at 11:36 AM, Drak wrote:
>
>> I dont like the idea of putting the min fee in the hands of the receiver.
>> Seems like that will work against the best interests of senders in the long
>> run.
>>
&
accept.
I absolutely do not trust vendors to set fees. I think it has to be based
on what senders are willing to pay and what miners are willing to accept.
Drak
--
Rapidly troubleshoot problems before they affect your business
On 19 November 2013 17:01, Gregory Maxwell wrote:
> On Tue, Nov 19, 2013 at 8:53 AM, Drak wrote:
> > It's quite normal for standards bodies to allocate numbers when in draft
> > status. If they don't pass, they don't pass - they are clearly labelled
> > DRAF
it could be called BIP xxx Draft).
> I don't think we are at risk of running out of numbers to assign any time
> soon.
>
It's quite normal for standards bodies to allocate numbers when in draft
status. If they don't pass, they don't pass - the
On 16 November 2013 01:10, Luke-Jr wrote:
> On Saturday, November 16, 2013 12:41:56 AM Drak wrote:
> > So "a payment clears after one confirmation, but you might want to wait
> > until the payment has been confirmed n times".
> > Then at least you are not using
e "email
address"
So "payment address" or "bitcoin address" make better sense here when
qualified as a " address" and not just an "address"
You could also call it "payment id", but I don
On 14 November 2013 22:32, Drak wrote:
> On 14 November 2013 22:00, Alan Reiner wrote:
>
>> Just keep in mind it will be a little awkward that 54.3 uBTC is the
>> smallest unit that can be transferred [easily] and the standard fees are
>> 500 uBTC.It's not a
On 14 November 2013 22:00, Alan Reiner wrote:
> Just keep in mind it will be a little awkward that 54.3 uBTC is the
> smallest unit that can be transferred [easily] and the standard fees are
> 500 uBTC.It's not a deal breaker,
>
The fed was reduced to 0.0001/kb a wh
ve to switch to uBTC later - especially when that later could be a lot
sooner.
Unless something is recommended/done by the bitcoin core developers I doubt
much will change at bitcoin user/consumer level.
Drak
On 14 November 2013 11:45, Melvin Carvalho wrote:
> Rationale
> ===
&g
On 5 November 2013 23:06, Gregory Maxwell wrote:
> On Tue, Nov 5, 2013 at 2:15 PM, Drak wrote:
> > If I understand the issue properly, this seems like a pretty elegant
> > solution: if two blocks are broadcast within a certain period of
> eachother,
> > chose the lower t
diately.
You could even add another unpredictable factor: deciding the rules of
whether higher or lower wins by hashing both competing blockhashes. If the
leading two hex digits are below 128 lower wins, and if above, higher wins.
Drak
--
roperly, this seems like a pretty elegant
solution: if two blocks are broadcast within a certain period of eachother,
chose the lower target. That's a provable fair way of randomly choosing the
winning block and would
80 matches
Mail list logo
