Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Gavin Andresen
On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos mor...@gmail.com wrote:

 Let me take a pass at explaining how I see this.

 1) Code changes to Bitcoin Core that don't change consensus:  Wladimir is
 the decider but he works under a process that is well understood by
 developers on the project in which he takes under reasonable consideration
 other technical opinions and prefers to have clear agreement among them.


Yes.

2) Changes to the consensus rules: As others have said, this isn't anyone's
 decision for anyone else.


Yes.


 It's up to each individual user as to what code they run and what rules
 they enforce.  So then why is everyone so up in arms about what Mike and
 Gavin are proposing if everyone is free to decide for themselves?  I
 believe that each individual user should adhere to the principle that there
 should be no changes to the consensus rules unless there is near complete
 agreement among the entire community, users, developers, businesses miners
 etc. It is not necessary to define complete agreement exactly because every
 individual person decides for themselves.  I believe that this is what
 gives Bitcoin, or really any money, its value and what makes it work, that
 we all agree on exactly what it is.  So I believe that it is misleading and
 bad for Bitcoin to tell users and business that you can just choose without
 concern for everyone else which code you'll run and we'll see which one
 wins out.  No.  You should run the old consensus rules (on any codebase you
 want) until you believe that pretty much everyone has consented to a change
 in the rules.  It is your choice, but I think a lot of people that have
 spent time thinking about the philosophy of consensus systems believe that
 when the users of the system have this principle in mind, it's what will
 make the system work best.


I don't think I agree with pretty much everybody, because status-quo bias
is a very powerful thing. Any change that disrupts the way they've been
doing things will generate significant resistance -- there will be 10 or
20% of any population that will take a position of too busy to think about
this, everything seems to be working great, I don't like change, NO to any
change.

For example, I think some of the resistance for bigger blocks is coming
from contributors who are worried they, personally, won't be able to keep
up with a bigger blockchain. They might not be able to run full nodes from
their home network connections (or might not be able to run a full node AND
stream Game of Thrones), on their old raspberry pi machines.

The criteria for me is clear super-majority of the people and businesses
who are using Bitcoin the most, and I think that criteria is met.



 3) Code changes to Core that do change consensus: I think that Wladimir,
 all the other committers besides Gavin, and almost all of the other
 developers on Core would defer to #2 above and wait for its outcome to be
 clear before considering such a code change.


Yes, that's the way it has mostly been working. But even before stepping
down as Lead I was starting to wonder if there are ANY successful open
source projects that didn't have either a Benevolent Dictator or some clear
voting process to resolve disputes that cannot be settled with rough
consensus.


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


Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed

2015-06-12 Thread Gavin Andresen
Nice work, Pieter. You're right that my simulation assumed bandwidth for
'block' messages isn't the bottleneck.

But doesn't Matt's fast relay network (and the work I believe we're both
planning on doing in the near future to further optimize block propagation)
make both of our simulations irrelevant in the long-run?

Or, even simpler, why couldn't the little miners just run their
block-assembling-and-announcing code on the other high-bandwidth-side of
the bandwidth bottleneck?

-- 
--
Gavin Andresen
--
___
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 block size limit

2015-06-09 Thread Gavin Andresen
On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . rayst...@hotmail.com wrote:

   That does sound good on the surface, but how do we enforce #1 and #2?
 They seem to be unenforceable, as a miner can adjust the size of the memory
 pool in his local source.


It doesn't have to be enforced. As long as a reasonable percentage of hash
rate is following that policy an attacker that tries to flood the network
will fail to prevent normal transaction traffic from going through and will
just end up transferring some wealth to the miners.

Although the existing default mining policy (which it seems about 70% of
hashpower follows) of setting aside some space for high-priority
transactions regardless of fee might also be enough to cause this attack to
fail in practice.

-- 
--
Gavin Andresen
--
___
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

2015-06-01 Thread Gavin Andresen
On Sun, May 31, 2015 at 6:55 PM, Alex Mizrahi alex.mizr...@gmail.com
wrote:

 Yes, if you are on a slow network then you are at a (slight) disadvantage.
 So?


 Chun mentioned that his pool is on a slow network, and thus bigger blocks
 give it an disadvantage. (Orphan rate is proportional to block size.)

You said that no, on contrary those who make big blocks have a disadvantage.
 And now you say that yes, this disadvantage exist.


Did you just lie to Chun?


Chun said that if somebody produced a big block it would take them at least
6 seconds to process it.

He also said he has nodes outside the great firewall (We also use Aliyun
and Linode cloud services for block
propagation.).

So I assumed that he was talking about the what if somebody produces a
block that takes a long time to process attack -- which doesn't work (the
attacker just increases their own orphan rate).

If the whole network is creating blocks that takes everybody (except the
person creating the blocks) six seconds to broadcast+validate, then the
increase in orphan rate is spread out over the whole network. The
network-wide orphan rate goes up, everybody suffers a little (fewer blocks
created over time) until the next difficulty adjustment, then the
difficulty drops, then everybody is back in the same boat.

If it takes six seconds to validate because of limited bandwidth, then he
should connect via Matt's fast relay network, which optimize new block
announcements so they take a couple orders of magnitude less bandwidth.

If it takes six seconds because he's trying to validate on a raspberry
pi then he should buy a better validating machine, and/or help test the
current pending pull requests to make validation faster (e.g.
https://github.com/bitcoin/bitcoin/pull/5835 or
https://github.com/bitcoin/bitcoin/pull/6077 ).

If Chun had six seconds of latency, and he can't pay for a lower-latency
connection (or it is insanely expensive), then there's nothing he can do,
he'll have to live with a higher orphan rate no matter the block size.

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


Re: [Bitcoin-development] Proposed alternatives to the 20MB step

2015-06-01 Thread Gavin Andresen
RE: going to the public:

I started pushing privately for SOMETHING, ANYTHING to be done, or at the
very least for there to be some coherent plan besides wait and see back
in February.

As for it being unhealthy for me to write the code that I think should be
written and asking people to run it:

Ok. What would you suggest I do? I believe scaling up is the number one
priority right now. I think core devs SHOULD be taking time to solve it,
because I think the uncertainty of how it will be solved (or if it will be
solved) is bad for Bitcoin.

I think working on things like fixing transaction malleability is great...
but the reason to work on that is to enable smart contracts and all sorts
of other interesting new uses of the blockchain. But if we're stuck with
1MB blocks then there won't be room for all of those interesting new uses
on the blockchain.

Others disagree, and have the advantage of status-quo : if nothing is done,
they get what they want.

Based on some comments I've seen, I think there is also concern that my
own personal network/computer connection might not be able to handle more
transaction volume. That is NOT a good reason to limit scalability, but I
think it is clouding the judgement of many of the core contributors who
started contributing as a spare-time hobby from their homes (where maybe
they have crappy DSL connections).


RE: decentralization:

I think this is a red-herring. I'll quote something I said on reddit
yesterday:

I don't believe a 20MB max size will increase centralization to any
significant degree.

See
http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized

and http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners

And I think we will have a lot LESS centralization of payments via services
like Coinbase (or hubs in some future StrawPay/Lightning network) if the
bitcoin network can directly handle more payment volume.

The centralization trade-offs seems very clear to me, and I think the big
blocks mean more centralized arguments are either just wrong or are
exaggerated or ignore the tradeoff with payment centralization (I think
that is a lot more important for privacy and censorship resistance).


RE: incentives for off-chain solutions:

I'll quote myself again from
http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea :

The “layer 2” services that are being built on top of the blockchain are
absolutely necessary to get nearly instant real-time payments,
micropayments and high volume machine-to-machine payments, to pick just
three examples. The ten-minute settlement time of blocks on the network is
not fast enough for those problems, and it will be the ten minute block
interval that drives development of those off-chain innovations more than
the total number of transactions supported.

On Mon, Jun 1, 2015 at 8:45 AM, Jérôme Legoupil jjlegou...@gmail.com
wrote:

 If during the 1MB bumpy period something goes wrong, consensus among the
 community would be reached easily if necessary.


That is the problem: this will be a frog in boiling water problem. I
believe there will be no sudden crisis-- instead, transactions will just
get increasingly unreliable and expensive, driving more and more people
away from Bitcoin towards... I don't know what. Some less expensive, more
reliable, probably more-centralized solution.

The Gavin 20MB proposal is compromising Bitcoin's long-term security in an
 irreversible way, for gaining short-term better user experience.


If by long-term security you mean will transaction fees be high enough to
pay for enough hashing power to secure the network if there are bigger
blocks I've written about that:
http://gavinandresen.ninja/block-size-and-miner-fees-again


If you mean something else, then please be specific.

-- 
--
Gavin Andresen
--
___
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

2015-06-01 Thread Gavin Andresen
On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang 1240...@gmail.com wrote:

 I cannot believe why Gavin (who seems to have difficulty to spell my
 name correctly.) insists on his 20MB proposal regardless the
 community. BIP66 has been introduced for a long time and no one knows
 when the 95% goal can be met. This change to the block max size must
 take one year or more to be adopted. We should increase the limit and
 increase it now. 20MB is simply too big and too risky, sometimes we
 need compromise and push things forward. I agree with any solution
 lower than 10MB in its first two years.


Thanks, that's useful!

What do other people think?  Would starting at a max of 8 or 4 get
consensus?  Scaling up a little less than Nielsen's Law of Internet
Bandwidth predicts for the next 20 years?  (I think predictability is
REALLY important).

I chose 20 because all of my testing shows it to be safe, and all of my
back-of-the-envelope calculations indicate the costs are reasonable.

If consensus is 8 because more than order-of-magnitude increases are
scary -- ok.

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


Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-31 Thread Gavin Andresen
On Sun, May 31, 2015 at 10:59 AM, Jorge Timón jti...@jtimon.cc wrote:

 Whatever...let's use the current subsidies, the same argument applies,
 it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B.
 Miner B would still go out of business, bigger blocks still mean more
 mining and validation centralization

Sorry, but that's ridiculous.

If Miner B is leaving 18BTC per block on the table because they have bad
connectivity, then they need to pay for better connectivity.

If you are arguing I should be able to mine on a 56K modem connection from
the middle of the Sahara then we're going to have to agree to disagree.

So: what is your specific proposal for minimum requirements for
connectivity to run a full node? The 20MB number comes from estimating
costs to run a full node, and as my back-and-forth to Chang Wung shows, the
costs are not excessive.

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


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

2015-05-31 Thread Gavin Andresen
On Sun, May 31, 2015 at 9:31 AM, gb kiw...@yahoo.com wrote:

 Aren't you calculating bandwidth for a singly-connected node? A highly
 connected miner could have 30-100 node connections so you probably need
 to increase your traffic estimates by that factor.

 I.e. For 100MB blocks, 30-100 Mbps and $60-$100 per day data costs.


No, randomly connected gossip networks (which is what the Bitcoin p2p
network is) don't work that way, bandwidth is (roughly) O(N) where N is the
number of bytes relayed to everybody.

(it is actually a small multiple of N, because of the overhead of 'inv'
messages, and if we ever get really serious about scaling up we'll need to
fix the protocol to reduce that overhead, but that won't be a problem for
years).


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


Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-31 Thread Gavin Andresen
On Sun, May 31, 2015 at 3:05 AM, Peter Todd p...@petertodd.org wrote:

 Yeah, I'm pretty surprised myself that Gavin never accepted the
 compromises offered by others in this space for a slow growth solution


What compromise? I haven't seen a specific proposal that could be turned
into a pull request.




 Something important to note in Gavin Andresen's analysises of this issue
 is that he's using quite optimistic scenarios for how nodes are
 connected to each other.


NO I AM NOT.

I simulated a variety of connectivities; see the .cfg files at
  https://github.com/gavinandresen/bitcoin_miningsim

The results I give in the are bigger blocks better blog post are for
WORST CASE connectivity (one dominant big miner, multiple little miners,
big miner connects to only 30% of little miners, but all the little miners
connected directly to each other).


 For instance, assuming that connections between
 miners are direct is a very optimistic assumption


Again, I did not simulate all miners directly connected to each other.

I will note that miners are VERY HIGHLY connected today. It is in their
best interest to be highly connected to each other.


 that depends on a
 permissive, unregulated, environment where miners co-operate with each
 other - obviously that's easily subject to change!


Really? How is that easily subject to change? If it is easily subject to
change, do bigger blocks have any effect? Why are 1MB blocks not subject to
change?

I talk about what if your government bans Bitcoin entirely here:
   http://gavinandresen.ninja/big-blocks-and-tor

... and the issues are essentially the same, independent of block size.


-- 
--
Gavin Andresen
--
___
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

2015-05-31 Thread Gavin Andresen
On Sat, May 30, 2015 at 9:31 PM, Chun Wang 1240...@gmail.com wrote:

 If someone propagate a 20MB block, it will take at best 6 seconds for
 us to receive to verify it at current configuration, result of one
 percent orphan rate increase.


That orphan rate increase will go to whoever is producing the 20MB blocks,
NOT you.


Or, we can mine the next block only on
 the previous block's header, in this case, the network would see many
 more transaction-less blocks.


Are you sure that is the best strategy? If a big block is slow to
propagate, I suspect it will be better to punish the miner that created it
by refusing to build on it until it has been fully validated.

I'll try to find time to run a couple of simulations.




 Our orphan rate is about 0.5% over the past few months. If the network
 floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB
 block could contain an average of 5 transactions, hundred of
 thousands of sigops, Do you have an estimate how long it takes on the
 submitblock rpccall?


I can benchmark it. It should be pretty fast, and sipa has a couple of
patches pending to make the UTXO cache much faster.

It can be fast because the vast majority of the work of validating all
those transactions can happen as they are received into the memory pool.


 For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars
 per month.


You should be able to handle 20MB blocks no problem; if I round up to 100MB
per block that works out to 1.3Mbps.

We also use Aliyun and Linode cloud services for block
 propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for
 100Mbps connectivity at Aliyun.


That speed will handle 20MB blocks no problem.

If each 20MB block is 100MB of data up/down the wire (I'm vastly
over-estimating, after optimization it should be 40MB) then you'll be
paying...uhhh:

0.1 GB / block-data-on-wire * 144 blocks/day * 30.5 days/month * 0.13 $ /
GB = $57

Less than $2 per day in bandwidth.


 For a single cross-border TCP
 connection, it would be certainly far slower than 12.5 MB/s.


That's OK, you'll 1.3Mbps or less.


 I think we can accept 5MB block at most.


Are you worried about paying too much, or do 20MB blocks feel like too
much ?

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


Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-31 Thread Gavin Andresen
On Sun, May 31, 2015 at 10:46 AM, Jorge Timón jti...@jtimon.cc wrote:

 Here's a thought experiment:

 Subsidy is gone, all the block reward comes from fees.

I wrote about long-term hypotheticals and why I think it is a big mistake
to waste time worrying about them here:
   http://gavinandresen.ninja/when-the-block-reward-goes-away


-- 
--
Gavin Andresen
--
___
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

2015-05-31 Thread Gavin Andresen
On Sun, May 31, 2015 at 9:45 AM, Alex Mizrahi alex.mizr...@gmail.com
wrote:



 That orphan rate increase will go to whoever is producing the 20MB
 blocks, NOT you.


 This depends on how miners are connected.

 E.g. suppose there are three miners, A and B have fast connectivity
 between then, and C has a slow network.
 Suppose that A miners a block and B receives it in 1 second. C receives it
 in 6 seconds.
 This means that blocks mined by C during these ~5 seconds will be orphaned
 because B gets A's block first.


Yes, if you are on a slow network then you are at a (slight) disadvantage.
So?

There are lots of equations that go into the is mining profitable
equation: cost of power, Internet cost and connectivity, cost of capital,
access to technology other miners don't have, inexpensive labor or rent,
inexpensive cooling, ability to use waste heat...

That's good. An equation with lots of variables has lots of different
maximum solutions, and that means better decentralization -- there is less
likely to be one perfect place or way to mine.

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


Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-30 Thread Gavin Andresen
On Fri, May 29, 2015 at 7:42 PM, Chun Wang 1240...@gmail.com wrote:

 Hello. I am from F2Pool. We are currently mining the biggest blocks on
 the network.


Thanks for giving your opinion!



 Bad miners could attack us and the network with artificial
 big blocks.


How?

I ran some simulations, and I could not find a network topology where a big
miner producing big blocks could cause a loss of profit to another miner
(big or small) producing smaller blocks:

http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners

(the 0.3% advantage I DID find was for the situation where EVERYBODY was
producing big blocks).


 We think
 the max block size should be increased, but must be increased
 smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
 and so on. Thanks.


Why 2 MB ?   You said that server bandwidth is much more expensive in
China; what would be the difference in your bandwidth costs between 2MB
blocks and 20MB blocks?


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


Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-29 Thread Gavin Andresen
What do other people think?


If we can't come to an agreement soon, then I'll ask for help
reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
big increase now that grows over time so we may never have to go through
all this rancor and debate again.

I'll then ask for help lobbying the merchant services and exchanges and
hosted wallet companies and other bitcoind-using-infrastructure companies
(and anybody who agrees with me that we need bigger blocks sooner rather
than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they
are running it. We'll be able to see uptake on the network by monitoring
client versions.

Perhaps by the time that happens there will be consensus bigger blocks are
needed sooner rather than later; if so, great! The early deployment will
just serve as early testing, and all of the software already deployed will
ready for bigger blocks.

But if there is still no consensus among developers but the bigger blocks
now movement is successful, I'll ask for help getting big miners to do the
same, and use the soft-fork block version voting mechanism to (hopefully)
get a majority and then a super-majority willing to produce bigger blocks.
The purpose of that process is to prove to any doubters that they'd better
start supporting bigger blocks or they'll be left behind, and to give them
a chance to upgrade before that happens.


Because if we can't come to consensus here, the ultimate authority for
determining consensus is what code the majority of merchants and exchanges
and miners are running.


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


Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-29 Thread Gavin Andresen
Matt brought this up on Twitter, I have no idea why I didn't respond weeks
ago (busy writing blog posts, probably):

On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote:



  * Though there are many proposals floating around which could
 significantly decrease block propagation latency, none of them are
 implemented today.


If block propagation isn't fixed, then mines have a strong incentive to
create smaller blocks.

So the max block size is irrelevant, it won't get hit.


 In addition, I'd expect to
 see analysis of how these systems perform in the worst-case, not just
 packet-loss-wise, but in the face of miners attempting to break the system.


See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
for analysis of but that means bigger miners can get an advantage
argument.

Executive summary: if little miners are stupid and produce huge blocks,
then yes, big miners have an advantage.

But they're not, so they won't.

Until the block reward goes away, and assuming transaction fees become an
important source of revenue for miners.
I think it is too early to worry about that; see:

   http://gavinandresen.ninja/when-the-block-reward-goes-away


  * I'd very much like to see someone working on better scaling
 technology, both in terms of development and in terms of getting
 traction in the marketplace.


Ok. What does this have to do with the max block size?

Are you arguing that work won't happen if the max block size increases?

  * I'd like to see some better conclusions to the discussion around

 long-term incentives within the system.


Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away for
what I think about that.

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


Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-29 Thread Gavin Andresen
On Fri, May 29, 2015 at 10:09 AM, Tier Nolan tier.no...@gmail.com wrote:

  How do you intend to measure exchange/merchant acceptance?


Public statements saying we're running software that is ready for bigger
blocks.

And looking at the version (aka user-agent) strings of publicly reachable
nodes on the network.
(e.g. see the count at  https://getaddr.bitnodes.io/nodes/ )

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


Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-28 Thread Gavin Andresen
On Thu, May 28, 2015 at 1:34 PM, Mike Hearn m...@plan99.net wrote:

 As noted, many miners just accept the defaults. With your proposed change
 their target would effectively *drop* from 1mb to 800kb today, which
 seems crazy. That's the exact opposite of what is needed right now.


 I am very skeptical about this idea.


By the time a hard fork can happen, I expect average block size will be
above 500K.

Would you support a rule that was larger of 1MB or 2x average size ? That
is strictly better than the situation we're in today.

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


Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction

2015-05-28 Thread Gavin Andresen
On Thu, May 28, 2015 at 1:59 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:

 I personally think the block size should increase, by the way, but only if
 we can do it under a policy of doing it after technological growth has been
 shown to be sufficient to support it without increased risk.

 Can you be more specific about this? What risks are you worried about?

I've tried to cover all that I've heard about in my blog posts about why I
think the risks of 20MB blocks are outweighed by the benefits, am I missing
something?
  (blog posts are linked from
http://gavinandresen.ninja/time-to-roll-out-bigger-blocks )

There is the a sudden jump to a 20MB max might have unforseen
consequences risk that I don't address, but a dynamic increase would fix
that.

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


Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-28 Thread Gavin Andresen
Can we hold off on bike-shedding the particular choice of parameters until
people have a chance to weigh in on whether or not there is SOME set of
dynamic parameters they would support right now?


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


Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

2015-05-13 Thread Gavin Andresen
I think this needs more details before it gets a BIP number; for example,
which opcodes does this affect, and how, exactly, does it affect them? Is
the merkle root in the block header computed using normalized transaction
ids or normalized ids?

I think there might actually be two or three or four BIPs here:

 + Overall what is trying to be accomplished
 + Changes to the OP_*SIG* opcodes
 + Changes to the bloom-filtering SPV support
 + ...eventually, hard fork rollout plan

I also think that it is a good idea to have actually implemented a proposal
before getting a BIP number. At least, I find that actually writing the
code often turns up issues I hadn't considered when thinking about the
problem at a high level. And I STRONGLY believe BIPs should be descriptive
(here is how this thing works) not proscriptive (here's how I think we
should all do it).

Finally: I like the idea of moving to a normalized txid. But it might make
sense to bundle that change with a bigger change to OP_CHECKSIG; see Greg
Maxwell's excellent talk about his current thoughts on that topic:
  https://www.youtube.com/watch?v=Gs9lJTRZCDc


On Wed, May 13, 2015 at 9:12 AM, Tier Nolan tier.no...@gmail.com wrote:

 I think this is a good way to handle things, but as you say, it is a hard
 fork.

 CHECKLOCKTIMEVERIFY covers many of the use cases, but it would be nice to
 fix malleability once and for all.

 This has the effect of doubling the size of the UTXO database.  At
 minimum, there needs to be a legacy txid to normalized txid map in the
 database.

 An addition to the BIP would eliminate the need for the 2nd index.  You
 could require a SPV proof of the spending transaction to be included with
 legacy transactions.  This would allow clients to verify that the
 normalized txid matched the legacy id.

 The OutPoint would be {LegacyId | SPV Proof to spending tx  | spending tx
 | index}.  This allows a legacy transaction to be upgraded.  OutPoints
 which use a normalized txid don't need the SPV proof.

 The hard fork would be followed by a transitional period, in which both
 txids could be used.  Afterwards, legacy transactions have to have the SPV
 proof added.  This means that old transactions with locktimes years in the
 future can be upgraded for spending, without nodes needing to maintain two
 indexes.


 --
 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




-- 
--
Gavin Andresen
--
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] Long-term mining incentives

2015-05-13 Thread Gavin Andresen
On Tue, May 12, 2015 at 7:48 PM, Adam Back a...@cypherspace.org wrote:

 I think its fair to say no one knows how to make a consensus that
 works in a decentralised fashion that doesnt weaken the bitcoin
 security model without proof-of-work for now.


Yes.


 I am presuming Gavin is just saying in the context of not pre-judging
 the future that maybe in the far future another innovation might be
 found (or alternatively maybe its not mathematically possible).


Yes... or an alternative might be found that weakens the Bitcoin security
model by a small enough amount that it either doesn't matter or the
weakening is vastly overwhelmed by some other benefit.

I'm influenced by the way the Internet works; packets addressed to
74.125.226.67 reliably get to Google through a very decentralized system
that I'll freely admit I don't understand. Yes, a determined attacker can
re-route packets, but layers of security on top means re-routing packets
isn't enough to pull off profitable attacks.

I think Bitcoin's proof-of-work might evolve in a similar way. Yes, you
might be able to 51% attack the POW, but layers of security on top of POW
will mean that won't be enough to pull off profitable attacks.


-- 
--
Gavin Andresen
--
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] Long-term mining incentives

2015-05-12 Thread Gavin Andresen
Added back the list, I didn't mean to reply privately:

Fair enough, I'll try to find time in the next month or three to write up
four plausible future scenarios for how mining incentives might work:

1) Fee-supported with very large blocks containing lots of tiny-fee
transactions
2) Proof-of-idle supported (I wish Tadge Dryja would publish his
proof-of-idle idea)
3) Fees purely as transaction-spam-prevention measure, chain security via
alternative consensus algorithm (in this scenario there is very little
mining).
4) Fee supported with small blocks containing high-fee transactions moving
coins to/from sidechains.

Would that be helpful, or do you have some reason for thinking that we
should pick just one and focus all of our efforts on making that one
scenario happen?

I always think it is better, when possible, not to bet on one horse.


On Tue, May 12, 2015 at 10:39 AM, Thomas Voegtlin thom...@electrum.org
wrote:

 Le 12/05/2015 15:44, Gavin Andresen a écrit :
  Ok, here's my scenario:
 
  https://blog.bitcoinfoundation.org/a-scalability-roadmap/
 
  It might be wrong. I welcome other people to present their road maps.
 

 [answering to you only because you answered to me and not to the list;
 feel free to repost this to the list though]

 Yes, that's exactly the kind of roadmap I am asking for. But your blog
 post does not say anything about long term mining incentives, it only
 talks about scalability. My point is that we need the same kind of thing
 for miners incentives.




-- 
--
Gavin Andresen
--
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] Long-term mining incentives

2015-05-11 Thread Gavin Andresen
I think long-term the chain will not be secured purely by proof-of-work. I
think when the Bitcoin network was tiny running solely on people's home
computers proof-of-work was the right way to secure the chain, and the only
fair way to both secure the chain and distribute the coins.

See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a  for some
half-baked thoughts along those lines. I don't think proof-of-work is the
last word in distributed consensus (I also don't think any alternatives are
anywhere near ready to deploy, but they might be in ten years).

I also think it is premature to worry about what will happen in twenty or
thirty years when the block subsidy is insignificant. A lot will happen in
the next twenty years. I could spin a vision of what will secure the chain
in twenty years, but I'd put a low probability on that vision actually
turning out to be correct.

That is why I keep saying Bitcoin is an experiment. But I also believe that
the incentives are correct, and there are a lot of very motivated, smart,
hard-working people who will make it work. When you're talking about trying
to predict what will happen decades from now, I think that is the best you
can (honestly) do.

-- 
--
Gavin Andresen
--
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] Proposed alternatives to the 20MB step function

2015-05-10 Thread Gavin Andresen
Let me make sure I understand this proposal:

On Fri, May 8, 2015 at 11:36 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

 (*) I believe my currently favored formulation of general dynamic control
 idea is that each miner expresses in their coinbase a preferred size
 between some minimum (e.g. 500k) and the miner's effective-maximum;
 the actual block size can be up to the effective maximum even if the
 preference is lower (you're not forced to make a lower block because you
 stated you wished the limit were lower).  There is a computed maximum
 which is the 33-rd percentile of the last 2016 coinbase preferences
 minus computed_max/52 (rounding up to 1) bytes-- or 500k if thats
 larger. The effective maximum is X bytes more, where X on the range
 [0, computed_maximum] e.g. the miner can double the size of their
 block at most. If X  0, then the miners must also reach a target
 F(x/computed_maximum) times the bits-difficulty; with F(x) = x^2+1  ---
 so the maximum penalty is 2, with a quadratic shape;  for a given mempool
 there will be some value that maximizes expected income.  (obviously all
 implemented with precise fixed point arithmetic).   The percentile is
 intended to give the preferences of the 33% least preferring miners a
 veto on increases (unless a majority chooses to soft-fork them out). The
 minus-comp_max/52 provides an incentive to slowly shrink the maximum
 if its too large-- x/52 would halve the size in one year if miners
 were doing the lowest difficulty mining. The parameters 500k/33rd,
 -computed_max/52 bytes, and f(x)  I have less strong opinions about;
 and would love to hear reasoned arguments for particular parameters.


I'm going to try to figure out how much transaction fee a transaction would
have to pay to bribe a miner to include it. Greg, please let me know if
I've misinterpreted the proposed algorithm. And everybody, please let me
know if I'm making a bone-headed mistake in how I'm computing anything:

Lets say miners are expressing a desire for 600,000 byte blocks in their
coinbases.

computed_max = 600,000 - 600,000/52 = 588,462 bytes.
  -- this is about 23 average-size (500-byte) transactions less than
600,000.
effective_max = 1,176,923

Lets say I want to maintain status quo at 600,000 bytes; how much penalty
do I have?
((600,000-588,462)/588,462)^2 + 1 = 1.00038

How much will that cost me?
The network is hashing at 310PetaHash/sec right now.
Takes 600 seconds to find a block, so 186,000PH per block
186,000 * 0.00038 = 70 extra PH

If it takes 186,000 PH to find a block, and a block is worth 25.13 BTC
(reward plus fees), that 70 PH costs:
(25.13 BTC/block / 186,000 PH/block) * 70 PH = 0.00945 BTC
or at $240 / BTC:  $2.27

... so average transaction fee will have to be about ten cents ($2.27
spread across 23 average-sized transactions) for miners to decide to stay
at 600K blocks. If they fill up 588,462 bytes and don't have some
ten-cent-fee transactions left, they should express a desire to create a
588,462-byte-block and mine with no penalty.

Is that too much?  Not enough?  Average transaction fees today are about 3
cents per transaction.
I created a spreadsheet playing with the parameters:

https://docs.google.com/spreadsheets/d/1zYZfb44Uns8ai0KnoQ-LixDwdhqO5iTI3ZRcihQXlgk/edit?usp=sharing

We could tweak the constants or function to get a transaction fee we
think is reasonable... but we really shouldn't be deciding whether
transaction fees are too high, too low, or just right, and after thinking
about this for a while I think any algorithm that ties difficulty to block
size is just a complicated way of dictating minimum fees.

As for some other dynamic algorithm: OK with me. How do we get consensus on
what the best algorithm is? I'm ok with any don't grow too quickly, give
some reasonable-percentage-minority of miners the ability to block further
increases.

Also relevant here:
The curious task of economics is to demonstrate to men how little they
really know about what they imagine they can design. - Friedrich August
von Hayek

-- 
--
Gavin Andresen
--
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] Proposed alternatives to the 20MB step function

2015-05-09 Thread Gavin Andresen
RE: fixing sigop counting, and building in UTXO cost: great idea! One of
the problems with this debate is it is easy for great ideas get lost in all
the noise.

RE: a hard upper limit, with a dynamic limit under it:

I like that idea. Can we drill down on the hard upper limit?

There are lots of people who want a very high upper limit, right now (all
the big Bitcoin companies, and anybody who thinks as-rapid-as-possible
growth now is the best path to long-term success). This is the it is OK if
you have to run full nodes in a data center camp.

There are also lots of people who want an upper limit low enough that they
can continue to run Bitcoin on the hardware and Internet connection that
they have (or are concerned about centralization, so want to make sure
OTHER people can continue to run).

Is there an upper limit we can choose to make both sets of people mostly
happy? I've proposed must be inexpensive enough that a 'hobbyist' can
afford to run a full node ...

Is the limit chosen once, now, via hard-fork, or should we expect multiple
hard-forks to change it when necessary ?

The economics change every time the block reward halves, which make me
think that might be a good time to adjust the hard upper limit. If we have
a hard upper limit and a lower dynamic limit, perhaps adjusting the hard
upper limit (up or down) to account for the block reward halving, based on
the dynamic limit



RE: the lower dynamic limit algorithm:  I REALLY like that idea.

-- 
--
Gavin Andresen
--
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] Proposed alternatives to the 20MB step function

2015-05-08 Thread Gavin Andresen
I like the bitcoin days destroyed idea.

I like lots of the ideas that have been presented here, on the bitcointalk
forums, etc etc etc.

It is easy to make a proposal, it is hard to wade through all of the
proposals. I'm going to balance that equation by completely ignoring any
proposal that isn't accompanied by code that implements the proposal (with
appropriate tests).

However, I'm not the bottleneck-- you need to get the attention of the
other committers and convince THEM:

a) something should be done now-ish
b) your idea is good

We are stuck on (a) right now, I think.


On Fri, May 8, 2015 at 8:32 AM, Joel Joonatan Kaartinen 
joel.kaarti...@gmail.com wrote:

 Matt,

 It seems you missed my suggestion about basing the maximum block size on
 the bitcoin days destroyed in transactions that are included in the block.
 I think it has potential for both scaling as well as keeping up a constant
 fee pressure. If tuned properly, it should both stop spamming and increase
 block size maximum when there are a lot of real transactions waiting for
 inclusion.

 - Joel



-- 
--
Gavin Andresen
--
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


[Bitcoin-development] Fwd: Block Size Increase

2015-05-07 Thread Gavin Andresen
On Thu, May 7, 2015 at 1:26 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote:

 I think this is a huge issue. You've been wandering around telling
 people that the blocksize will increase soon for months


I think the strongest thing I've ever said is:

There is consensus that the max block size much change sooner or later.
There is not yet consensus on exactly how or when. I will be pushing to
change it this year.

This is what I will be pushing to change it this year looks like.

-- 
--
Gavin Andresen
--
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

2015-05-07 Thread Gavin Andresen
For reference: the blog post that (re)-started this debate, and which links
to individual issues, is here:
  http://gavinandresen.ninja/time-to-roll-out-bigger-blocks

In it, I asked people to email me objections I might have missed. I would
still appreciate it if people do that; it is impossible to keep up with
this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and
also have time to respond thoughtfully to the objections raised.

I would very much like to find some concrete course of action that we can
come to consensus on. Some compromise so we can tell entrepreneurs THIS is
how much transaction volume the main Bitcoin blockchain will be able to
support over the next eleven years.

I've been pretty clear on what I think is a reasonable compromise (a
one-time increase scheduled for early next year), and I have tried to
explain why I think it it is the right set of tradeoffs.

There ARE tradeoffs here, and the hard question is what process do we use
to decide those tradeoffs?  How do we come to consensus? Is it worth my
time to spend hours responding thoughtfully to every new objection raised
here, or will the same thing happen that happened last year and the year
before-- everybody eventually gets tired of arguing
angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?

I AM considering contributing some version of the bigger blocksize-limit
hard-fork patch to the Bitcoin-Xt fork (probably  target a hobbyist with a
fast Internet connection, and assume Nelson's law to increase over time),
and then encouraging merchants and exchanges and web wallets and
individuals who think it strikes a reasonable balance to run it.

And then, assuming it became a super-majority of nodes on the network,
encourage miners to roll out a soft-fork to start producing bigger blocks
and eventually trigger the hard fork.

Because ultimately consensus comes down to what software people choose to
run.

-- 
--
Gavin Andresen
--
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

2015-05-07 Thread Gavin Andresen
Fee dynamics seems to come up over and over again in these discussions,
with lots of talk and theorizing.

I hope some data on what is happening with fees right now might help, so I
wrote another blog post (with graphs, which can't be done in a mailing list
post):
   http://gavinandresen.ninja/the-myth-of-not-full-blocks

We don’t need 100% full one megabyte blocks to start to learn about what is
likely to happen as transaction volume rises and/or the one megabyte block
size limit is raised.

-- 
--
Gavin Andresen
--
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] [softfork proposal] Strict DER signatures

2015-02-03 Thread Gavin Andresen
I think we should just do it, and include it with the other DERSIG changes
for 0.10.

On Tue, Feb 3, 2015 at 1:15 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:


 I understand it's late, which is also why I ask for opinions. It's
 also not a priority, but if we release 0.10 without, it will first
 need a cycle of making this non-standard, and then in a further
 release doing a second softfork to enforce it.

 It's a 2-line change; see #5743.

 --
 Pieter


-- 
--
Gavin Andresen
--
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] New BIP: protocol for multisignature payments

2015-01-31 Thread Gavin Andresen
I agree- standards should be descriptive (here is how this thing I did
works) and NOT proscriptive (here's what I think will work, lets all try
to do it this way.).


On Sat, Jan 31, 2015 at 2:07 PM, Mike Hearn m...@plan99.net wrote:

 I could look at implementing it someday, but now I'd like to receive
 feedback from community.


 IMO it's better to pair a protocol spec with an implementation.


-- 
--
Gavin Andresen
--
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] [softfork proposal] Strict DER signatures

2015-01-21 Thread Gavin Andresen
DERSIG BIP looks great to me, just a few nit-picky changes suggested:

You mention the DER standard : should link to
http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf (or
whatever is best reference for DER).

this would simplify avoiding OpenSSL in consensus implementations  --
this would make it easier for non-OpenSSL implementations

causing opcode failure  : I know what you mean by opcode failure, but
it might be good to be more explicit.

since v0.8.0, and nearly no transactions --  and very few
transactions...

reducing this avenue for malleability is useful on itself as well  :
awkward English. How about just This proposal has the added benefit of
reducing transaction malleability (see BIP62).


-- 
--
Gavin Andresen
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

2015-01-19 Thread Gavin Andresen
On Mon, Jan 19, 2015 at 3:40 PM, Mike Hearn m...@plan99.net wrote:

 OK, I guess we can boil this down more simply. BIP 70 uses protocol
 buffers because I designed it and implemented the original prototype (with
 lots of input from Gavin and an earlier proposal by sipa). I used protocol
 buffers because, beyond all their nice properties, I used to work at Google
 and so was very familiar with them.


What Mike said. Runner-up for encoding was JSON.

XML+ASN.1 was Right Out, because lots of us hate XML and ASN.1 with a
burning passion. Complexity is the Enemy of Security, and both XML and
ASN.1 are too complex.


-- 
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Serialised P2SH HD chains

2014-12-04 Thread Gavin Andresen
On Thu, Dec 4, 2014 at 10:42 AM, Luke Dashjr l...@dashjr.org wrote:

 Is anyone working on a serialisation format to convey P2SH HD chains? For 
 example,
 to give someone who wants to make recurring payments a single token that
 can be used to generate many P2SH addresses paying to a multisig script.


Seems like the wrong approach to me, because in practice you really need
a reasonable expiration date or some way of determining that whatever you
are paying
is still around (I still get random transactions to the Bitcoin Faucet's
old addresses).

See the discussion from January about extending the payment protocol for
recurring transactions:

https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03823.html

Give them a single token == give them a recurring PaymentRequest in my
mind. Or maybe Give them a URL where they can fetch PaymentRequests
whenever they need to make a payment or maybe Give them an array of
PaymentRequests for the next X days/months/years of payments.

-- 
--
Gavin Andresen
--
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=164703151iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP62 and future script upgrades

2014-11-04 Thread Gavin Andresen
On Tue, Nov 4, 2014 at 8:29 AM, Pieter Wuille pieter.wui...@gmail.com
wrote:

 Luke suggested on the pull request to not apply this rule on every
 transaction with nVersion = 3, which indeed solves the problem. I
 believe this can easily be generalized: make the (non mandatory) BIP62
 rules only apply to transaction with strict nVersion==3, and not to
 higher ones.


I agree; soft-forking is a useful way of rolling out upgrades, we shouldn't
prohibit it.

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


Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

2014-10-28 Thread Gavin Andresen
I think Alex's approach is better; I don't think we can know how much
better until we have a functioning fee market.

We don't have a functioning fee market now, because fees are hard-coded. So
we get pay the hard-coded fee and you'll get confirmed in one or two or
three blocks, depending on which miners mine the next three blocks and what
time of day it is.

git HEAD code says you need a fee of 10, satoshis/kb to be pretty sure
you'll get confirmed in the next block. That looks about right with Alex's
real-world data (if we take 90% chance as 'pretty sure you'll get
confirmed'):

Fee rate 10 Avg blocks to confirm 1.09 NumBlocks:% confirmed 1: 0.901
2: 1.0   3: 1.0

My only concern with Alex's code is that it takes much longer to get
'primed' -- Alex, if I started with no data about fees, how long would it
take to be able to get enough data for a reasonable estimate of what is
the least I can pay and still be 90% sure I get confirmed in 20 blocks ?
Hours? Days? Weeks?

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


Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

2014-10-28 Thread Gavin Andresen
On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos mor...@gmail.com wrote:

 Do you think it would make sense to make that 90% number an argument to
 rpc call?  For instance there could be a default (I would use 80%) but then
 you could specify if you required a different certainty.  It wouldn't
 require any code changes and might make it easier for people to build more
 complicated logic on top of it.


RE: 80% versus 90% :  I think a default of 80% will get us a lot of the
fee estimation logic is broken, I want my transactions to confirm quick and
a lot of them aren't confirming for 2 or 3 blocks.

RE: RPC argument:  I'm reluctant to give too many 'knobs' for the RPC
interface. I think the default percentage makes sense as a
command-line/bitcoin.conf option; I can imagine services that want to save
on fees running with -estimatefeethreshold=0.5  (or
-estimatefeethreshold=0.95 if as-fast-as-possible confirmations are
needed). Setting both the number of confirmations and the estimation
threshold on a transaction-by-transaction basis seems like overkill to me.

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


Re: [Bitcoin-development] death by halving

2014-10-25 Thread Gavin Andresen
We had a halving, and it was a non-event.

Is there some reason to believe next time will be different?

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


Re: [Bitcoin-development] BIP process

2014-10-15 Thread Gavin Andresen
RE: process:

I like author == primary control, and an assume they will do the right
thing, revert if they don't

RE: separate mailing list for BIP discussion:

Great idea. Jeff Garzik was looking for a better mailing list solution than
SourceForge, but assuming
there isn't a clearly better solution I think we should create a strictly
moderated bitcoin-bips@lists.sourceforge list.

-- 
--
Gavin Andresen
--
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 draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-07 Thread Gavin Andresen
On Sat, Oct 4, 2014 at 8:58 AM, Mike Hearn m...@plan99.net wrote:


 Meanwhile, what I said *is* correct. New version numbers result in only
 a log print. Being hard forked off results in both log prints *and* the
 -alertnotify being run:


That is easy to change; I'll submit a pull request. It is a good idea to
get an -alertnotify sooner rather than later for EITHER a hard fork or a
soft-fork. Better to be told you have to upgrade while the block.version is
on its way to being a super-majority than after you are either hard-forked
off the main chain (or soft-forked).

I don't have any opinion on the hard- versus soft- fork debate. I think
either can work.

-- 
--
Gavin Andresen
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-01 Thread Gavin Andresen
Very nice, semantics are clear and use cases are compelling.

Can we defer discussion of how to roll this out for a little bit, and see
if there is consensus that:

a) benefits of having this outweigh risks
b) we're all happy with exact semantics

Then we can have a knock-down drag-out argument about whether it should
roll out as a soft fork, wait for a hard fork, be combined with some other
things that it would be nice to add or change, etc.

-- 
--
Gavin Andresen
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-01 Thread Gavin Andresen
On Wed, Oct 1, 2014 at 2:23 PM, Luke Dashjr l...@dashjr.org wrote:

 houghts on some way to have the stack item be incremented by the height at
 which the scriptPubKey was in a block? A limitation of encoding the target
 height/time directly, is that miners may choose not to mine the first
 transaction until they can also take the burn to fee.


If the first transaction is P2SH, then the miner won't know there is an
advantage to holding it until it is too late (the scriptPubKey is an opaque
hash until the second transaction is final and relayed/broadcast).


-- 
--
Gavin Andresen
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-01 Thread Gavin Andresen
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner etothe...@gmail.com wrote:

 On 10/01/2014 04:58 PM, Gavin Andresen wrote:
  If the first transaction is P2SH, then the miner won't know there is
  an advantage to holding it until it is too late (the scriptPubKey is
  an opaque hash until the second transaction is final and
  relayed/broadcast).

 If you're doing some kind of proof-of-burn scheme, wouldn't using P2SH
 defeat the purpose of it?


No, the burner would supply the funding transaction plus the redeeming
script as the proof-of-burn to whoever needed the proof.

Only after at least one confirmation, if there was some risk that revealing
the redeeming script would make miners refuse to mine that first
transaction because they want to get it plus the CHECKTIMELOCKVERIFY burn
transaction.

-- 
--
Gavin Andresen
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire

2014-07-18 Thread Gavin Andresen
Two more half-baked thoughts:

We should be able to assume that the majority of transaction data (except
for coinbase) has already been propagated. As Jeff said, incentivizing
nodes to propagate transactions is a very good thing (the signature cache
already gives a small incentive to miners to propagate and not 'hoard'
transactions).

So the only information that theoretically needs to be propagated is which
transactions a miner is including in their block, and in what order they
are included.

But if there was some agreed-upon canonical ordering, then it should
theoretically be possible to take shortcuts in the what order.

You'd start with setof(transactions I think everybody knows about)
Select some subset, based on miner's policy
Sort that subset with the canonical ordering algorithm
Very efficiently broadcast, taking all sorts of shortcuts assuming most of
your peers already know the set you started with and expect the same
canonical ordering (see gmaxwell's thoughts on block encoding).

Second half-baked thought:
I wonder if broadcasting your transaction selection policy (11KB of free
transactions, sorted by priority, then 111K of fee-paying transactions,
sorted by fee) might make it possible to save even more bandwidth by
letting your peers create a very good approximation of your block with just
that information

-- 
--
Gavin Andresen
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire

2014-07-17 Thread Gavin Andresen
A couple of half-baked thoughts:

On Thu, Jul 17, 2014 at 5:35 PM, Kaz Wesley kezi...@gmail.com wrote:

 If there's support for this proposal, I can begin working on the specific
 implementation details, such as the bloom filters, message format, and
 capability advertisment, and draft a BIP once I have a concrete proposal
 for
 what those would look like and a corresponding precise cost/benefit
 analysis.


I'd encourage you to code up a prototype first (or at the same time), in
whatever programming language / networking library you're most familiar
with.

Maybe not even using the existing p2p protocol; there could be a
mining-only very-fast-block-propagation network separate from the existing
p2p network.

Combining your optimizations with broadcast as many near-miss blocks as
bandwidth will allow on a mining backbone network should allow insanely
fast propagation of most newly solved blocks.

-- 
--
Gavin Andresen
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Building from git on OSX

2014-07-03 Thread Gavin Andresen
Just FYI for anybody else building on OSX:

libtool is a new dependency, so if you update to git HEAD and have trouble
building:

brew install libtool
  (or port install libtool -- see doc/build-osx.md for all the dependencies)
./autogen.sh
./configure   etc, whatever configure options you use. I develop with:
./configure --disable-hardening --disable-silent-rules CXXFLAGS='-g3 -O0
-DDEBUG_LOCKORDER'



-- 
--
Gavin Andresen
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-24 Thread Gavin Andresen
On Tue, Jun 24, 2014 at 3:00 PM, Gmail will.ya...@gmail.com wrote:

 Ok, wanting structured data is a decent argument, but why this random
 arbitrary case in particular? There are hundreds of fields like this that
 people might want to use.


Protocol buffers are designed to be extensible, and there are hundreds of
field numbers available.

It would be silly to add a generic stuff field inside a container format
that ALREADY has all the mechanisms necessary for forwards and backwards
extensibility.


-- 
--
Gavin Andresen
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Proposal: relax the IsStandard rules for P2SH transactions

2014-06-17 Thread Gavin Andresen
Assuming there is rough consensus, I'll make this a pull request (see
https://github.com/gavinandresen/bitcoin-git/tree/relax_isstandard for code
changes).



Now that we are finally starting to see the use of multi-signature and
other more complicated transaction forms in applications I think it is time
to open up the IsStandard transaction rules on the main Bitcoin network.

There are two main risks to doing this:

1. The risk that one of the seldom-used opcodes has a not-yet-discovered
chain-forking bug. I believe that risk to be very low; we have never seen
such a bug on the test network (where all transaction forms are allowed)
and have never found a bug after writing extensive unit tests.
2. The risk of opening up a denial-of-service attack (either bloat the
blockchain or use an excessive amount of CPU time) via a very
expensive-to-store-or-verify transaction. This proposal does not entirely
eliminate IsStandard checks to mitigate the potential for DoS attacks.

Proposal

Allow any Script containing 15 or fewer signature operations as a
pay-to-script-hash (P2SH) Script to be relayed and mined by the reference
implementation.

This should be a simple change to the AreInputsStandard() method in the
reference implementation.

Discussion
--
P2SH Scripts are limited to 520 bytes, and are currently limited to one of
the standard transaction forms on the main network. In practice that
means you can currently encode a n-of-15 OP_CHECKMULTISIG which can be
redeemed as a 'standard' transaction.

Allowing any P2SH Script would allow an attacker to craft a single standard
transaction output that requires on the order of 200 ECDSA signature
checking operations to validate-- an order of magnitude more than is
currently allowed. Therefore I am proposing that we keep the current
15-signature-checking-operations-per-transaction-output limit in place, but
allow any combination of enabled Script opcodes. So, for example, you might
have a P2SH Script that is redeemed with 2-of-2 OR 2-of-3 using:
```
OP_IF 2 pubkey1 pubkey2 2 OP_CHECKMULTISIG OP_ELSE 2 pubkey3 pubkey4
pubkey5 3 OP_CHECKMULTISIG OP_ENDIF
```
(this would count as 5 signature operations)

Restricting arbitrary Scripts to P2SH transaction types limits unspent
transaction output set bloat in two ways:
1. The Scripts are not stored in UTXO set.
2. They are limited to 520 bytes by the Script rule on the amount of data
that can be pushed onto the stack.

The reference implementation's wallet will still only recognize P2SH
transactions that use one of the standard transaction forms. To actually
USE a new transaction form will require specialized wallets or specialized
applications.

-- 
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Gavin Andresen
On Mon, May 19, 2014 at 2:20 PM, Justus Ranvier justusranv...@gmail.comwrote:


 You and Gavin could do a lot better by working on a Bitcoin social
 contract - a promise of what features will *never* be added (or taken
 away) from Bitcoin, because despite what you say it's not acceptable
 to propose anything at all.


Now I'm really confused.

Why would Mike or I have the authority to write a social contract to
promise anything about future-Bitcoin?

I thought the only social contract was the decentralized one we have
already-- if you don't like something about the code, then don't download
and run it. Or fork it if you're able.

As the person who started this mailing list, I DO feel like I have the
authority to enforce a social contract of no trolling or flaming or
name-calling here. I'd very much like to delegate that authority, though;
ideally to some software algorithm that automatically censors topics or
people who don't contribute to a productive discussion.

PS: speaking of productive discussion...
... please change the Subject line when the topic wanders.

-- 
--
Gavin Andresen
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Gavin Andresen
Okey dokey:

I hereby promise and solemnly swear on pain of atomic wedgie that I will
never ever work on or endorse any changes to the Bitcoin system that would
enable any person or group to confiscate, blacklist, or devalue any other
person or group's bitcoin.

RE: writing an RFC: go for it. I have much higher tasks on my TODO list.

-- 
--
Gavin Andresen
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Proposal to change payment protocol signing

2014-04-28 Thread Gavin Andresen
There is a discussion about clarifying how BIP70 signs payment requests
here:
  https://github.com/bitcoin/bips/pull/41

The issue is what to do with the signature field before signing. The code
Mike and I initially wrote does this:

request.set_signature(string());

(sets signature to the empty string)

I think that is a mistake; it should be:

   request.clear_signature();

(clears signature field, so it is not serialized at all).

So: if you are implementing, or have implemented, the payment protocol,
please chime in. I'd like to change the spec and the reference
implementation NOW, while BIP70 is still a 'Draft'.

Because this type of hey, I'm implementing your standard and it doesn't
work the way I think it should mistake is exactly why BIPs take a while
before being declared 'Final.'


-- 
--
Gavin Andresen
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)

2014-04-26 Thread Gavin Andresen

 The main area of concern is handling unexpected problems while sending
 the Payment message, or receiving the corresponding PaymentACK message.
 For example, in case of a transport layer failure or non-200 HTTP status
 code while sending the Payment message, what should the wallet software
 do next? Is it safe to re-send the Payment message? I'd propose that for
 any transport failure or 500 status code, the client retries after a
 delay (suggested at 30-60 seconds). For 400 status codes, the request
 should not be repeated, and as such the user should be alerted and a
 copy of the Payment message saved to be resent later.


Why does error handling have to be standardized?

I generally think that wallet software should be free to do whatever gives
the user the best experience, so I'm in favor of restricting BIPs to things
that must be standardized so that different implementations inter-operate.


 For 300 (redirect and similar) status codes, is it considered safe to
 follow redirects? I think we have to, but good to make it clear in the
 specification.


Referencing whatever RFCs defines how to fetch URLs would be the best way
to do this. Submit a pull request.



 On the merchant's side; I think it would be useful for there to be
 guidance for handling of errors processing Payment messages. I'd suggest
 that Payment messages should have a fixed maximum size to avoid merchant
 systems theoretically having to accept files of any size; 10MB would
 seem far larger than in any way practical, and therefore a good maximum
 size?


PaymentRequests are limited to 50,000 bytes. I can't think of a reason why
Payment messages would need to be any bigger than that. Submit a pull
request to the existing BIP.


 A defined maximum time to wait (to avoid DDoS via connection
 holding) might be useful too, although I'd need to do measurements to
 find what values are tolerable.


Implementation detail that doesn't belong in the spec, in my humble opinion.


 I would like to have the protocol state that merchant systems should
 handle repeatedly receiving the same Payment message, and return an
 equivalent (if not identical) PaymentACK to each. This is important in
 case of a network failure while the client is sending the Payment
 message, as outlined above.


I think this should be left to implementations to work out.


 Lastly, I'm wondering about potential timing issues with transactions;
 if a merchant system wants to see confirmation of a transaction before
 sending a PaymentACK...


 not a good idea. The user should get feedback right away. Poking a
pay now button and then waiting more than a second or three to get your
payment has been received and is being processed is terrible UI.


-- 
--
Gavin Andresen
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Gavin Andresen


 I've formulated my replies to you and this proposal in a more public
 venue, where such discussions of existential changes to the protocol
 more rightfully belong


I strongly disagree.  It makes perfect sense to discuss changes here,
first, where there are lots of people who understand how the system works
at a very detailed level.

And why do you think your blog is more public than this open, publicly
archived mailing list???

-- 
--
Gavin Andresen
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Timed testing

2014-04-17 Thread Gavin Andresen
On Thu, Apr 17, 2014 at 12:09 PM, Jorge Timón jti...@monetize.io wrote:

 So it seems a new mode only makes sense if the -private mode makes
 sense, which in turn only makes sense to include in bitcoind if it's
 useful enough for the network attack simulations, which remains the
 open question.


Unless I misunderstood what your private mode does, you can get the same
effect with -regtest by just controlling nodes connectivity. For example:

Start 2 nodes, connected to each other. Mine a -regtest chain they both
agree on.

Restart them so they're not connected.  Have one mine normally,
have the other  mine... however you like to simulate some attack (deep
chain re-org, double-spend,
whatever).

To simulate launching the attack, connect them together again, let the two
chains compete and see
what happens.

-- 
--
Gavin Andresen
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] 0.9.1 released

2014-04-08 Thread Gavin Andresen
Bitcoin Core version 0.9.1 is now available from:

  https://bitcoin.org/bin/0.9.1/

This is a security update. It is recommended to upgrade to this release
as soon as possible.

It is especially important to upgrade if you currently have version
0.9.0 installed and are using the graphical interface OR you are using
bitcoind from any pre-0.9.1 version, and have enabled SSL for RPC and
have configured allowip to allow rpc connections from potentially
hostile hosts.

Please report bugs using the issue tracker at github:

  https://github.com/bitcoin/bitcoin/issues

How to Upgrade
--

If you are running an older version, shut it down. Wait until it has
completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac)
or
bitcoind/bitcoin-qt (on Linux).

If you are upgrading from version 0.7.2 or earlier, the first time you run
0.9.1 your blockchain files will be re-indexed, which will take anywhere
from
30 minutes to several hours, depending on the speed of your machine.

0.9.1 Release notes
===

No code changes were made between 0.9.0 and 0.9.1. Only the dependencies
were changed.

- Upgrade OpenSSL to 1.0.1g. This release fixes the following
vulnerabilities which can
  affect the Bitcoin Core software:

  - CVE-2014-0160 (heartbleed)
A missing bounds check in the handling of the TLS heartbeat extension
can
be used to reveal up to 64k of memory to a connected client or server.

  - CVE-2014-0076
The Montgomery ladder implementation in OpenSSL does not ensure that
certain swap operations have a constant-time behavior, which makes it
easier for local users to obtain ECDSA nonces via a FLUSH+RELOAD cache
side-channel attack.

- Add statically built executables to Linux build

Credits


Credits go to the OpenSSL team for fixing the vulnerabilities quickly.
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 70 refund field

2014-03-28 Thread Gavin Andresen
On Fri, Mar 28, 2014 at 9:18 AM, Tamas Blummer ta...@bitsofproof.comwrote:

 May I ask how the current payment protocol is supposed to handle salaries?


It doesn't.

walk before you run and all that; lets see what problems we run into with
the minimal payment protocol we have now (like refund outputs you have to
remember forever) before we create an insurmountable set of problems by
trying to solve everything we can think of all at once.

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


Re: [Bitcoin-development] Tree-chains preliminary summary

2014-03-25 Thread Gavin Andresen
On Tue, Mar 25, 2014 at 8:28 AM, Peter Todd p...@petertodd.org wrote:

 Bitcoin doesn't scale. There's a lot of issues at hand here, but the
 most fundemental of them is that to create a block you need to update
 the state of the UTXO set, and the way Bitcoin is designed means that
 updating that state requires bandwidth equal to all the transaction
 volume to keep up with the changes to what set. Long story short, we get
 O(n^2) scaling, which is just plain infeasible.


We have a fundamental disagreement here.

If you go back and read Satoshi's original thoughts on scaling, it is clear
that he imagined tens of thousands of mining nodes and hundreds of millions
of lightweight SPV users.

Scaling is a problem if every person is a fully validating node; then,
indeed, you get an O(n^2) problem.  Which can be solved by extending some
tentative trust to your peers, but lets put all those possible solutions
aside.

Given tens of thousands of fully validating nodes, you get O(m*n), where m
is the number of fully validating peers and is a large constant (10s of
thousands).

We don't know how large m can or will be; we have only just started to
scale up.

Bitcoin doesn't scale is pure FUD. It might not scale in exactly the way
you want, but it WILL scale.

-- 
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys

2014-03-25 Thread Gavin Andresen
Y'all are getting deep into tinfoil-wearing-hat-conspiracy-theory territory.

If you are worried about the NSA compromising your hardware or software,
then use multisig transactions and
sign on diverse hardware/software stacks. Generate the multiple private
keys on different hardware/software
stacks, too.

Or, in other words, eliminate the single point of failure and you will
mitigate whole families of possible attacks,
from NSA compromised the hardware random number generator in my CPU to
NSA is listening to EMF
radiation coming from my dedicated server in my data center to the much
more likely data center employee
is tricked into letting somebody have access to my dedicated server.

-- 
--
Gavin Andresen
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Fake PGP key for Gavin

2014-03-22 Thread Gavin Andresen
On Sat, Mar 22, 2014 at 1:03 PM, Mike Hearn m...@plan99.net wrote:

 do we codesign the Windows binaries?


Yes, the -setup.exe installers are Authenticode (or whatever Microsoft is
calling that these days) code-signed.

-- 
--
Gavin Andresen
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin Core version 0.9.0 released

2014-03-19 Thread Gavin Andresen
 connections
- Bump protocol version to 70002
- Add some additional logging to give extra network insight
- Added new DNS seed from bitcoinstats.com

Validation:

- Log reason for non-standard transaction rejection
- Prune provably-unspendable outputs, and adapt consistency check for it.
- Detect any sufficiently long fork and add a warning
- Call the -alertnotify script when we see a long or invalid fork
- Fix multi-block reorg transaction resurrection
- Reject non-canonically-encoded serialization sizes
- Reject dust amounts during validation
- Accept nLockTime transactions that finalize in the next block

Build system:

- Switch to autotools-based build system
- Build without wallet by passing `--disable-wallet` to configure, this
  removes the BerkeleyDB dependency
- Upgrade gitian dependencies (libpng, libz, libupnpc, boost, openssl) to
more
  recent versions
- Windows 64-bit build support
- Solaris compatibility fixes
- Check integrity of gitian input source tarballs
- Enable full GCC Stack-smashing protection for all OSes

GUI:

- Switch to Qt 5.2.0 for Windows build
- Add payment request (BIP 0070) support
- Improve options dialog
- Show transaction fee in new send confirmation dialog
- Add total balance in overview page
- Allow user to choose data directory on first start, when data directory is
  missing, or when the -choosedatadir option is passed
- Save and restore window positions
- Add vout index to transaction id in transactions details dialog
- Add network traffic graph in debug window
- Add open URI dialog
- Add Coin Control Features
- Improve receive coins workflow: make the 'Receive' tab into a form to
request
  payments, and move historical address list functionality to File menu.
- Rebrand to `Bitcoin Core`
- Move initialization/shutdown to a thread. This prevents Not responding
  messages during startup. Also show a window during shutdown.
- Don't regenerate autostart link on every client startup
- Show and store message of normal bitcoin:URI
- Fix richtext detection hang issue on very old Qt versions
- OS X: Make use of the 10.8+ user notification center to display
Growl-like
  notifications
- OS X: Added NSHighResolutionCapable flag to Info.plist for better font
  rendering on Retina displays.
- OS X: Fix bitcoin-qt startup crash when clicking dock icon
- Linux: Fix Gnome bitcoin: URI handler

Miscellaneous:

- Add Linux script (contrib/qos/tc.sh) to limit outgoing bandwidth
- Add '-regtest' mode, similar to testnet but private with instant block
  generation with 'setgenerate' RPC.
- Add 'linearize.py' script to contrib, for creating bootstrap.dat
- Add separate bitcoin-cli client

Credits


Thanks to everyone who contributed to this release:

- Andrey
- Ashley Holman
- b6393ce9-d324-4fe1-996b-acf82dbc3d53
- bitsofproof
- Brandon Dahler
- Calvin Tam
- Christian Decker
- Christian von Roques
- Christopher Latham
- Chuck
- coblee
- constantined
- Cory Fields
- Cozz Lovan
- daniel
- Daniel Larimer
- David Hill
- Dmitry Smirnov
- Drak
- Eric Lombrozo
- fanquake
- fcicq
- Florin
- frewil
- Gavin Andresen
- Gregory Maxwell
- gubatron
- Guillermo Céspedes Tabárez
- Haakon Nilsen
- HaltingState
- Han Lin Yap
- harry
- Ian Kelling
- Jeff Garzik
- Johnathan Corgan
- Jonas Schnelli
- Josh Lehan
- Josh Triplett
- Julian Langschaedel
- Kangmo
- Lake Denman
- Luke Dashjr
- Mark Friedenbach
- Matt Corallo
- Michael Bauer
- Michael Ford
- Michagogo
- Midnight Magic
- Mike Hearn
- Nils Schneider
- Noel Tiernan
- Olivier Langlois
- patrick s
- Patrick Strateman
- paveljanik
- Peter Todd
- phantomcircuit
- phelixbtc
- Philip Kaufmann
- Pieter Wuille
- Rav3nPL
- R E Broadley
- regergregregerrge
- Robert Backhaus
- Roman Mindalev
- Rune K. Svendsen
- Ryan Niebur
- Scott Ellis
- Scott Willeke
- Sergey Kazenyuk
- Shawn Wilkinson
- Sined
- sje
- Subo1978
- super3
- Tamas Blummer
- theuni
- Thomas Holenstein
- Timon Rapp
- Timothy Stranex
- Tom Geller
- Torstein Husebø
- Vaclav Vobornik
- vhf / victor felder
- Vinnie Falco
- Warren Togami
- Wil Bown
- Wladimir J. van der Laan
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 0.9.0rc3 tagged

2014-03-13 Thread Gavin Andresen
Binaries for 0.9.0rc3 are available at:

https://bitcoin.org/bin/0.9.0/test/

Please help sanity test.

We will also need more 'gitian builders' for the final 0.9.0 release
(Wladimir and I are the only builders so far for the rc3 binaries), so if
you are running Linux or OSX and are willing to help please start up those
virtual machines and start building dependencies.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Multisign payment protocol?

2014-03-11 Thread Gavin Andresen
On Tue, Mar 11, 2014 at 8:38 AM, Jeff Garzik jgar...@bitpay.com wrote:

 On Tue, Mar 11, 2014 at 7:43 AM, Drak d...@zikula.org wrote:
  I very much like the idea of assuming each party uses HD wallets, that
  certainly simplifies things greatly.

 It also assumes a reality different from our current one.


Multisig wallets are a different reality from our current one, so when we
move to that new reality we should do it correctly from the beginning.

-- 
--
Gavin Andrese
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Multisign payment protocol?

2014-03-11 Thread Gavin Andresen
On Tue, Mar 11, 2014 at 10:13 AM, Jeff Garzik jgar...@bitpay.com wrote:

 Sure, but I don't see wallets being able to _assume_ _remote_ parties
 have an HD wallet for a long, long time.  Interoperability common
 sense implies the environment will be heterogenous, perhaps forever,
 invalidating assume-each-party-uses-HD logic.


If the remote party is one of the parties involved in a multisig, and
speaks the Lets set up a multisig wallet together / Lets spend from a
multisig protocols, then it should be perfectly reasonable to assume that
they're HD-capable.

Remote parties paying into a multisig, or receiving funds from a multisig,
don't have to support it (that's what P2SH gives us).

-- 
--
Gavin Andresen
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Multisign payment protocol?

2014-03-10 Thread Gavin Andresen
In my experience, best process for standardizing something is:

1) Somebody has a great idea
2) They implement it
3) Everybody agrees, Great idea! and they copy it.
4) Idea gets refined by the people copying it.
5) It gets standardized.

Mutisig wallets are at step 2 right now. BIP is step 5, in my humble
opinion...




On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org wrote:

 I was wondering if there would be merit in a kind of BIP for a payment
 protocol using multisig?

 Currently, setting up a multisig is quite a feat. Users have to exchange
 public keys, work out how to get the public keys from their addresses. If
 one of the parties are not savvy enough, an malicious party could easily be
 setup that was 2 of 3 instead of 2 of 2 where the malicious party generates
 the multisig address+script and thus be able to run off with funds anyway.

 It's also terribly complex to generate and keep track of. There's been a
 nice attempt at creating an browser interface 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 thoughts?

 Drak


 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
--
Gavin Andresen
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Multisign payment protocol?

2014-03-10 Thread Gavin Andresen
Multisig is orthogonal to the payment protocol (but payment protocol is
needed first).

There need to be protocols for:

a) Establishing multisig wallets of various sorts. See:
  https://moqups.com/gavinandresen/no8mzUDB/
  https://moqups.com/gavinandresen/no8mzUDB/p:ab18547e0
... etc.  for a UI mock-up.
  There needs to be some protocol so all participants in a multisig wallet
contribute keys (actually, we should just assume everybody uses BIP32 HD
public keys so we get privacy from the start).

Multi-person shared wallets, escrows, and wallet protection service
wallets (which might be protected with two-factor authentication) are
different use cases and probably use slightly different protocols (and will
probably need different BIPs eventually).


b) Gathering signatures for a multisig spend. Here is where the payment
protocol is useful; the PaymentRequest message should be passed around so
all participants know what is being paid for, and maybe a partially-signed
Payment message is where the signatures are gathered (or maybe the
signatures are sent separately and one of the participants creates and
submits the Payment and gets the PaymentACK... to be designed).
  See:
https://moqups.com/gavinandresen/no8mzUDB/p:a7e81be96
https://moqups.com/gavinandresen/no8mzUDB/p:af7339204
... for UI mock-up for the multi-person-spend case.

And maybe a protocol for I don't want to be part of this multisig any more
/ I lost control of my private key don't trust me in this multisig any
more.



On Mon, Mar 10, 2014 at 8:14 PM, Jeff Garzik jgar...@bitpay.com wrote:

 All of that only melds with the payment protocol under an extremely
 expansive definition of payment.  The payment protocol is really
 geared towards a direct one-to-one relationship





--
Gavin Andresen
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

2014-02-24 Thread Gavin Andresen
40 bytes is small enough to never require an OP_PUSHDATA1, too, which will
make writing the OP_RETURN-as-standard BIP simpler.


On Mon, Feb 24, 2014 at 11:39 AM, Wladimir laa...@gmail.com wrote:


 On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik jgar...@bitpay.com wrote:

 A common IRC proposal seems to lean towards reducing that from 80.
 I'll leave it to the crowd to argue about size from there. I do think
 regular transactions should have the ability to include some metadata.


 I'd be in favor of bringing it down to 40 for 0.9.

 That'd be enough for 8 byte header/identifier32 byte hash.

 80, as the standard line length, is almost asking for insert your
 graffiti message here. I also see no need for 64 bytes hashes such as
 SHA512 in the context of bitcoin, as that only offers 256-bit security (at
 most) in the first place.

 And if this is not abused, these kind of transactions become popular, and
 more space is really needed, the limit can always be increased in a future
 version.

 Wladimir




-- 
--
Gavin Andresen
--
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 alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-20 Thread Gavin Andresen
I think we should get Pieter's proposal done and implemented quickly. I
agree with Mike, it doesn't have to take a long time for the core network
to fully support this.

Getting wallets to start generating transaction.version=3 might take years,
but that is OK.

-- 
--
Gavin Andresen
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-20 Thread Gavin Andresen
Great, I'm hearing rough consensus to proceed with Pieter's plan.

RE: far from confident on malleability routes:  I'm reasonably confident
that we can squash malleability for IsStandard, SIGHASH_ALL transactions. A
proper proof of DSA signature un-malleability (or an lower bound for how
much work it would be to create a valid doppleganger signature) would be
great, but I don't think it is necessary to proceed.


On Thu, Feb 20, 2014 at 9:36 AM, Gregory Maxwell gmaxw...@gmail.com wrote:

 On Thu, Feb 20, 2014 at 6:29 AM, Gavin Andresen gavinandre...@gmail.com
 wrote:
  I think we should get Pieter's proposal done and implemented quickly. I
  agree with Mike, it doesn't have to take a long time for the core
 network to
  fully support this.
 
  Getting wallets to start generating transaction.version=3 might take
 years,
  but that is OK.

 Sure I'm all for doing what Pieter suggested-- it's basically the plan
 we've been executing for some time already but with the version check
 to make it sane to complete.

 My reserved sounding comments were relative to the proposals to do
 things with nversion=1 transactions, frankly I think thats completely
 insane. Though while we're on the subject of reservations, I am far
 from confident that we've uncovered all the possible malleability
 routes-- that list gained a new, never before discussed entry, when
 Pieter was writing it a couple weeks ago.  We also have no proof of
 the absence of further algebraic malleability in DSA (though I think
 its somewhat unlikely, a solid proof of it has been somewhat elusive).




-- 
--
Gavin Andresen
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Transaction malleability in the core code: update

2014-02-20 Thread Gavin Andresen
A quick update on the state of transaction malleability work in
Bitcoind/Bitcoin-Qt (aka Bitcoin Core). This is not about longer-term
malleability issues, just the very short-term work being done (or already
done) to the reference implementation.

First, the problems:

We've had a longstanding TODO to improve the way the core code deals with
double-spends. From the core code's point of view, malleable transactions
are just one particular form of double-spend.

Improving double-spend handling never made it to the top of the TODO list,
because the cases where it happened involved doing unsupported things (like
copying your wallet.dat to another machine and then spending on both
machines).

And because there is a heavy-handed workaround if a wallet becomes confused
because of a double-spend:  restore all of the keys, rescan for
transactions confirmed in the blockchain, and any outputs tied up in
double-spends get released. Coins (really, unspent transaction outputs)
were never permanently lost, but they could be tied up and unspendable when
associated with a 0-confirmation transaction that would never confirm.

So, work in progress or done:

https://github.com/bitcoin/bitcoin/pull/3659
https://github.com/bitcoin/bitcoin/pull/3674

These implements a kinder, gentler sledgehammer (-zapwallettxes) to fix a
confused wallet. If you have a wallet with 0-confirmation transactions that
are tying up bitcoins these should fix it.


https://github.com/bitcoin/bitcoin/pull/3651
https://github.com/bitcoin/bitcoin/pull/3657
https://github.com/bitcoin/bitcoin/pull/3676

These three merged pull requests implement a new command-line option:
-nospendzeroconfchange .  The best way to get a wallet confused is to spend
zero-confirmation change outputs that you created yourself; if the
transaction creating the change gets mutated, then the subsequent
transaction is invalid and will never confirm.

The core code spends unconfirmed change only as a last resort. If you are a
service using bitcoind that generates a lot of transactions then best
practice would be to run with -nospendzeroconfchange, and use sendmany to
batch payments only after previous payments have confirmed.

https://github.com/bitcoin/bitcoin/pull/3025

This tightens up the IsStandard() rule, so the easiest-to-implement method
of mutating transactions is blocked. Many big mining pools are already
running this patch.

https://github.com/bitcoin/bitcoin/pull/3669
https://github.com/bitcoin/bitcoin/pull/3671
https://github.com/bitcoin/bitcoin/pull/3694

These three get at the root of the problem; they rework the core wallet
code to implement handle double spends better.  See the pull requests for
details.

How can you help:

Testing and code review is, as always, the bottleneck for getting out a
release with these changes.

We have a chronic problem with people running Bitcoin services on top of
the core code waiting until there is an official release, and then
assuming that somebody else has done the hard work of reviewing and testing
the changes.

YOU SHOULD NOT BE MAKING THAT ASSUMPTION!  Your particular RPC call usage
might trigger some edge-case bug that was missed, or perhaps the size of
your wallet triggers a performance problem introduced by a fix.

Or, in other words: do not treat the core development team as if we were a
commercial company that sold you a software library. That is not how open
source works; if you are making a profit using the software, you are
expected to help develop, debug, test, and review it.

-- 
--
Gavin Andresen
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] MtGox blames bitcoin

2014-02-10 Thread Gavin Andresen
RE: taking discussion elsewhere:

Yes, please, the purpose of this mailing list is technical discussions to
encourage interoperability of Bitcoin implementations, improve ease-of-use
and security, etc.

-- 
--
Gavin Andresen
--
Androi apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-30 Thread Gavin Andresen
On Thu, Jan 30, 2014 at 9:51 AM, Jeff Garzik jgar...@bitpay.com wrote:

 Is this truly the intent?  That the merchant/processor takes full
 responsibility for getting the TX confirmed?


The intent is to give the customer a great experience. We could talk for
months about whether having the wallet broadcast the transaction as soon as
possible or having it wait for the merchant to respond with a PaymentACK is
better. But I think we should let wallets experiment with different ways of
doing it, and see what works best in practice.


-- 
--
Gavin Andresen
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Gavin Andresen
On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote:

 Yeah, that's the interpretation I think we should go with for now. There
 was a reason why this isn't specified and I forgot what it was - some
 inability to come to agreement on when to broadcast vs when to submit via
 HTTP, I think.


If the wallet software is doing automatic CoinJoin (for example), then
typically one or several of the other participants will broadcast the
transaction as soon as it is complete.

If the spec said that wallets must not broadcast until they receive a
PaymentACK (if a payment_url is specified), then you'd have to violate the
spec to do CoinJoin.

And even if you don't care about CoinJoin, not broadcasting the transaction
as soon as the inputs are signed adds implementation complexity (should you
retry if payment_url is unavailable? how many times? if you eventually
unlock the probably-not-quite-spent-yet inputs, should you double-spend
them to yourself just in case the merchant eventually gets around to
broadcasting the transaction, or should you just unlock them and squirrel
away the failed Payment so if the merchant does eventually broadcast you
have a record of why the coins were spent).

-- 
--
Gavin Andresen
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Stealth Addresses

2014-01-12 Thread Gavin Andresen
On Sun, Jan 12, 2014 at 5:33 AM, Jeremy Spilman jer...@taplink.co wrote:

 ...
 Now, you would need to get two pubkeys to the payer, throw in a prefix to
 help standardize it, and end up with addresses that could look like (for
 example):


 xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX

 tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba


No, please. Make it easy for non-geeks, extend the payment protocol, or
we'll spend the next two years writing code that tries to ignore linebreaks
and spaces and changing input elements in HTML forms to textarea 

-- 
--
Gavin Andrese
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-12 Thread Gavin Andresen
On Fri, Dec 13, 2013 at 4:24 AM, Mike Hearn m...@plan99.net wrote:

 I think the right way to integrate BIP32 and BIP70 would be to specify
 output scripts as normal for backwards compatibility, and then allow each
 output to have an additional xpubkey and iteration count field. The
 iteration counts could be unsigned.


Why would there be an iteration count? The payer would handle that,
wouldn't they?

If the use case is:  I give the Foundation a here's where to pay my
salary PaymentRequest, maybe with several Outputs each having a different
xpubkey, then it seems to me the Foundation's wallet software should take
care of iterating.

(either saving state, so it knows it used xpubkey+10 last month and should
use xpubkey+11 this month, or maybe it knows I'm paid monthly and just uses
xpubkey+(number_of_months_from_date_in_original_payment_request).

-- 
--
Gavin Andresen
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] 0.8.6 release candidate 1

2013-12-05 Thread Gavin Andresen
0.8.6 release candidate 1 is available from:
  https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.6/test/

Please help sanity-test, especially if you are running OSX or Windows.

-- 
--
Gavin Andresen
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Gavin Andresen

 Wouldn't the idea be that the user always sees 10mBTC no matter what, but
 the receiver may receive less if the user decides to pay with a huge
 transaction?


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 them to eat the cost seems like a
great way to enable bleed-the-merchant-dry attacks.


RE: hiding or showing fees:  I pointed out to Peter that there doesn't have
to be One True Answer.  Let wallets experiment with either hiding or
exposing fees, and may the best user experience win.

-- 
--
Gavin Andresen
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Gavin Andresen

 A merchant can always refuse the payment and refund it if that's a
 practical problem.


No, they can't, at least not in bitcoin-qt:  when the user pokes the SEND
button, the transaction is broadcast on the network, and then the merchant
is also told with the Payment/PaymentACK round-trip.

Allowing merchants to cancel (e.g. having a PaymentNACK) makes
implementation harder, and brings up nasty issues if we want to allow
CoinJoin or CoinJoin-like transactions as payments to merchants.
 Bitcoin-Qt ALREADY allows you to pay several PaymentRequests with one
transaction; handling the case where one merchant gives you a PaymentACK
and another gives you (or wants to give you) a PaymentNACK is a nightmare.

--
Gavin Andresen
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-02 Thread Gavin Andresen
On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn m...@plan99.net wrote:

 PPv1 doesn't have any notion of fee unfortunately. I suppose it could be
 added easily, but we also need to launch the existing feature set.


Lets bang out a merchant-pays-fee extension.

How about:

SPEC:

optional uint64 allowfeetag number=1000

Allow up to allowfee satoshis to be deducted from the amount paid to be
used to pay Bitcoin network transaction fees. A wallet implementation must
not reduce the amount paid for fees more than allowfee, and transaction
fees must be equal to or greater than the amount reduced.

:ENDSPEC

Rationale: we don't want wallet software giving users discounts-- sending
transactions that are amount-allowfee without paying any fee.  We also want
to allow users to pay MORE in fees, if they need to (fragmented wallet,
maybe, or big CoinJoin transaction) or decide to.


PS: I think there was also consensus that the BIP72  request=...   should
be shortened to just r=... (save 6 chars in QR codes).  Unless somebody
objects, I'll change the BIP and the reference implementation code to make
it so...

-- 
--
Gavin Andresen
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize

2013-11-13 Thread Gavin Andresen
Couple of thoughts:

RE: the marvelous coincidence that the average fee these days is very close
to the modeled minimum orphan cost:

Engineers tend to underestimate the power of markets, even inefficient
markets, to arrive at the 'correct' price. It would not surprise me at all
if the messy, chaotic inefficient market with tens of thousands of
individual decisions (which mining pool should I join and how high
should my dice site set fees and how large should the minimum payout be
and should I make my blocks bigger or smaller) might arrive at the
'correct' price, even if NOBODY involved has any clue how or why it
happened.

Or it might just be a coincidence.

RE: orphan rate:

The network-wide orphan rate has been very steady apart from the March
blockchain fork. Kudos to Ben Reeves for keeping track of the data and
giving us a nice chart:
  http://blockchain.info/charts/n-orphaned-blocks

RE: new block latency:

We should be able to reduce the size of new block announcements by about a
factor of ten with very little additional effort (transmit/relay as
merkleblock with full bloom filters-- the factor of 10 is because a
transaction id hash is 32 bytes, average transaction size is a few hundred
bytes).

Mining revenue is a fixed-size pie, so if EVERYBODY agreed to accept
(somewhat) higher orphan rates for more transaction volume then, in the
long run, there is no difference.  Well, except that more transaction
volume means more utility for Bitcoin as a whole, so everybody should
benefit from a higher bitcoin price.

That's a classic free-rider problem, though-- a miner could defect to try
to get a lower orphan rate.

This is one of the reasons why I think relaying all blocks in a race is
probably the right thing to do; if a miner is mildly punished (by losing
the occasional block race) for creating blocks that don't include enough
already-relayed transactions, that is a strong incentive to go along with
whatever consensus has been established.

The same argument applies for a miner producing too-large blocks, or blocks
with lots of transactions that were never relayed across the network.

-- 
--
Gavin Andresen
--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Feedback requested: reject p2p message

2013-10-29 Thread Gavin Andresen
On Tue, Oct 29, 2013 at 10:32 PM, Mike Hearn m...@plan99.net wrote:

 Yes, exactly. That's the point. As you well know I think the whole
 soft-fork mechanism is wrong and should not be used. If the rules change,
 your node is *supposed* to end up on a chain fork and trigger an alert to
 you, that's pretty much the whole purpose of Bitcoin's design. Undermining
 that security model is problematic.


But if you are getting soft-forked recent versions of the reference
implementation WILL alert you; see this code in main.cpp:

if (nUpgraded  100/2)
strMiscWarning = _(Warning: This version is obsolete, upgrade
required!);

That is, if more than half of the last 100 blocks are up-version, warn.
 block.version is part of the block header, so SPV clients can (and
probably should) do the same.

There are also warnings if you are forked, and, most recently, warnings if
there is a high-work alternative fork.

-- 
--
Gavin Andresen
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Feedback requested: reject p2p message

2013-10-28 Thread Gavin Andresen
Thanks for the feedback, everybody, gist updated:
  https://gist.github.com/gavinandresen/7079034

Categories are:

0x01-0x0fProtocol syntax errors0x10-0x1fProtocol semantic errors0x40-0x4fServer
policy rule
https://gist.github.com/gavinandresen/7079034#rejection-codes-common-to-all-message-types

RE: why not a varint:  because we're never ever going to run out of reject
codes.  Eight are defined right now, if we ever defined eight more I'd be
surprised.

RE: why not use HTTP codes directly: because we'd be fitting round pegs
into square holes.

-- 
--
Gavin Andresen
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Advisory: PHP library Bitcoin SCI weak key generation

2013-10-27 Thread Gavin Andresen
Thanks for the warning; to be clear, the Bitcoin SCI library is this
project?
  http://bitfreak.info/index.php?page=toolst=bitsci


On Mon, Oct 28, 2013 at 8:25 AM, Andres Home a86...@outlook.com wrote:

 For those developers who are using the Bitcoin SCI library (maybe others
 too, I
 found two total and could only make contact with one), I would advise that
 you
 review how your software handles private key creation.



 --

--
Gavin Andresen
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Feedback requested: reject p2p message

2013-10-27 Thread Gavin Andresen
RE: use HTTP-like status codes:

Okey dokey, I'll add a one-byte machine-readable HTTP-like status code.
Unless y'all want a 32-bit status code.  Or maybe a varint. Or a
three-character numeric string. I really and truly don't care, but I am
writing this code right now so whatever you want, decide quickly.

If anybody has strong feelings about what the reject categories should be,
then please take the time to write a specific list, I can't read your
mind


-- 
--
Gavin Andresen
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Making fee estimation better

2013-10-25 Thread Gavin Andresen
On Fri, Oct 25, 2013 at 5:51 PM, Jeremy Spilman jer...@taplink.co wrote:

 **
 Gavin, can you confirm the best place to  read  up on the discuss fee
 estimation changes for v0.9?


The blog post is the best place for high-level overview.

The (closed for now, but it will come back) pull request is the best place
for low-level details and nit-picking discussion:
  https://github.com/bitcoin/bitcoin/pull/3024



 I think fee estimation at its core is about providing a data point, or
 even call it an API, which can be used however you see fit.

 What parameters do I want to see in a 'fee estimation' API?

  - 30 minutes vs 24 hours processing time
  - Confidence Levels (50%/90%)


The pull request adds an 'estimatefees' JSON-RPC api call:


estimatefees [prioritymedian=0.1] [feemedian=0.5]
Estimates the priority or fee a transaction needs
to be relayed across the network and included in
the block chain.

prioritymedian and feemedian are values from 0.0
to 1.0, where 0.0 will return the smallest
recently-included-in-a-block priority (or fee) seen,
1.0 the largest, and 0.5 the median priority (or fee)
for transactions that were broadcast on the network and
included in a block.

The default value for prioritymedian (0.1) is
chosen to return a priority for free transactions that
will eventually be confirmed, but might take several hours.
The default value for feemedian (0.5) returns how much
fee you should include to have your transactions confirmed
in an average amount of time.

Values returned are:
 freepriority : priority needed to out-compete a prioritymedian
  fraction of free transactions to be relayed and included in blocks.
 feeperbyte : fee, in satoshis/byte, needed to out-compete a
  feemedian fraction of fee-paying transactions.

Values of -1.0 are returned if not enough transactions
have been seen to make a good estimate.


That API doesn't give 30 minute versus 24 hour confirmation time or
confidence intervals. I've always regretted not taking a statistics class;
if you want to help write code that estimates confidence intervals send me
an email. The API certainly isn't set in stone.

  - Is it globally consistent?


Ummm roughly, yes, it will be. Nodes that have just joined the network
and haven't seen enough transactions enter and leave the memory pool will
have a different estimate than long-running nodes, but in my testing the
estimate narrows down very quickly (with three or four blocks enough
fee-paying transactions have been seen to make a reasonable estimate; it
takes longer to see enough free transactions to get a good estimate of the
priority needed to get into the free space of a block).

RE: lots of other comments:

I feel like there is a lot of in the weeds discussion here about
theoretical, what-if-this-and-that-happens-in-the-future scenarios.

I would just like to point out (again) that this is not intended to be The
One True Solution For Transaction Fees And Transaction Prioritization. If
you've got a better mechanism for estimating fees, fantastic! If it turns
out estimates are often-enough wrong to be a problem and you've got a
solution for that, fantastic!

RE: are we already seeing pressure on transaction fees:

I believe we are, yes. As part of the prep work for the smart fee work I
spent some time plotting priority (for zero-fee transactions) and
transaction fee (for zero-priority transactions) versus confirmation time,
and it looks to me like people/services are starting to include more than
the hard-coded fees in the reference implementation-- I assume because they
want their transactions to be confirmed more quickly.

There is definitely already competition among zero-fee transactions for the
free block space. One of the reasons I'm comfortable with the fee changes
I'm proposing is if the estimation code gets it very wrong we'll see that
first as free transactions taking too long to confirm, but they'll
confirm eventually because priority increases over time.

-- 
--
Gavin Andresen
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Feedback requested: reject p2p message

2013-10-25 Thread Gavin Andresen
Mike Hearn has been lobbying for an error message in the Bitcoin p2p
protocol for years (at least since the ban peers if they send us garbage
denial-of-service mitigation code was pull-requested). This came up again
with my proposed smartfee changes, which would drop low-priority or
low-fee transactions.

In short, giving peers feedback about why their blocks or transactions are
dropped or why they are being banned should help interoperability between
different implementations, and will give SPV (simplified payment
verification) clients feedback when their transactions are rejected due to
insufficient priority or fees.

See the gist for details, I'm looking for feedback and planning on
implementing this before circling back to finish the 'smart fee' work:

   https://gist.github.com/gavinandresen/7079034

-- 
--
Gavin Andresen
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment protocol for onion URLs.

2013-10-25 Thread Gavin Andresen
On Sat, Oct 26, 2013 at 1:31 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

 

This would give us an fully supported option which is completely CA
 free... it would only work for tor sites, but the people concerned
 about CA trechery are likely to want to use tor in any case.

 Thoughts?


I think a tiny number of people would use it, so from a purely engineering
priority perspective my initial reaction is not worth it.

However, as a demonstration of the flexibility of the payment protocol and
because it is a really nifty idea that will give lots of people warm
fuzzies I think you should do it and we should pull it.

-- 
--
Gavin Andresen
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Making fee estimation better

2013-10-24 Thread Gavin Andresen
On Fri, Oct 25, 2013 at 12:54 AM, Peter Todd p...@petertodd.org wrote:

 Eligius has contracts to do transaction mining, and it's currently 10%
 of the hashing power.


Yes, and I asked Luke what percentage of that 10% is OOB fee payments, and
the answer is a small percentage.

So: there are multiple layers of reasons why OOB fee payments will not
screw up the fee estimation code:

+ If the transactions are not broadcast, then they have no effect on the
estimates.

+ If the transactions are broadcast but not relayed because their priority
and fee are way below current estimates then they will have very close to
zero effect on the estimates.

+ If the OOB transaction is zero-fee, zero-priority (e.g comes from a
high-tx-volume service and relies on recently spent outputs) it will have
zero effect on the estimates.

+ If they make up less than about 40% of broadcast transactions they will
have very close to zero effect on the fee estimate (because of the
distribution of fees and behavior of taking a median)

The only case where the estimation code is even slightly likely to get
confused is estimating the priority needed to get into a block IF there are
a significant number of zero-fee, low-but-not-zero-priority OOB
transactions being broadcast.

And since priority naturally increases over time, even if that case DOES
occur the failure is very mild-- it means your free transactions might have
to build up more priority than the code estimates before successfully
entering a block.  If that gets to be an actual problem, then implementing
Pieter's idea of keeping track of memory pool transactions that are NOT
getting mined would fix it. But I don't want to waste time on a theoretical
problem when it is very possible miners will decide to stop accepting free
transactions alltogether.



And all of the above is completely orthogonal to child-pays-for-parent
and/or replace-with-higher-fee.

PS: I would appreciate it if you stop saying things like Regarding the
transaction fee estimate code, it's not very well thought out.

-- 
--
Gavin Andresen
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bitcoind stops responding

2013-10-04 Thread Gavin Andresen
On Tue, Oct 1, 2013 at 6:58 PM, slush sl...@centrum.cz wrote:

 One process is asking getinfo every second as a fallback to possibly
 misconfigured blocknotify. It also calls getblocktemplate every 30 second.


getinfo does a bunch of stuff; with 0.9 you will be able to use
getbestblockhash instead.



 Second process is calling getinfo once a minute to check if bitcoind is
 working. If it don't receive a response in a minute, it kills bitcoind and
 starts it again.


If you just want to see if bitcoind is responding to RPC requests, then
'help getinfo' would do the trick without acquiring any locks.

RE: running into the maximum-of-4-keepalive-requests : simple workaround is
to run with -rpcthreads=11 (or however many keepalive connections you need
to support).  I agree that the rpc code should be smarter; making the last
rpc thread ignore keepalive and always disconnecting should be a fairly
simple patch, and patches welcome.

-- 
--
Gavin Andresen
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Code review

2013-10-04 Thread Gavin Andresen
On Fri, Oct 4, 2013 at 8:30 PM, Mike Hearn m...@plan99.net wrote:

 I'd like to make a small request - when submitting large, complex pieces
 of work for review, please either submit it as one giant squashed change,
 or be an absolute fascist about keeping commits logically clean and
 separated.


I'll try harder to be a fascist (it doesn't come naturally to me). HUGE
thanks for taking the time to review the fee changes in detail.

RE: using Review Board:

I'm all for using better tools, if they will actually get used. If a
potential reviewer has to sign up to create a Review Board account or learn
Yet Another Tool, then I think it would be counter-productive:  we'd just
make the pool of reviewers even smaller than it already is.

Are there good examples of other open source software projects successfully
incentivizing review that we can copy?

For example, I'm wondering if maybe for the 0.9 release and onwards the
Thank you section should thank only people who have significantly helped
test or review other people's code.

-- 
--
Gavin Andresen
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] smart contracts -- possible use case? yes or no?

2013-09-29 Thread Gavin Andresen
On Sun, Sep 29, 2013 at 12:28 PM, Neil Fincham n...@asdf.co.nz wrote:

 I subscribe to this list so I can keep up-to date with bitcoin
 development, can we keep philosophy and tax evasion out of it?


Yes, that's off-topic for this mailing list. Lets stick to technical issues
that we can solve by writing code.

-- 
--
Gavin Andresen
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

2013-09-24 Thread Gavin Andresen
On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn m...@plan99.net wrote:

 BTW, on the make qrcodes more scannable front -- is it too late to
 change BIP 72 so the new param is just r instead of request? Every byte
 helps when it comes to qrcodes ...


Not too late, assuming there are no objections. Smaller QR codes is a very
good reason to change it.

-- 
--
Gavin Andresen
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin-Qt / bitcoind version 0.8.5 released

2013-09-12 Thread Gavin Andresen
Bitcoin-Qt version 0.8.5 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.5/

This is a maintenance release to fix a critical bug;
we urge all users to upgrade.

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues

0.8.5 Release notes
===

Bugs fixed
--

Transactions with version numbers larger than 0x7fff were
incorrectly being relayed and included in blocks.

Blocks containing transactions with version numbers larger
than 0x7fff caused the code that checks for LevelDB database
inconsistencies at startup to erroneously report database
corruption and suggest that you reindex your database.

This release also contains a non-critical fix to the code that
enforces BIP 34 (block height in the coinbase transaction).

--

Thanks to Gregory Maxwell and Pieter Wuille for quickly
identifying and fixing the transaction version number bug.
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] BIP 72 updated: require Accept HTTP header

2013-08-27 Thread Gavin Andresen
I just added a requirement to the BIP 72 (bitcoin: URI payment protocol)
spec:

Wallets must include an Accept HTTP header in HTTP requests:

Accept: application/bitcoin-paymentrequest

... and submitted a pull request so the reference implementation follows
the spec.

Thanks to Stephen/Jeff at BitPay for the suggestion. I'll make a similar
change to BIP 70 and require wallets set Accept:
application/bitcoin-paymentrequestack when sending the Payment and
expecting a PaymentACK message in return.

-- 
--
Gavin Andresen
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] There will be a 0.8.4 release

2013-08-20 Thread Gavin Andresen
There have been a few not-quite-serious-enough-to-justify-a-release
security fixes that, along with a couple of serious bugs, we think together
DO justify a new 0.8.* release.

So I just created a 0.8.4 branch, based on the 0.8.3 branch, and will be
cherry-picking from the master branch.

Planned changes from the 0.8.3 release:

Security-related:
42656ea  Make RPC password resistant to timing attacks
159bc48  Simplify storage of orphan transactions, fix CVE-2013-4627
37c6389  Performance optimization for bloom filters (help mitigate
potential DoS attack discussed last week)

Bug fixes:
9bf2a4ab  Fix multi-block reorg transaction resurrection
bf81a3ef  Fix Gnome bitcoin: URI handler
f0784ac4  Fix non-standard disconnected transactions causing mempool orphans
2461aba1  Mempool consistency check
pull 2916  Import OSX fsync change from LevelDB subtree  (will hopefully
fix the random-OSX leveldb corruption issues)

There are lots of little fixes that could be included, but those will wait
for the 0.9 release.

-- 
--
Gavin Andresen
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

2013-08-19 Thread Gavin Andresen
On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson andr...@petersson.atwrote:

 I was just reviewing the integration work to integrate the Payment
 Protocol into our products. Is there any notion of a standardized
 invoice serialisation? If i pay for two Burgers and one Club Mate, how
 would my Bitcoin Wallet be able to know that?


No. There are XML-based (shudder) standards for electronic invoicing that
include all sorts of bells and whistles; the PaymentDetails message could
easily encapsulate one of them in an 'invoice' field extension. Or we could
reinvent the wheel and come up with our own, but I'd rather use an existing
standard (or maybe a subset of an existing standard).

I didn't want to wade into that swamp for the 1.0 version of the payment
protocol.


 Right now, i would simply
 put that into memo and come up with my own serialisation mechanism.


Two Burgers, one Club Mate seems pretty user-friendly.

Second, is there a way to communicate acceptance levels of TX
 (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK?


No, because the Payment-PaymentACK communication round-trip is done in
one, non-persistent http request-response round-trip.

I don't think we want to allow merchants to push messages to the wallet
(wouldn't take long for merchants to use the opportunity to push annoying
advertising at me, I think), and I don't think we want wallets to poll the
merchant. Although maybe a payment protocol version 2.0 feature could be a
PaymentACK extension that says ask me how the transaction is going at THIS
URL in THIS many minutes.

-- 
--
Gavin Andresen
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_BLOOM BIP

2013-08-18 Thread Gavin Andresen
Mike pointed out exactly the reason I oppose a NODE_BLOOM service bit: I
also think it is a bad idea to start making various bits and pieces of the
protocol optional.

It is bad for privacy (easier to fingerprint nodes) and bad for
decentralization (fewer nodes support your required feature set). And every
bit you add can give you an exponential number of combinations your QA team
should test.

I'd say the same thing about NODE_TRANSACTION (I don't know about blocks,
have and NODE_BLOCK bits.

-- 
--
Gavin Andresen
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-15 Thread Gavin Andresen
Mike asked what non-0.9 code I'm working on; the three things on the top of
my list are:

1) Smarter fee handling on the client side, instead of hard-coded fees. I
was busy today generating scatter-plots and histograms of transaction fees
versus priorities to get some insight into what miner policies look like
right now.

2) First double-spend relaying and alerting, to better support low-value
in-person transactions.  Related:
*Have *a *Snack*, Pay with
*Bitcoins*http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf


3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
block size limit, how we can do it safely, and go through all of the
arguments that have been made against it and explain why they're wrong.

-- 
--
Gavin Andresen
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Version 0.9 goals

2013-08-14 Thread Gavin Andresen
It feels to me like we're close to a 0.9 feature freeze / start of
release cycle; I'd like to talk a little bit about what we'd like to see in
the final 0.9 release.

My list:

Bug:  I'd really like to see the leveldb corruption issue (mostly on OSX,
it seems) fixed. This is hard because it can't be reliably reproduced, and,
at least on my machine, takes weeks to occur. Help needed to reproduce/fix,
see https://github.com/bitcoin/bitcoin/issues/2770 for what we know about
the problem.

Payment Protocol support is ready to be pulled (
https://github.com/bitcoin/bitcoin/pull/2539) . Unless there are major
objections, I will pull it tomorrow (it has already gone through two rounds
of bounty-driven QA testing, so I'm convinced it is ready).

I'd love for 0.9 to contain sipa's headers first initial block download
optimization; I think it is a big enough improvement to justify making the
0.9 test/release cycle longer.

Coin control (https://github.com/bitcoin/bitcoin/pull/2343).

The autotools work (https://github.com/bitcoin/bitcoin/pull/2805).

Gitian-build with the latest openssl and Qt5. Perhaps update the version of
Debian VMs that we gitian-build with.

I plan on spending about half my time on code review and helping get pull
requests tested, and the other half of my time working on code that
probably won't make it into the 0.9 release.

-- 
--
Gavin Andresen
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

2013-08-07 Thread Gavin Andresen
RE: making the bitcoin address in the bitcoin: URI optional:

Ok, I'm convinced, sometimes merchants won't want or need backwards
compatibility and sometimes it won't make sense for them to put an
arbitrary bitcoin: address there.

RE: should the customer's machine not broadcast the transaction:

I'd like to hear from other wallet implementors. Do you have a notion
of 'locked inputs' ?  The tricky bit in constructing a transaction but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.

I'd also like to hear from merchants: any issue with your payment
processing server having broadcast transaction functionality?

My biggest worry is that the payment protocol will not get wide
support if it is too hard to implement.

-- 
--
Gavin Andresen

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

2013-08-07 Thread Gavin Andresen
I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so
the bitcoin address is optional:

If the request parameter is provided and backwards compatibility is
not required, then the bitcoin address portion of the URI may be
omitted (the URI will be of the form: bitcoin:?request=... ).

The spec already said what should happen if both request and
address/amount/etc were given:

it should ignore the bitcoin address/amount/label/message in the URI
and instead fetch a PaymentRequest message and then follow the payment
protocol

I think this gives us a smooth, clear upgrade path.

-- 
--
Gavin Andresen

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


  1   2   3   >