Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Btc Drak]

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 marked as
paid but the API exposes the the confirmation status allowing the merchant
to make business decisions about when to progress to fulfilment. A good
example of this is Neteller (a sort of paypal variant) which allows one to
fund the account with fiat using Bitcoin, via Bitpay. When you pay the
bitpay invoice, your account is marked as payment pending until there are
some confirmations.

Coinbase does not expose the confirmation status and from what I understand
(not checked myself) they guarantee payment to merchants for 0-confirm,
regardless of whether they confirm or not.

I want to address something stated by Justus, that signing a payment
message and broadcasting somehow solidifies intent and going back on that
would be fraud. This seriously conflates cryptographic certainty with human
behaviour. For one, humans make mistakes all the time. We get tired, we get
distracted, we make copy paste errors. It's entirely possible on sends a
payment only to find it's been sent to the wrong address or the wrong
amount has been sent or the fee is wrong. Software may also misbehave
(Electrum for example has a weird UI glitch with fees where the specified
fee can be overwritten). r/bitcoin it littered with sad examples. What
ECDSA signing tells is that it was signed by your private key, but nothing
else. It does not say if *you* signed it, or that the message you signed
was correct.


On Sun, Jun 21, 2015 at 8:42 AM, Eric Lombrozo  wrote:

>
> On Jun 20, 2015, at 11:45 PM, Jeff Garzik  wrote:
>
> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo 
> wrote:
>
>>  but we NEED to be applying some kind of pressure on the merchant end to
>> upgrade their stuff to be more resilient
>>
>
> Can you be specific?  What precise technical steps would you have BitPay
> and Coinbase do?  We upgrade our stuff to... what exactly?
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/
>
>
> Thanks for asking *the* question, Jeff. We often get caught up in these
> philosophical debates…but at the end of the day we need something concrete.
>
> Even more important than the specific software you’re using is the
> security policy.
>
> If you must accept zero confirmation transactions, there are a few
> concrete things you can do to reduce your exposure:
>
> 1) limit the transaction amounts for zero confirmation transactions - do
> not accept them for very high priced goods…especially if they require
> physical shipping.
> 2) limit the total amount of unconfirmed revenue you’ll tolerate at any
> given moment - if the amount is exceeded, require confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, etc…)
> the ability to shut the user out if a double-spend is detected.
> 4) collect legal information on purchasers (or have the merchants collect
> this information) so you have someone to go after if they try to screw you
> 5) create a risk profile for users…and flag suspicious behavior (i.e.
> someone trying to purchase a bunch of stuff that totally doesn’t fit into
> their purchasing habits).
> 6) get insurance (although right now reasonably-priced insurance is
> probably pretty hard to obtain since statistics are generally of little
> use…we’re entering uncharted territory).
> 7) set up a warning system and a “panic” button so that if you start to
> see an attack you can immediately disable all zero confirmation
> transactions system-wide.
> 8) independently verify all inbound transactions and connect to multiple
> network nodes…check them against one another.
>
>
> As for software tools to accomplish these things, we can talk about that
> offline :)
>
>
> - Eric Lombrozo
>
>
>
>
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit

[Btc Drak]

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 p2p protocol. Block would
de-facto be limited to this size.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Btc Drak]

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 the situation I had hoped
> people would realize how abjectly ignorant and insensitive his statement
> was.  I am sorry to those in the community if they misunderstood my post. I
> thought it was obvious that it was sarcasm where I do not seriously believe
> particular participants should be excluded.
>
> On Mon, Jun 1, 2015 at 3:06 AM, Thy Shizzle 
> wrote:
>
>>  Doesn't mean you should build something that says "fuck you" to the
>> companies that have invested in farms of ASICS. To say "Oh yea if they
>> can't mine it how we want stuff 'em" is naive. I get decentralisation, but
>> don't dis incentivise mining. If miners are telling you that you're going
>> to hurt them, esp. Miners that combined hold > 50% hashing power, why would
>> you say too bad so sad? Why not just start stripping bitcoin out of
>> adopters wallets? Same thing.
>>  --
>> From: Warren Togami Jr. 
>> Sent: ‎1/‎06/‎2015 10:30 PM
>> Cc: Bitcoin Dev 
>> Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
>>
>>   Whilst it would be nice if miners in *outside* China can carry on
>> forever regardless of their internet situation, nobody has any inherent
>> "right" to mine if they can't do the job - if miners in *outside* China
>> can't get the trivial amounts of bandwidth required through their
>> firewall *TO THE MAJORITY OF THE HASHRATE* and end up being outcompeted
>> then OK, too bad, we'll have to carry on without them.
>>
>>
>> On Mon, Jun 1, 2015 at 12:13 AM, Mike Hearn  wrote:
>>
>>  Whilst it would be nice if miners in China can carry on forever
>> regardless of their internet situation, nobody has any inherent "right" to
>> mine if they can't do the job - if miners in China can't get the trivial
>> amounts of bandwidth required through their firewall and end up being
>> outcompeted then OK, too bad, we'll have to carry on without them.
>>
>>  But I'm not sure why it should be a big deal. They can always run a
>> node on a server in Taiwan and connect the hardware to it via a VPN or so.
>>
>>
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: A measured response to save Bitcoin Core

[Btc Drak]

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 miners to switch, then that's what he'll do. He believes
> that he is working in the best interests of Bitcoin (as I would hope we all
> do), and so I do not fault him for his intentions. However, I think his
> proposal is too risky.
>

I seriously doubt if miners and merchants who's income depends on bitcoin
are going to risk a network split. Gavin isn't pedalling some mempool
policy which doesn't affect consensus. The changes have to be universally
adopted by miners and full nodes. If there is any uncertainty about that
global acceptance, those financially dependent on bitcoin will not take the
risk just to be political. You can see how conservative the mining
community is already by their slow upgrade of Bitcoin Core as it is. Even
if some miners and merchants generally support the idea of bigger blocks,
they most certainly are not going to take the risk of leading a hard fork
when there is substantial risk of it failing.

Until there is actual consensus among the technical community I wouldn't be
too concerned.


> 4. I also think that ignoring the immediate problem is too risky. If
> allowing significantly larger blocks will cause a serious problem for
> Bitcoin (which is a possibility that we cannot rule out, as we lack
> omniscience), then NOT making any change to Bitcoin Core will virtually
> *assure* that we cause exactly this problem, as the popular (non-technical)
> consensus appears to be in favor of Bitcoin XT and a larger block size
> limit. If we do nothing, then there's a very real chance that Bitcoin XT
> takes over, for better or worse.
>

I don't think anyone is ignoring the issues, nor that everyone accepts that
blocksize may have to eventually change. The overwhelming technical
majority do not agree there is a problem that needs to be immediately
addressed. It would be far more helpful if we focused on stuff that helps
enable level 2 technologies so that bitcoin can actually scale, (like
R/CLTV and malleability fixes which are being delayed by BIP66 rollout and
pending the new "concurrent soft-forks" proposal).


> 7. It's not a given that blocks will immediately expand to meet the hard
> limit. In fact, there are strong and compelling arguments why this will NOT
> happen. But in any software system, if a given scenario is *possible*, then
> one MUST assume that it will happen and must have a plan to handle it.
>

But of course it would be dealt with if and when it becomes necessary. It's
not like there is blanket opposition to increasing the blocksize ever, it's
the matter of if, when and how; but when is defintely not now.

9. My proposal is that we raise the block size limit *gradually*, using an
> approximately smooth function, without a step discontinuity. We can employ
> a linear growth function to adjust the block size limit *smoothly* from 1
> MB to 20 MB over the course of several years, beginning next March.
>

Automatic or dynamic blocksize increase risks being very difficult to shut
down if later we find it is negatively impacting the ecosystem... and
that's part of the reluctance with bigger blocks because we still have not
studied the potential downsides enough beyond some sketchy and disputed
calculations and overall it's not addressing scalability at all.


> 10. This is the difference between cannonballing into the deep end of the
> pool and walking gingerly down the steps into the shallow end. Both get you
> to the eventual goal, but one is reckless while the other is measured and
> deliberate. If there's a problem that larger blocks will enable, then I'd
> prefer to see the problem crop up gradually rather than all at once. If
> it's gradual, then we'll have time to discuss and fix it without panicking.


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
good software do not mix.

Drak
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?

[Btc Drak]

Gavin and @NicolasDorier have a point: If there isn't actually scarcity of
NOPs because OP_NOP10 could become  OP_EX (if we run out), it makes
sense to chose the original unparameterised CLTV version #6124 which also
has been better tested. It's cleaner, more readable and results in a
slightly smaller script which has also got to be a plus.

On Tue, May 12, 2015 at 8:16 PM, Jorge Timón  wrote:

> This saves us ocodes for later but it's uglier and produces slightly
> bigger scripts.
> If we're convinced it's worth it, seems like the right way to do it,
> and certainly cltv and rclv/op_maturity are related.
> But let's not forget that we can always use this same trick with the
> last opcode to get 2^64 brand new opcodes.
> So I'm not convinced at all on whether we want  #5496 or #6124.
> But it would be nice to decide and stop 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:
> >> >
> >> >  1 OP_CLTV
> >> >
> >> > Where the 1 selects absolute mode, and all others act as OP_NOP's. A
> >> > future relative CLTV could then be a future soft-fork implemented as
> >> > follows:
> >> >
> >> >  2 OP_CLTV
> >> >
> >> > On the bad side it'd be two or three days of work to rewrite all the
> >> > existing tests and example code and update the BIP, and (slightly)
> gets
> >> > us away from the well-tested existing implementation. It also may
> >> > complicate the codebase compared to sticking with just doing a Script
> >> > v2.0, with the additional execution environment data required for v2.0
> >> > scripts cleanly separated out. But all in all, the above isn'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.
> >
> > Done!
> >
> > https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-100454263
> >
> > --
> > 'peter'[:-1]@petertodd.org
> > 12c438a597ad15df697888be579f4f818a30517cd60fbdc8
> >
> >
> --
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > ___
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase

[Btc Drak]

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 most active at the time
(active in contributing to discussions, code review, giving opinions etc.)
agreed to ACK. There are a regular staple of active contributors. Bitcoin
development is clearly a meritocracy. The more people participate and
contribute the more weight their opinions hold.


> Nobody can define what these terms even mean. It would be more accurate to
>> say decisions are vetoed by whoever shows up and complains enough,
>> regardless of technical merit. After all, my own getutxo change was merged
>> after a lot of technical debate (and trolling) . then unmerged a day
>> later because "it's a shitstorm".
>
>
I am not sure that is fair, your PR was reverted because someone found a
huge exploit in your PR enough to invalidate all your arguments used to get
it merged in the first place.


> So if Gavin showed up and complained a lot about side chains or whatever,
> what you're saying is, oh that's different. We'd ignore him. But when
> someone else complains about a change they don't like, that's OK.
>
> Heck, I could easily come up with a dozen reasons to object to almost any
> change, if I felt like it. Would I then be considered not a part of the
> consensus because that'd be convenient?
>

I don't think it's as simple as that. Objections for the sake of
objections, or unsound technical objections are going to be seen for what
they are. This is a project with of some of the brightest people in the
world in this field. Sure people can be disruptive but their reputation
stand the test of time.

The consensus system might not be perfect, but it almost feels like you
want to declare a state of emergency and suspend all the normal review
process for this proposed hard fork.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase

[Btc Drak]

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 specifics on why it
> is not a feasible plan.
>

See this response:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07462.html
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase

[Btc Drak]

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 there is
any urgency, nor that there is an immanent problem that has to be solved
before the sky falls in.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase

[Btc Drak]

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 over.
>
> You cannot have committers fighting over what goes in and what doesn't.
> That's madness. There must be a single decision maker for any given
> codebase.
>

You are conflating consensus with commit access. People with commit access
are maintainers who are *able to merge* pull requests. However, the rules
for bitcoin development are that only patches with consensus get merged. If
any of the maintainers just pushed a change without going through the whole
code review and consensus process there would be uproar, plain and simple.

Please don't conflate commit access with permission to merge because it's
just not the case. No-one can sidestep the requirement to get consensus,
not even the 5 maintainers.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase

[Btc Drak]

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 "let's do more research" (Gavin has done plenty of
> research), or "but what about the risks" (Bitcoin is full of risks). A
> plan, with dates attached, and a strong chance of actually being deployed
> in time.
>

Would you please explain where this 12 months timeframe comes from?
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?

[Btc Drak]

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
> OP_NOPs we have we might as well make it more flexible."
>
> [snip]

> That said, if people have strong feelings about this, I would be willing
> to make OP_CLTV work as follows:
>
>  1 OP_CLTV
>
> Where the 1 selects absolute mode, and all others act as OP_NOP's. A
> future relative CLTV could then be a future soft-fork implemented as
> follows:
>
>  2 OP_CLTV
>
> On the bad side it'd be two or three days of work to rewrite all the
> existing tests and example code and update the BIP, and (slightly) gets
> us away from the well-tested existing implementation. It also may
> complicate the codebase compared to sticking with just doing a Script
> v2.0, with the additional execution environment data required for v2.0
> scripts cleanly separated out. But all in all, the above isn'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
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

[Btc 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. It also keeps the script validation independent
> from the utxo.
> Here's is how it works:
>
> The operator takes a relative_height parameter and it checks that the
> nSequence of the input is lower than that parameter.
>
> Additionally, a new check at the transaction level:
>
> for (unsigned int i = 0; i < tx.vin.size(); i++) {
> // ...
> if (coins->nHeight + tx.vin[i].nSequence < nSpendHeight)
> return state.Invalid(false, REJECT_INVALID,
> "bad-txns-non-final-input");
> // ...
> }
>
> Well, this is assuming that we're only using it with heights and not
> timestamps.
> Mark, feel free to elaborate further.


Does dropping timestamp refer just to RCLTV or absolutely CLTV also? For
absolute CLTV I think it's important to have timestamps so that trust fund
use cases are practical (e.g. spendable on 18th birthday), because the
exact date a future block will be mined on is unpredictable if it's far
enough in the future (out by days or even weeks).
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Btc Drak]

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 payment back to themselves with an *even* higher fee than that.
>> Then the fraudster can re-spend their double spend with an *even* higher
>> fee than that, and so on back and forth, until *all* the money has been
>> spent to miner fees. Thus the merchant loses their goods but the fraudster
>> has still "paid" in some sense because they don't get the money either.
>>
>
> This argument makes no sense for two reasons.
>
> The first is that this setup means miners can steal arbitrary payments if
> they work together with the sender of the money. The model assumes this
> collaboration won't happen, but it will. Because no existing wallet has a
> "double spend this" button, to make the scheme work the dishonest miners
> must create and distribute such a wallet that implements the whole
> scorched-earth protocol. At that point it's easy for miners to reward the
> payment fraudster with some of the stolen money the merchant lost, meaning
> it now makes sense for the fraudster to always do this. The situation isn't
> stable at all.
>
> The second is that it incentivises competitors to engage in payment fraud
> against each other. A big rich coffee shop chain that is facing competition
> from a small, scrappy newcomer can simply walk into the new shop and buy
> things, then trigger the "scorched earth". Even with no miner
> collaboration, this means the big company is down the cost of the product
> *but* so is the little company who lost everything. Whoever can outspend
> the other wins.
>

I think that is a misdirection on your part. The point of replace-by-fee is
to make 0-confirms reliably unreliable. Currently people can "get away"
with 0-confirms but it's only because most people arent actively double
spending, and when they do it is for higher value targets. Double spend
attacks *are* happening a lot more frequently than is being admitted here,
according to Peter from work with various clients.

Like single address reuse, people have gotten used to something which is
bad. Generally accepting 0-conf is also a bad idea(tm) and instant
confirmation solutions should be sought elsewhere. There are already
interesting solutions and concepts: greenaddress for example, and
CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than
supporting and promoting risky 0-confirms, we need to spend time on better
alternative solutions that will work for everyone and not during the
honeymoon phase where attackers are fewer.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Cartographer

[Btc Drak]

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 misdirection as opposed to
sound technical reasoning? Remember how hand waving ended for you the last
time with your p2p getutxo pull-request[5] and the public flogging the
ensued because you refused to accept your implementation was not only
flawed but critically vulnerable to attack[6].

Given your intelligence, education and experience, it would seem logical
that your behaviour is not random or irrational, but in fact calculated and
planned.

references:
[1]
http://www.reddit.com/r/Bitcoin/comments/2byqz0/mike_hearn_proposes_to_build_vulnerable/
[2]
https://www.reddit.com/r/Bitcoin/comments/1qmbtu/mike_hearn_chair_of_the_bitcoin_foundations_law/
[3]
http://www.reddit.com/r/Bitcoin/comments/28zts3/mike_hearn_interview_quotes_progress_on_the/
[4] https://www.youtube.com/watch?v=iMIzMVABFxQ
[5] https://github.com/bitcoin/bitcoin/pull/4351
[6]
http://www.reddit.com/r/Bitcoin/comments/2eq8gi/getutxos_a_convenient_way_to_crash_bitcoind/
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] ACK NACK utACK "Concept ACK"

[Btc Drak]

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 with the idea and overall direction, but haven't
>> reviewed the code changes nor tested it
>>
>
> Concept ACK -> like the idea; the code may need rewriting (or haven't
> reviewed).
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged

[Btc Drak]

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 new data structures, breaking a
> bunch of out-of-tree patches, complicating review quite a bit.  If the vast
> majority of code movement is up front, followed by algebraic
> simplifications, followed by data structure work, further patches are easy
> to review/apply with less impact on unrelated code.
>
> The flow of patches into the tree over time should be examined.  Simply
> tagging patches as movement-only does not address the described problem at
> all.
>

I think we can all agree that if the process is made more friendly for
reviewers, everyone wins. It's been hard to even know where everything is
because it moves so often. e.g. In the last couple weeks stuff moved from
core.h to core/block.h to primitive/block.h or something to that effect.
Anyway, Jeff said this quite elegantly.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged

[Btc Drak]

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). Refactoring should
come in a second wave preferably after a stable release. Refactoring should
be in the pure sense, optimising code with absolutely no change in
behaviour.

When it comes to actual API changes, I think we need to be a lot more
careful and should be considered feature requests and get a lot more
scrutiny as we are essentially breaking backwards compatibility. #4890 was
pretty much merged with no discussion or thought yet other really simple
and uncontroversial PRs remain unmerged for months. A key question in the
case of EvalScript() would have been, "why are we passing txTo and nIn
here, and are there any future use cases that might require them? Why
should this be removed from the API and the entire method signature
changed?". BC breaks always need strong justification.

So I've expressed my concern a few times about the speed and frequency of
refactoring and also the way it's being done. I am not alone, as others not
directly connected with the Bitcoin Core project have also expressed
concerns about the number of refactorings "for the sake of refactoring",
especially of consensus critical code. Careful as we may be, we know from
history that small edge case bugs can creep in very easily and cause a lot
of unforeseen problems.

BtcDrak


On Mon, Dec 15, 2014 at 12:47 PM, Peter Todd  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, changed the
> EvalScript() function to take an abstract SignatureChecker object,
> removing the
> txTo and nIn arguments that used to contain the transaction the script was
> in
> and the txin # respectively. CHECKLOCKTIMEVERIFY needs txTo to obtain the
> nLockTime field of the transaction, and it needs nIn to obtain the
> nSequence of
> the txin.
>
> We need to fix this if CHECKLOCKTIMEVERIFY is to be merged.
>
> Secondly, that this change was made, and the manner in which is was made,
> is I
> think indicative of a development process that has been taking significant
> risks with regard to refactoring the consensus critical codebase. I know I
> personally have had a hard time keeping up with the very large volume of
> code
> being moved and changed for the v0.10 release, and I know BtcDrak - who is
> keeping Viacoin up to date with v0.10 - has also had a hard time giving the
> changes reasonable review. The #4890 pull-req in question had no ACKs at
> all,
> and only two untested utACKS, which I find worrying for something that made
> significant consensus critical code changes.
>
> 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. This is after all a
> multi-billion
> project where a simple fork will cost miners alone tens of thousands of
> dollars
> an hour; easily much more if it results in users being defrauded. That's
> also
> not taking into account the significant negative PR impact and loss of
> trust. I
> personally would recommend *not* upgrading to v0.10 due to these issues.
>
> A much safer approach would be to keep the code changes required for a
> consensus library to only simple movements of code for this release, accept
> that the interface to that library won't be ideal, and wait until we have
> feedback from multiple opensource projects with publicly evaluatable code
> on
> where to go next with the API.
>
> 1) https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
> 2) https://github.com/bitcoin/bitcoin/pull/4890
>
> --
> 'peter'[:-1]@petertodd.org
> 1b18a596ecadd07c0e49620fb71b16f9e41131df9fc52fa6
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Shar

Re: [Bitcoin-development] bitcoind as a library

[Btc Drak]

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 and transactions).


This might be useful for you https://github.com/MatthewLM/cbitcoin
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

[Btc Drak]

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
> is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them
> from doing so. In fact they use multi-sig outputs which is worse than
> OP_RETURN since it's not always prunable, and yet let them store much more
> than 40 bytes.
>
> For Open Assets , we
> need to store a URL in the OP_RETURN output (with optionally a hash) plus
> some bytes of overhead. 40 bytes comes really short for that. The benefit
> of having a URL in there is that any storage mechanism can be used (Web,
> FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to
> hardcode the storing mechanism in the protocol (and even then, a hash is
> not enough to address a HTTP or FTP resource). Storing only a hash is fine
> for the most basic timestamping application, but it's hardly enough to
> build something interesting.
>
> I've counted the number of OP_RETURN outputs in the blockchain for the
> month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659
> blocks. Assuming they were all 40 bytes (the average is probably less than
> half of that), that means an increase of 14.37 bytes per block. Considering
> a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data
> in average.
>
> Increasing to 80 bytes will have a negligible impact on bandwidth and
> storage requirements, while being extremely useful for many use cases where
> a hash only is not enough.
>

While I am not opposing the proposal, I am not sure about your statistics
because while Counterparty is not currently using OP_RETURN encoding, you
should factor in the number of CP transactions that would have been
OP_RETURNs if they had been permitted (100,000 since inception according
their blog[1] with monthly charts at their block explorer[2]).

Refs:
[1]
http://counterparty.io/news/celebrating-10-transaction-on-the-counterparty-network/
[2] http://blockscan.com/
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP process

[Btc Drak]

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 against that if I was
> allowed to. There really should be *more* discussion here, and splitting
> the
> list up won't help with that.


I agree. This is also where the best peer review is to be found. Splitting
the list will dilute this.
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP process

[Btc Drak]

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 to subscribe with a non-google
> address if google has any hint that your address is associated with a
> gmail account.  Quite frustrating.


Mailman is good enough...
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development